Object orgy
From Wikipedia, the free encyclopedia
| This article may not meet the notability guideline. If you are familiar with the subject matter, please expand or rewrite the article to establish its notability. The best way to address this concern is to reference published, third-party sources about the subject. If notability cannot be established, the article is more likely to be considered for redirection, merge or ultimately deletion, per Wikipedia:Guide to deletion. This article has been tagged since July 2007. |
 |
It has been suggested that this article or section be merged with Spaghetti code. (Discuss) |
In computer programming, object orgy is a term, common in the Perl programming community, describing a common failure (or 'anti-pattern') in object-oriented design or programming. In an object orgy, objects are insufficiently encapsulated, allowing unrestricted access to their internals, usually leading to unmaintainable complexity.
Contents |
[edit] Consequences
The consequences of an object orgy are essentially a loss of the benefits of encapsulation:
- Unrestricted access makes it hard for the reader to reason about the behaviour of an object. This is because direct access to its internal state means any other part of the system can manipulate it, increasing the amount of code to be examined, and opening the door to future abuse.
- As a consequence of the difficulty of reasoning, design by contract is effectively impossible.
- If much code takes advantage of the lack of encapsulation, the result is a scarcely maintainable maze of interactions, commonly known as a rat's nest or spaghetti code.
- The original design is obscured by the excessively broad interfaces to objects.
- The broad interfaces make it harder to re-implement a class without disturbing the rest of the system. This is especially hard when the clients of the class are developed by a different team or organisation.
[edit] Forms
Encapsulation may be weakened by declaring internal members public or by providing free access to data via public getter/setter methods. The access need not be public: for details see ee.g. Java access modifiers and the Accessibility Levels in C# (MSDN). In C++, encapsulation is also weakened by declaring friend-classes or -functions.
An object may also make its internal data accessible by passing references to them as arguments to methods or constructors of other classes, which may retain references.
On the other hand, objects holding references to one another, though sometimes described as a form of object orgy, does not of itself breach encapsulation.
[edit] Causes
Members may be declared public to avoid the effort or syntactic overhead of providing proper accessors for them. This may well increase readability of the class itself, but at the expense of the consequences described above.
In particular, a member may be intended to be readable by other objects may be made modifiable as well because the language used does not provide a convenient construct for read-only access.
An object orgy may be a symptom of coding to an immature design, when the designer has not sufficiently analysed the interactions between objects. It can also arise from laziness or haste in implementing the design, especially if the programmer does not communicate enough with the designer. Reluctance to revise the design when problems arise also encourages this (and many other) anti-patterns.
[edit] Solutions
In general, encapsulation is broken because the design of other classes requires it, and a redesign is required. If that is not the case, it may be sufficient to re-code the system according to best practices. Once the interfaces have been irrevocably published, it may be too late to fix them.
