Anonymous
Unregistered
|
|
Design decisions ultimately come down to trade-offs. This article proposes adding a layer of abstraction and complexity (thus ensuring a maintenance nightmare) all in the name of preserving encapsulation. I favor ease of use and maintainability over complexity (KISS - Keep It Simple, Stupid). Hiding implementation details by not using accessors/mutators is irrelevant given the fact that object creation requires constructors. Constructors can (and do) take parameters. Doesn't the constructors parameter type expose the underlying implementation type? I would argue that an implementation type change occurs very rarely. If it does the designer/architect didn't do his/her job correctly.
|
Anonymous
Unregistered
|
|
I would disagree with that. I have been on a project that has been under continious develoment (EXTENSIONS on the original functionality). It started as a relatively simple application, but over time, there was a lot of extra business rules that needed to be added. You will have to change signatures/types of objects, since the original design wasn't able to account for all those future logic/requirements. It is not that the design is bad, it was good for the requirements set at that time.
We have had nightmare WEEKS refactoring out some key classes that needed to change (the application has over 3000 classes, as to indicate the complexity), the base class was used in about 800 of them, When we encountered this, Me and some coleagues have decided to start to redesign a LOT of classes to use patterns similar to the ones described. By eliminating a lot of data transferring (and thus getter/setter methods) we have saved AGES of time. A few days ago, one of the core business objects had to change (i rewrote half of it, added fields, removed others, and changed the type of some). It is used thrroughout some 600 classes, and I only needed to maintain 12 of them to incorporate the change.
I would see you do this when you rely on getter/setter methods for doing stuff with your objects.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
