How to make your code suck less

Complexity reduction

• Cyclomatic Complexity – indicator that too much is going on in a class or a method (code smell)
  • How many different branches or paths your code has in it
• Dependencies
• Lines of Code
• Stability
  • Unstable == few dependencies
    • Small fighter jet, very nimble, quick to react
  • Stable = many dependencies
    • Jumbo jet, slow to change directions
• NDepend
• Commercial tool that reads a VS project
• Shows dependencies and other metrics to help find code smells
• Great for refactoring and looking at legacy systems
• VSTS Static Analysis
• Calculate Code Metrics
• .NET Reflector CodeMetrics add-in (http://www.red-gate.com – still a free version)
• Will graph out dependencies (plugin)
• Will show cyclomatic complexities to help find code smells
• DevExpress CodeRush

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, Ninject
• 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

Object-Oriented Programming really varies from language to language, but the core concepts are the same

Smalltalk was the first language to be called “Object Oriented” (Trivia: Simula was first language to implement the concepts)

OOP is about objects collaborating, not functions or tasks.  Objects send and receive messages

C# is a class-based language, classes are the blueprints for the objects

The object, then, is an instance of a class, and it exists at runtime.

Encapsulation – writing code that is self contained.  Consumers don’t need to know HOW, just that communication is possible.  Expressed well through interfaces and implementation of those interfaces

Interface + Implementation leads to decoupling.  If a class is a blueprint, then an interface is the description of that class.

Inheritance - (.NET is single inheritance) is-a versus has-a –> Is this something that HAS something else, or is this something that IS something else?

Keep hierarchies shallow and take advantage of abstract classes for reuse

If you have multiple sub-classes and something higher up the “chain” changes, it changes everything below it.  Rather than sub-classing, use interfaces and always use the is-a test.

Polymorphism – I am one thing with many forms (Single state with many behaviors)
- Parametric Polymorphism – Generics

Single Responsibility Principle – Class has ONE thing to do and that’s it!  Make sure classes only do ONE thing.  Self-documenting

High cohesion/low coupling – Cohesion is a system that communicates well but doesn’t rely on other things

Microsoft decided they were going to go back to the basics in a one day course.  Having been developing as a self-taught developer, I recognize that there are some issues with some things that I need to learn when it comes to the basics.

So, I’m going to post some notes from these sessions which focus on the principles of object-oriented programming, design principles and applying those principles in unit testing.