Iowa Code Camp 2009 - SOLID Development: Tim Gifford
- 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;
- 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
- 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
- Square/rectangle example
- Smells: Downcasting, violation leads to violation of OCP, non-abstract functions
- 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
- 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
- No output parameters
- No unintended consequences (don't modify parameter arguments)
- No more than 5 arguments - if any are Boolean, a kitten dies!
- Do no harm.
- Time pressure? Doctors could see more patients if they didn't wash their hands.
Your Host: email@example.com
Copyright © 2009 by William Sorensen. All rights reserved.