How to write better Object Oriented code. The central claim is that OO is not a problem, but many teams are not utilising the features of OO to design better code. Her other point is also that design becomes more important late stage as code bases becomes bigger.
- Premature design is bad. Does not really add value. However when design is required later, it is too late and most people don't know how to do it properly.
- Code that is properly abstracted should be easier to change than complex routines. However, wrongly abstracted code can also make it as difficult at complex code.
- Typical symptoms include method hiding for no reason (copying lines of code into private methods)
- One way to determine if code base has such a problem is to look for files that are high churn and high complexity
- Complexity can be measured in cyclomatic complexity and lines of code
- Santi proposes that most complexity should be inversely proportional to churn.
- Usually occurs on files that describe the apps core business domain
- See video for example on how code is typically made more complicated
- See video also for how to extract classes utilising polymorphism and factory patterns.
- Design principles
- Objects should be be thought of as playing roles. This satisfies Liskov substitution as well.
- Isolate the things you want to vary.
- Use dependancy injection, but inject smartly. In her example, inject objects and behaviors, not data.
- The problem is not OO if you need to see the entire behavior to make changes. It just means the abstraction is bad.