Doing it wrong: getters and setters. Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling.
A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly-designed set of classes. A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible led to more reliable and maintainable code. Before programming languages supported encapsulation or objects, programmers who cared to write better code followed best practices and idioms (what would be called patterns today) that encouraged limiting scope and data hiding. Back in the old days these ideas were discussed in terms of module strength and coupling.
To learn the concepts without the distraction of OOP and “design patterns” terminology see Glenford Myers’ books “Reliable Software Through Composite Design” and “Composite/Structured Design”. Here’s an example of arguing about the wrong thing. Getters and setters are evil. MF Bliki: GetterEradicator. Encapsulation · API design · object collaboration design tags: You can tell them by the twitch in the left hand side of the mouth when they see a getter method, there's swift pull on their battleaxe and a satisfied cry as another getter is hewn unmercifully from a class which immediately swoons in an ecstasy of gratefulness at the manly Getter Eradicator's feet.
Alright, maybe my return to English beer is affecting me a bit too much, but Chris's gentle tweak struck a pet peevlet of mine. I've often come across people who tell you to avoid having getting methods on classes, treating such things as a violation of encapsulation, Allen Holub's article is one of the best known. The general justification is that getters violate encapsulation. There's some sense to this argument, and I certainly suggest that you shouldn't write accessors until you really need them, but it also brings in the danger of missing the point of encapsulation. Avoiding Nulls with "Tell, Don't Ask" Style. When dealing with possibly non-existent information, a Maybe type forces client code to be aware of, and deal with, the possible non-existence of information.
That complicates the API, violates information hiding and spreads awareness of the possible non-existence of the information throughout the code, complicating everything as it goes. (This is a cue for Haskell programmers to feel smug about monads.) For that reason, I consider a Maybe type to be a tool of last resort when eliminating the use of null references from my code. If my objects follow the Tell, Don't Ask style, I can avoid it altogether. If an object has a query method that returns a value that might not exist, then it must have some way of returning the "does not exist" case.
On the other hand, if the object tells a collaborator to do something with the value, it can choose, when the value does not exist, to just not tell it's collaborator anything or to tell the collaborator to do something different. Spiros.blog() » Blog Archive » A simple example of “Tell, don’t Ask” Tell, Don't Ask. Alec Sharp, in the recent book Smalltalk by Example[SHARP], points up a very valuable lesson in few words: Procedural code gets information then makes decisions.
Object-oriented code tells objects to do things. . — Alec Sharp. Tell, Don't Ask. Alec Sharp, in the recent book Smalltalk by Example[SHARP], points up a very valuable lesson in few words: Procedural code gets information then makes decisions.
Object-oriented code tells objects to do things. . — Alec Sharp That is, you should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do. The problem is that, as the caller, you should not be making decisions based on the state of the called object that result in you then changing the state of the object. Sure, you may say, that’s obvious.
It is easier to stay out of this trap if you start by designing classes based on their responsibilities, you can then progress naturally to specifying commands that the class may execute, as opposed to queries that inform you as to the state of the object. Just the Data The biggest danger here is that by asking for data from an object, you are only getting data. Invariants aren’t enough // Called as: References.