Geeks With Blogs

News Please visit me at my new blog!!

profile for Aligned at Stack Overflow, Q&A for professional and enthusiast programmers
"free in Christ Jesus from the law of sin and death." Romans 8:2 (ESV) Check out the Falling Plates video on YouTube.
more about the Gospel
And then listen to Francis Chan speaking at LifeLight in SD.

Programming and Learning from SD

I took notes on a great TechEd presentation about the S.O.L.I.D. principles. I highly recommend this talk for all developers.


Single Responsibility Principle

There can be only one requirement that, when changed, will cause a class to change

simple easy classes

easy to switch out

Open/Closed principle

once a class is done, it is done!

don't modify it

no need to change tests

Meyer vs. Polymorphic min 20

Meyer class implementation to inherit from - how much virtual?

DocumentStorage with virtual method

FileDocumentStorage : DocumentStorage

Opening up for extension, closing it down for modifications

or interfaces and base classes

benefits - no unit test reworks, don't change code and you won't break it

Liskovs Substitution Principle

"A subclass should behave in such a way that it will not cause problems when used instead of the superclass"


Contravariance of the method args in a sub class is allowed

- new inheritor, you can have different and additional params, then pass to the base class

Covariance of return types in the sub class is allowed

- return value can be any type that is the same as the parent or a descendant class

virtually impossible to do in C#

no new exceptions types are allowed to be thrown, unless they are sub classes of previously used ones

preconditions cannot be strengthened in a subtype

- can't change assumptions of the base class (might cause breakage)

postconditions cannot be weakend in a subtype

history constraint - can't change immutable property or value

** don't change to break an existing application **

abstract base classes and interfaces ~ 44:30 min

Benefits: new pluggable classes without breaking existing classes

Interface Integration Principle

Clients should not be forced to depend upon interfaces that they don't use

breaking into small interfaces makes it easier to implement

avoid notImplementedException that breaks Liskov's principle

small pieces

Membership provider -

Dependency Inversion

High level should not depend on low level, depend on abstraction

by making sure classes don't depend on specific implementations, it becomes easy to change things around...

don't premature optimize

KISS, may not be needed, don't go too far (like DB normalization)

refactor later, if not needed now



50 vs 230 lines of code

Posted on Thursday, August 28, 2014 10:33 AM Pragmatic Programming | Back to top

Comments on this post: Notes from a TechEd talk on SOLID principles

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Aligned | Powered by: