On Dec 12, 7:51 am, Nick <[email protected]> wrote: > 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.
In the given example, all the parameters of the method are internal components of the Employee class. Therefore, the method should probably be part of the Employee class, too. If it was then no parameters at all would be required. However, that's not the point of the lesson. The point is that since the holidays method has no dependency upon the employee, per se, (i.e. it is just a fuction of the date and sales) then it should not have an artificial dependency introduced by explicitly referencing Employee in its method signature. > 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. One principle that Agile Programming advocates have successfully established, is that you should not base your current design upon speculation about what might or might not happen in the future. Code for the requirements in hand. Factor in changes when they happen. (In this case, correctly including the holidays method in the Employee class would mean that the parameterless method signature would be unaffected by the addition of an age dependency.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
