Yie old Reliable Data Structures and Their Controversial (Read) Access. Using objects as data structures is an established practice that generates many problems associated with the maintainability and evolution of software. It misuses brilliant concepts that were stated five decades ago. In this second part we will reflect on the reading access of these objects. In the first part of this article, we showed the transition from hidden information in data structures towards living objects responsibilities (the essential ) hiding the implementation (the accidental ). what how Nude Models - Part I : Setters In this second part, we will show the drawbacks of using . getters The name that does not exist in real world (Reprise) Programmers conventionally use the names of the form to expose (and lose control of) a previously private attribute. Due to the same arguments stated on setter’s article , this name cannot be to a real-world equivalent through . getAttribute…() mapped bijection The final conclusion regarding these names is: There should never be methods of the form setAttribute…() or getAttribute…() Do not expose collections Many objects manage collections. The contents management, the invariants or the traversal method should be the of these objects. sole responsibility Suppose we want to draw the polygon presented on Part I on a canvas. We will achieve it with the following code: $triangle = Polygon([( Point( , ), Point( , ), Point( , ))]);
  $lastPoint = $triangle->getVertices()->last(); ($triangle->getVertices() $vertex){
    $canvas->drawLine($vertex, $lastPoint);
    $lastPoint = $vertex; 
  } new new 1 1 new 2 2 new 3 3 foreach as By exposing the vertices collection (and since collections are in most languages) we lose control over that collection. passed by reference Nothing prevents this other code from running: $triangle = Polygon([( Point( , ), Point( , ), Point( , ))]);
  array_shift($triangle->getVertices()); new new 1 1 new 2 2 new 3 3 array_shift () removes the first value from the array This causes the triangle to mutate, generating an inconsistency in real world . Two-sided polygons would violate the principle of being a closed figure. bijection This defect will be noticed a long time later because it has not been detected in time, thus violating the fail fast principle. Fail Fast Philosophy, Explained In no case shall such objects expose their collections, thus enforcing Demeter’s law. In case you need to return the collected elements, you should answer with a copy ( ) to avoid losing control. With the current state of the art, copying collections is extremely fast. If they were very large collections, there are design solutions with iterators, proxies and cursors to avoid performing the full copy operation. shallow Iterating collections How do we solve the polygon draw operation ? is a well-known topic when working with design patterns: Iterating a collection If we want to go around our polygon, we can return an iterator (indicating we need to do) without revealing our underlying data structure ( we traverse it). what how { ArrayIterator( ->vertices);
    } public : function iterator () Iterator return new $this In case of languages supporting or , we could take the responsibility of iterating elements without exposing an iterator outwards: anonymous functions closures { ( ->vertices $vertex) {
      $$function($vertex);
    } 
  } public function verticesDo ($function) foreach $this as Mutating collections Polygons must not mutate because vertices are part of their minimal : if we remove any of their vertices, they are no longer that polygon that makes them . essence unique There are many business objects that can mutate in their accidental collections and there are mechanisms to manage such mutations. If we wanted to model a account and keep its followers, knowing the business rules, the account is created without followers. Twitter let’s ignore the suggestions that it offers us when creating the new account. { $followers; { ->followers = [];
    }
  } final class TwitterAccount private private function __construct () $this Using and , a novice programmer would be tempted to add a follower in this way: setters getters $mcsee1 = TwitterAccount( );
  $pontifex = TwitterAccount( );
  $mcsee1->getFollowers()[] = $pontifex; new 'mcsee1' new 'pontifex' A correct responsibility assignment guided by business rules suggests that it is the account’s responsibility to add a new follower, carry out validations (for example, that it is was not followed previously) and keep collection integrity. Therefore, a better solution would be: $mcsee1 = TwitterAccount( );
$pontifex = TwitterAccount( );
$mcsee1->addFollower($pontifex); new 'mcsee1' new 'pontifex' Double encapsulation In the 90s there was a tendency to create a of attributes as an extreme approach on privacy. This means that, even from the private methods of an object, direct access to variables would be avoided. double encapsulation This practice does not generate any benefits. Adds unnecessary indirection, and expose setters and getters in languages ​​that have no distinction between and methods. public private In addition, it hides the between an attribute and the direct methods that reference it, avoiding possible refactorings. coupling Coupling: The One and Only Software Designing Problem Tell, don’t ask There is a that states: principle Don’t ask for the information you need to get the job done; ask the object that has the information to do the work for you This principle is known as: . Tell, don’t ask It reminds us that, instead of requesting from an object and acting on this data, we should tell an object to do. This encourages movement of along with the that the object is responsible for managing. data what behavior knowledge Too much information can kill us Paraphrasing Demeter’s Law and minimum coupling and maximum cohesion laws: Each unit should have limited knowledge of others  and only know those units closely related to itself. Each unit should speak only to its friends and not speak to strangers. Just talk to your immediate friends. Adding complexity with and implies generating coupling, violating these rules and generating a greater ripple effect in case of possible changes. accidental setters getters Photo by Macau Photo Agency on Unsplash Setters and getters violate anthropomorphism Let’s go back to our only design rule that asks for a between the model we are building and the real world and respecting the principle of (giving a living entity to each object). bijection Anthropomorphism The One and Only Software Design Principle In doing so, we will discover that the we give to objects after they have been returned with a do not with the real world violating . responsibilities getter map bijection On this there is an excellent example of disrespected anthropomorphism when using . page getters Changing the way we think When we start to model our objects forgetting about their representation, we will be able to avoid (which only fulfill the function of saving data, resulting in a well-known ). accidental anemic classes anti-pattern As with data structures, there is no way for an anemic class to guarantee the integrity of your data and relationships. Since operations on anemic classes are of anemic classes boundaries there is no . Therefore, we will generate both and access points to these attributes that exist in our model. We will always pursue to emulate the behavior of objects like , getting much more realistic and declarative bijections. outside single point of control repeated code black boxes Recommendations Do not use . There are no well-reasoned reasons for doing so. setters Don’t use . In case any of the responsibilities of an object is related to responding to a message matching an attribute, do it thinking beforehand if we are not getters breaking the encapsulation. Never prefix the function name with the word get. If a polygon in the real world can answer what its vertices are, be it with the real world name ( ). vertices() In case of returning collections, return a or a so as not to lose control and favor the use of iterators. copy proxy Have no attributes. For practical purposes it is like having and . It is also a of anemic objects. public setters getters code smell Have no attributes. In addition to what is listed above the classes should be stateless and this is a code smell indicating that a class is being used as a global variable. public static Singleton Pattern: The Root of All Evil Transition from a legacy code system Not all is bad news. Converting a bad model into a good one is possible through a correct and with the help of the appropriate refactors. responsibilities reassignment, If we have the opportunity of improving a system with , we can gradually encapsulate the objects, restricting their access in an good coverage incremental iterative way. In case of not having enough coverage we will be in front of a according to the excellent definition of : legacy code system Michael Feathers A legacy code system is one that has no coverage. Should this be the case, we must the existing functionality, and then we can carry out the necessary transformations. first cover There's an example addressing this problem here: How to Decouple a Legacy System Photo by Greg Nunes on Unsplash Conclusions The well established practice of using and generates and prevents the of our computer systems. setters getters coupling incremental evolution According to the arguments stated in this article, we should restrict their use as much as possible. Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.

Polygon

Twitter

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Nominated for 2022 - HackerNoon Contributor of the Year - Quality Assurance

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - the Greatest Storyteller

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Portfolio

Software Engineer

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Nude Models - Part II : Getters

Nude Models - Part II : Getters

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Nude Models - Part II : Getters

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Maximiliano Contieri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES