I have been reviewing some code at work (mostly my own ;) ). We tend to make a lot of mistakes, especially when we have not thought through and we start writing code, only to regret later. Here are my favourite ones.
Explicit object Instantiation: If your design involves instantiating objects from concrete classes, then there's a flaw already. This commits an application to a particular implementation instead of a particular interface, it complicates future (unavoidable) changes.
Visibility to Implementation: If a calling module knows how a library is represented or Implemented, it tends (rather unknowingly) to a design a system which is more specific to the implementation. Hiding this information from the client is a better design because even if the implementation of the object used is changed or altered, there are no cascading changes on the client.
Algorithmic Dependencies: Algorithms are prone to changes in the name of optimization and often are replaced with better ones. Objects that depend on an algorithm will have to change whenever the algorithm changes. Therefore algorithms that are likely to change should be isolated from the rest of the lot.
Too much SubClassing: Subclassing requires an in-depth understanding of the parent class. Overriding one method might require overriding another and so on. Different ways of object composition would be a better approach than extending functionality by subclassing.
Explicit object Instantiation: If your design involves instantiating objects from concrete classes, then there's a flaw already. This commits an application to a particular implementation instead of a particular interface, it complicates future (unavoidable) changes.
Visibility to Implementation: If a calling module knows how a library is represented or Implemented, it tends (rather unknowingly) to a design a system which is more specific to the implementation. Hiding this information from the client is a better design because even if the implementation of the object used is changed or altered, there are no cascading changes on the client.
Algorithmic Dependencies: Algorithms are prone to changes in the name of optimization and often are replaced with better ones. Objects that depend on an algorithm will have to change whenever the algorithm changes. Therefore algorithms that are likely to change should be isolated from the rest of the lot.
Too much SubClassing: Subclassing requires an in-depth understanding of the parent class. Overriding one method might require overriding another and so on. Different ways of object composition would be a better approach than extending functionality by subclassing.
Comments
Post a Comment