In OOP (Object Oriented Programming) it is important to remember why you are building an application with objects instead of mere functions (procedural programming). Sometimes programmers will treat objects more like functions, which completely defeats the purpose of objects in the first place! The purpose of this post is to explore the real benefit of OOP and how to structure your models properly.
What is a decoupled object?
Contrary to the novice object-oriented programmer’s belief, an object is much more than a collection of data members and related methods. It is important to remember that an object embodies data and methods that belong only to itself. The term “decoupling” is used to identify the separation of software blocks that should not depend on each other.
Why is it important to decouple objects?
let’s say we have a Because class with methods boost(), Stop(), turn(), honk()Y change lanes(). This object is poorly designed because one of the methods, change lanes(), could depend on a street class. What if you were trying to reuse this class for a car that only drives off-road? In this case, the change lanes() The method doesn’t make any sense for instantiating your object. Also, if the turn() method were to refer to the change lanes() method, the whole object would start to seem too specific to instantiate and work with an offroad car. Also, if a change is made to the street class, it is very likely that the Because the class will also have to be modified. As Because has a method that depends on another object, this object is said to be “coupled” (which is what we’re trying to avoid).
How to undock objects
To create what I call “purified objects”, we need to completely decouple them in such a way that all their fields and methods are specific to what the object can do in any given circumstance. To uncouple the Because class, would you like to move the change lanes() method to another object that it interacts with Because, I like it CityDrive. This new object acts as a mediator because it uses the Because class for special circumstances without tarnishing its pure definition.
When designing your object models, ask yourself “are these objects purified? Are they decoupled?” If you ask yourself this question religiously when creating new objects, you’ll not only end up creating much cleaner code, but you’ll also spend less time refactoring. Good luck!