Getting things is widespread and safe. But it is a very bad practice.
Problems
Naming
Information Hiding
Coupling
Encapsulation Violation
Mutability
Anemic Models
Solutions
Avoid Getters
Use domain names instead
Protect your implementation decisions.
Sample Code
Wrong
Right
Detection
Getters coincide in certain scenarios with a true responsibility. It will be reasonable for a window to return its color, and it may accidentally store it as color. So a color() method returning the attribute color might be a good solution.
getColor() breaks bijection since it is implementative and has no real counterpart on our mappers.
Most linters can warn us if they detect anemic models with getters and setters.
Tags
- Information Hiding
Conclusion
Getters and Setters are a poorly established practice. Instead of focusing on object behavior (essential), we are desperate to know object guts (accidental) and violate their implementation.
Relations
More info
Credits
Photo by Vidar Nordli-Mathisen on Unsplash
The value of a prototype is in the education it gives you, not in the code itself.
Alan Cooper
Top comments (2)
Method names should start with verbs.
width()isn't a width, it is a method that gets a width and should be named appropriately, iegetWidth(). That goes doubly so forarea()which not only isn't an area, it isn't even getting an area, it is calculating an area and the name should reflect that, iecalArea(). You using property naming conventions for methods is a bigger smell than anything you're pointing out.And I don't know what kind of systems you work in, but a
Windowclass that doesn't allow access to its list of children is best described as nearly useless.what is 'cal' ?
I have asked my child what is 'calArea' and she laughed. She's perfectly aware of what is an area. And she has a friend called 'Cal' btw.
I work in a world class software company and have looooots of windows, we don't access objects since we believe in encapsulation and information hinding principles.
Windows are ok without being accessed