The results of an object orgy are mainly a loss of the benefits of encapsulation, including:
Unrestricted access makes it hard for a 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 examine, and creating means for 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 clients of a class are developed by a different team or organisation.
Forms
Encapsulation may be weakened in several ways, including:
By declaring internal members public, or by providing free access to data via public mutator methods.
In C++, via some of the above means, and 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. In contrast, objects holding references to one another, though sometimes described as a form of object orgy, does not by itself breach encapsulation.
Causes
Members may be declared public to avoid the effort or syntactic overhead of providing proper accessors for them. This may increase readability of the class, but at the cost of the consequences described above. For some languages, a member intended to be readable by other objects can be made modifiable because the language has no convenient construct for read-only access. An object orgy may be a symptom of coding to an immature design, when a designer has insufficiently analysed the interactions between objects. It can also arise from laziness or haste in implementing a design, especially if a programmer does not communicate enough with a designer, or from reluctance to revise a design when problems arise, which also encourages many other anti-patterns.
Solutions
In general, encapsulation is broken because the design of other classes requires it, and a redesign is needed. If that is not the case, it may be sufficient to re-code the system according to best practices. Once the interfaces are published irrevocably, it may be too late to fix them.
