Objects are like Legos. Pieces are designed to work together and build together. Take small pieces that can be implemented together.
Make code reusable so that you don’t repeat yourself.
Goal is for better quality: fewer bugs, more flexibility
Goal for getting things done faster: save money developing, save money fixing bugs
SOLID principles come from Uncle Bob Martin’s book on Agile Software Development Principles Patterns and Frameworks
These are GUIDELINES, not hard and fast rules, use your brain, do what makes sense
SOLID principles should make life easier! Easy != not learning a new way of doing things
Have only as much complexity as you need – have a good reason for complexity
Single Responsibility Principle – A class should have one, and only one, reason to change. – Just because you can, doesn’t mean you should.
- SRP Fixes – Split big classes that violate SRP rules
- To prevent violation of SRP – enforce Layers
- SRP Violation - “god” classes – Use XML Document comments for the, code smell from and, but or if
- Also put a verb in the Domain service name
- SRP matters because it allows for code reuse, makes maintenance easier by increasing flexibility.
- VS2010 Tip - ctrl+, will allow you to type in Capital Letters of method names for search.
Open Closed Principle – open chest surgery is not needed when putting on a coat
- Utilize interfaces to reuse code
Liskov Substitution Principle – if it walks like a duck and quacks like a duck but needs batteries, it’s probably not the right object
- People using derived classes should not be surprised
- If you violate LSP, fail LOUDLY. Throw an exception for cases that you can’t support (Cube doesn’t have an area, but is still a shape)
Interface Segregation Principle (You want me to plug this in WHERE?)
- Bad example – ASP.NET Membership Provider – a very FAT interface
- Fat interfaces typically have highly coupled code
- If you implement an interface and have to throw an exception because you don’t support a method, that base class or interface is probably too large
- Smaller is better
Dependency Inversion Principle – Would you solder a lamp directly to the electrical wiring in a wall?
- Kill tight coupling (two classes linked together and dependent on each other).
- Use interfaces between UI, Business Logic and Data Access layers
- Goal: Testability
- Unit Testing more than Integration Testing
- Using Mocks rather than actual external dependencies
- Constructor Injection
- DIP Violation – using statics or singletons using static
- What is a DI Container?
- Creates ready to use objects and knows how to create and initialize objects and their dependencies
- Popular .NET Choices
- StructureMap Overview
- Uses automatic conventions of ISomething interface to Something implementation
- DI Container Rules
- Don’t new up anything that’s a dependency
- Do new up entity objects
- Do new up value types (e.g. string, DateTime, etc.)
- Do new up .NET Framework types (e.g. SqlConnection)
- Entity objects should not have dependencies
- Static variables should be isolated behind the DI container
- Use ObjectFactory.GetInstance to create an object when you can take them in as constructor paramters
- Don’t use the DI container when writing Unit Tests
SOLID Articles – http://bit.ly/solid1
Slides – http://bit.ly/solid3