Thats a good point, keep it simple. Now in languages that supports extension methods, people would probably be contend with just importing the HR namespace and still be able to say <Employee>.getHolidays() by having the compiler delegate to HR.Utils.getHolidays(<Employee>). That strikes me as a very pragmatic solution with a well balanced pro/con list, though some Java purists will claim readability suffers.
/Casper On Dec 19, 5:35 pm, Kevin Wong <[email protected]> wrote: > Although I'm all about loose coupling, placing concerns and knowledge > where they belong is also important. I this case, what does the > HumanResources.holidays(..) method need to know to calculate > holidays? I think to make this calculation it's acceptable for > HumanResources to have access to all of Employee's data, i.e., holidays > (Employee). Wouldn't your company's human resources department have > access to such data? Dependencies are okay if they make sense and are > not undue. > > On Dec 12, 2:51 am, Nick <[email protected]> wrote:> Hi folks, > > > I'm just reading Code Complete by Steve McConell and I'm thinking of > > an Example he gives in a section about loose coupling. It's about the > > interface of a method that calculates the number of holidays for an > > employee, which is calculated from the entry date of the employee and > > her sales. The author suggests a to have entry date and sales as the > > parameters of the method instead of an instance of the employee: > > > int holidays(Date entryDate, Number sales) > > > instead of > > > int holidays(Employee emp) > > > The argument is that this decouples the client of the method because > > it does not need to know anything about the Employee class. > > > Two things came to my mind: > > > 1. Providing all the parameters that are needed for the calculation > > breaks encapsulation. It shows the internals of the method on how it > > computes the result. > > > 2. It's harder to change, e.g. when someone decides that also the age > > of the employee should be included in the calculation. One would have > > to change the signature. > > > What's your opinion? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
