Iowa Code Camp 2009 - SOLID Development: Tim Gifford

Sayso, Agile Iowa

Construction Analogy

• Big Ball of Mud - Shantytown, Spaghetti Code (Foote & Yoder)
  • No organized planning, unskilled labor
  • Quick to develop, expensive to maintain
• Peter Principle of Programming - complexity increases until it reaches point where we can no longer cope
• Throwaway Code - Quick Hack, Permanent Prototype, Boomtown - need's been met; move on
• Piecemeal Growth - Urban Sprawl, Iterative-Incremental Development
  • Core module, plug-ins as needed
  • React to change

* - UML + specs does not equate to identical software if given to two developers.

Bad Design == Bad Code

• Rigidity - can't change
• Fragility - breaks others
• Immobility - coupled & tangled; non-reusable

SOLID

• SRP - Single Responsibility Principle
  • A class should have one, and only one, reason to change.
  • Smells: Difficult naming ("and", "or"), Code regions/folding
• OCP - Open Closed Principle
  • You should be able to extend a class' behavior without modifying it.
  • Chain of Responsibility Pattern (refactoring to that) demo'd
  • Should be writing new classes rather than editing old ones.
• LSP - Liskov Substitution Principle
  • Derived classes must be substitutable for their base classes.
  • Design by Contract (preconditions cannot be strengthened, postconditions cannot be weakened)
  • Square/rectangle example
  • Smells: Downcasting, violation leads to violation of OCP, non-abstract functions without implementations
• ISP - Interface Segregation Principle
  • Make fine grained interfaces that are client specific.
  • Favor composition over inheritance.
  • Smells: NotImplementedException, irritation, abstract classes with lots of abstract methods, interfaces with lots of methods
  • Example: System.Web.Security.MembershipProvider - implementing this abstract class requires tons of overrides.
• DIP - Dependency Inversion Principle
  • Depend on abstractions, not on concretions.
  • High level modules should not depend upon low level modules. Both should depend upon abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.
  • Smells: Unable to unit test, fragility, rigidity
  • "New" statements should not be used in methods.
  • If constructors get bloated due to DI, you're violating SRP.
  • Highly cohesive, loosely coupled.
  • The fact that you can't test it means that your code is coupled.
  • IoC container frameworks can handle the wiring.

Functions (practical advice)

• Decompose. Repeat.
• Use a descriptive name
• Inverted pyramid - Journalism - put methods you don't care about at the bottom
• Separate command & query
• Rename function to the comment & delete the comment
• Arguments:
  • No output parameters
  • No unintended consequences (don't modify parameter arguments)
  • No more than 5 arguments - if any are Boolean, a kitten dies!

Professionalism

• Do no harm.
• Time pressure? Doctors could see more patients if they didn't wash their hands.