Understanding Object-Oriented Design Principles
đ§ Spotlights
I didnât find enough time to keep up with the challenge.
Spend some time understanding object-oriented principles with Ruby.
Understanding Object-Oriented Design Principles
Hiding implementation involves abstracting data manipulation rather than adding functions between variables.
Small objects encapsulate specific behaviors and break down complex tasks into manageable pieces.
Encapsulation means grouping data with the methods that manipulate that data. Encapsulation conceals an object's information, represented by its data or internal state. This is important because it reduces coupling when objects access each other's internal data.
Snippets of Code is an engineering journal documenting learnings for experiments and projects. I am learning about various programming languages with Exercismâs #48in21 challenge. Please subscribe to receive a new issue every Saturday.
It's essential to avoid asking objects for information and perform a function for them. Instead, we should command objects to do what they need to do. Each object handles its part of the domain and should tell the next object what to do.
Encapsulation should remove the ability to add if statements, forcing us to use commands instead of queries. This prevents us from putting processing in the wrong place.
The Open-Closed Principle, famously known as OCP, was introduced by Bertrand Meyer in the 1980s. The Single Responsibility Principle (SRP) suggests separating the code that different actors depend on. A module should be responsible for one, and only one, actor. The behavior of a software artifact should be extendable without having to change that artifact.
A well-designed software architecture would minimize the changed code to the barest minimum.
The OCP is one of the driving forces behind the architecture of systems. The goal is to make the system easy to extend without causing a high impact of change.
To better encapsulate an object, hide data access behind methods and limit external access to the object's internal state.
It's crucial to avoid asking objects for information and perform a function for them. Instead, we should command objects to do what they need to do. Each object is responsible for its part of the domain and should tell the next object what to do. Encapsulation should remove the ability to add if statements, forcing us to use commands instead of queries. This prevents us from putting processing in the wrong place.
Start each class definition with private methods to identify if an object is doing too much.
The object that owns the data can decide what should be displayed and not how. A value object is intended to be queried, and only that you don't do anything else with it. It simplifies our parameters. You can look at your code and see the direction of information, and if things are traveling west, that's a sign that you're leaking information. Information leaks responsibilities.
Commands encourage polymorphism.
They push responsibility down into objects, resulting in a looser coupling. To encapsulate data, always return self
. There's no other option if you're returning
and hiding information about an object so that you cannot query it.
Encapsulation conceals an object's information, represented by its data or internal state.
đ» đ
# using encapsulation for data hiding
class ShoppingCart
attr_reader :total
def initialize
@items = []
end
def add_item(item)
@items << item
self
end
def calculate_total
total = 0
@total = items.sum(&:price)
self
end
private
attr_reader :items
end
Item = Struc.new(:name, :price, keyword_init: true)
end
đ§Ș Next Actions
I am searching for a new job, so I will spend some time learning new tools in the Typescript ecosystem.
Start re-learning GoLang. Not curiosity but to open more market opportunities.
Complete all the exercises until Leap for Clojure. This one is out of curiosity.
If you enjoy the learning journal, please â€ïž If someone will benefit from this content, please share.