Object orgy
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) (New page: This anti-pattern occurs when there is insufficient encapsulation in a system and objects just access each other's internals directly rather than going through a public interface. ==Liabi...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Bertrand Roussel) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
==Liabilities== | ==Liabilities== | ||
| + | *Harder to find bugs because any part of the system could have potentially changed the state of an object to cause a bug so it is harder to determine where the problem occurred. | ||
| + | *Harder to reason about the behavior of an object because any part of the system can manipulate its internals. | ||
| + | *If many parts of the system access the internals of an object, the result is difficult to maintain [[Spaghetti code]]. | ||
| + | *It is harder to change the internal workings of a class because the change can effect many other parts of the system. | ||
| + | *Large public interfaces can make code hard to understand and obscure the original design. | ||
==Related design heuristics== | ==Related design heuristics== | ||
| Line 10: | Line 15: | ||
*[[Don't expose mutable attributes]] | *[[Don't expose mutable attributes]] | ||
*[[Encapsulate that which varies]] | *[[Encapsulate that which varies]] | ||
| + | *[[Minimize accesses to variables]] | ||
| + | |||
| + | {{Design Anti-patterns}} | ||
| + | [[Category: Anti-Patterns]] | ||
Latest revision as of 03:01, 25 November 2010
This anti-pattern occurs when there is insufficient encapsulation in a system and objects just access each other's internals directly rather than going through a public interface.
Liabilities
- Harder to find bugs because any part of the system could have potentially changed the state of an object to cause a bug so it is harder to determine where the problem occurred.
- Harder to reason about the behavior of an object because any part of the system can manipulate its internals.
- If many parts of the system access the internals of an object, the result is difficult to maintain Spaghetti code.
- It is harder to change the internal workings of a class because the change can effect many other parts of the system.
- Large public interfaces can make code hard to understand and obscure the original design.
Related design heuristics
- Information hiding
- Hide data within its class
- Minimal public interface
- Coupling and cohesion
- Don't expose mutable attributes
- Encapsulate that which varies
- Minimize accesses to variables
