Lecture
In computer programming, an object orgy is a situation in which objects are not sufficiently encapsulated through information hiding, allowing unrestricted access to their internals. This is a common failure (or anti-pattern) in object-oriented design or object-oriented programming, and it can lead to increased maintenance needs and problems, and even to unmanageable complexity.
"Object orgy" is a programming term describing a typical anti-pattern. In an object orgy, objects are insufficiently encapsulated and allow unrestricted access to their internal properties. As a result, the code becomes difficult to read, because it becomes unclear what the object is actually for. The class's interface loses its meaning. And changing such a class in the future becomes practically impossible, because one cannot be sure that some part of the application is not accessing the property directly.
Most often this looks like declaring properties as public rather than protected or private. It is often caused by "immature programming" - when a programmer starts writing a class without fully knowing what the class will do.
How to fight it? Design and finalize the class interface before writing the code.
The result of an object orgy is mainly the loss of the benefits of encapsulation, including:
Encapsulation can be weakened in several ways, including:
friendclasses or functions.An object can also make its internal data accessible by passing references to it as arguments to methods or constructors of other classes, which may retain those references.
In contrast, objects that hold references to each other, although sometimes described as a form of object orgy, do not by themselves violate encapsulation.
Members may be declared public to avoid the extra effort or syntactic overhead associated with providing them with proper accessors. This can improve the readability of the class, but at the cost of the consequences described above.
In some languages, a member intended to be read by other objects may be made mutable, because the language lacks a convenient construct for read-only access.
An object orgy can be a symptom of coding an immature, anemic design, where the designer has not sufficiently analyzed the interactions between objects. It can also arise from laziness or haste in implementing the design, especially when the programmer does not communicate enough with the designer, or from a reluctance to revise the design when problems arise, which also encourages many other anti-patterns.
Many programmers treat objects as anemic data stores and manipulate them, violating the principles of information hiding, encapsulation, and design by contract.
As a rule, encapsulation is violated because the design of other classes requires it, and rework is needed. If that is not the case, it may be enough to recode the system in accordance with best practices. Once interfaces have been published irrevocably, it may already be too late to fix them.
Comments