Are Shy classes the solution for Unorganized Code
Are Shy classes the solution for Unorganized Code
Are Shy classes the solution for Unorganized Code
Date
May 16, 2023
Read Time
3
min read
Category
Clean Code
Too many dependencies and unorganized code, are shy classes the answer?
I'm going to share why writing shy classes can help the readability and usage of your code, as well as keep it more maintainable. This is a concept if seen mentioned in many places some way or another and I wish to expand upon it since I've found that it has greatly improved how I think of classes and systems.
The objective of Shy Classes is to be self-contained entities that minimize their interactions with the outside (those being other classes and modules). Also as a shy person would, a Shy Class should hide as much of their internal details when interacting with others, maintaining a clear boundary and reducing coupling finally Shy Code should not be too nosy about other class's affairs.
The Do’s of Shy Classes
Do’s:
- Shy Classes should not ask many questions, and shy codes should follow the Tell don’t ask principle, where you should not need to know the other's internal state to tell him to do something.
- Shy classes should well, hide as much as they can! They should avoid public variables and most importantly, they should hide how they internally work. You don’t need to know how a plumber does his job when you ask him to fix your pipes.
- Shy Classes do not want to know the ins and outs of neighbor classes, they should “interact” as less as possible.
- Shy Classes do not want to depend much on other classes so they should strive to be independent, minimizing the dependencies on other classes
Resources
- [OOP Concept for Beginners: What is Abstraction?](read://https_stackify.com/?url=https%3A%2F%2Fstackify.com%2Foop-concept-abstraction%2F)
- [may_04_oo1.pdf](https://media.pragprog.com/articles/may_04_oo1.pdf)
- [Code quality - Keep my classes and methods as small as possible? - Software Engineering Stack Exchange](https://softwareengineering.stackexchange.com/questions/125357/keep-my-classes-and-methods-as-small-as-possible)
- [Use An Ask, Don’t Tell Policy With Ruby - Pat Shaughnessy](https://patshaughnessy.net/2014/2/10/use-an-ask-dont-tell-policy-with-ruby)
- [“Shy” Code. Dependencies in the code are what makes… | by Leena | Continuous Delivery | Medium](https://medium.com/continuousdelivery/shy-code-7e1dba06ae55)
- [Tell Don't Ask | Code Walks 011 - YouTube](https://www.youtube.com/watch?v=-wnt-UH5VBw)
Too many dependencies and unorganized code, are shy classes the answer?
I'm going to share why writing shy classes can help the readability and usage of your code, as well as keep it more maintainable. This is a concept if seen mentioned in many places some way or another and I wish to expand upon it since I've found that it has greatly improved how I think of classes and systems.
The objective of Shy Classes is to be self-contained entities that minimize their interactions with the outside (those being other classes and modules). Also as a shy person would, a Shy Class should hide as much of their internal details when interacting with others, maintaining a clear boundary and reducing coupling finally Shy Code should not be too nosy about other class's affairs.
The Do’s of Shy Classes
Do’s:
- Shy Classes should not ask many questions, and shy codes should follow the Tell don’t ask principle, where you should not need to know the other's internal state to tell him to do something.
- Shy classes should well, hide as much as they can! They should avoid public variables and most importantly, they should hide how they internally work. You don’t need to know how a plumber does his job when you ask him to fix your pipes.
- Shy Classes do not want to know the ins and outs of neighbor classes, they should “interact” as less as possible.
- Shy Classes do not want to depend much on other classes so they should strive to be independent, minimizing the dependencies on other classes
Resources
- [OOP Concept for Beginners: What is Abstraction?](read://https_stackify.com/?url=https%3A%2F%2Fstackify.com%2Foop-concept-abstraction%2F)
- [may_04_oo1.pdf](https://media.pragprog.com/articles/may_04_oo1.pdf)
- [Code quality - Keep my classes and methods as small as possible? - Software Engineering Stack Exchange](https://softwareengineering.stackexchange.com/questions/125357/keep-my-classes-and-methods-as-small-as-possible)
- [Use An Ask, Don’t Tell Policy With Ruby - Pat Shaughnessy](https://patshaughnessy.net/2014/2/10/use-an-ask-dont-tell-policy-with-ruby)
- [“Shy” Code. Dependencies in the code are what makes… | by Leena | Continuous Delivery | Medium](https://medium.com/continuousdelivery/shy-code-7e1dba06ae55)
- [Tell Don't Ask | Code Walks 011 - YouTube](https://www.youtube.com/watch?v=-wnt-UH5VBw)