OO Issues

After almost 10 years of working in OO languages, I've compiled a list of issues I see with the paradigm. Some are implementation specific but some aren't.

• Non-conforming subtype: Methods from a parent class that "don't apply" to the subtype, frequently the body of the routine is an exception or an assertion. This frequent practice breaks LSP and one of the main purposes of class subtyping.
• Inheritance for reuse: When multiple unrelated classes need to perform the same functionality, frequently the class hierarchy is rearranged to accommodate the unrelated classes to be under some shared parent explicitly for the point of reusing functionality. As more classes are added under the hierarchy for routine reuse, each class uses non-overlapping subsets of parent functionality.
• New operations on existing class definitions: Frequently utility functions are created to perform functionality that would really be a member routine of the target class except the class consumer may not have access to change the text of the target class. Frequently seen with utility functions on strings or integers.
• Reimplementing state with routines: When something was once implemented as a member variable wants to be changed to a routine in a subclass this causes a fragile base class problem.
• Encapsulation mutually exclusive to testing: Directly testing an individual method can be have great variance in difficulty varying from trivial to almost impossible if dependent parts of the class require accessing external resources.
• Encapsulation mutually exclusive to routine reuse: The main idea behind encapsulation is that the user can't unintentially "break things" in the class. This reasoning needs to be contrasted with two other confounding factors: for many classes it's possible to "break things" in the class even with the public interface; some times users actually wants to tweak some part of the class while keeping the majority of the class intact. If the original class author didn't keep this extensibility in mind the end user is left with the option of reimplementing the entire class.
• Utility routines that don't depend on class state: When a member routine only depends on arguments and not on its associated class, this is usually seen associated with the "New operations on existing class definitions" problem.
• Classes that belong to multiple hierarchies
• Wide variance in handling of name or method collision in OO languages. Very few offer flexibility for all programmer desired semantics.
• Constructors can only be varied by overloading: Languages that allow constructors to only have one name greatly hinder construction flexibility.
• Despite complicated constructor rules, many holes in safety of object initialization: Constructor chaining and static initialization orders have many complicated rules and most languages still have issues with mutually recursive class initialization.
• Adapters as a case of partial function application