This post is part 2 of an introduction to Software Architecture in C# or VB.NET. Part 1 covered some concepts, this post goes into a little more detail about programming by interface and SOLID principles by Uncle Bob Martin.
Programming by Interface
An interface is another layer of abstraction. Why bother? I’ve heard this from many people, especially people who are more inclined to look at the existing system to work out what to change, rather than look to a design of how things should be. I blogged about this a while ago.
Programming by Interface is an important concept whether you are interested in TDD or not, because it allows you to control (by explicitly defining) how different modules link together, i.e. dependencies. It also allows you to plug in TDD on anything you see fit, e.g. complex business logic that is absolutely fundamental to the working of your system.
Interfaces can be inherited just like classes can. It’s the interfaces that define functionality and dependencies, the concrete classes just come in to fulfil the needs of an interface at runtime.
This is where Dependancy Injection (DI) is typically used, just to plug in concrete classes when needed – for a certain part of the design. So you use new statements (or factories) in your design for certain classes, and DI instead of new statements of another set of classes. E.g. Model’s, Forms and Reports are not injected. Objects that work on the model typically are.
Interface vs Abstract Classes
These are more or less the same thing but slightly different. Abstract classes can provide some functionality (an interface can provide none), and also have a parent, so only single inheritance is allowed. Abstract classes should only really be used for “IS A” not “HAS A” relationships.
Programming by Interface is the most important concept I will blog about in this overview. You should try to learn as much as possible about this because interfaces explicitly control the relationships, i.e. dependencies, between objects. They are very important, not just for those interested in TDD. To find out more, apart from search for terms like “Programming by Interface” search for terms like “Composition over Inheritence”. Wikipedia has an example of Composition over Inheritence.
SOLID Principles
Uncle Bob Martin came up with the SOLDI principles which then were modified to SOLID during an interview with Scott Hanselman on Hanselminutes a while ago.
I am not going to try to define them again – a link to Uncle Bob at the end of the post does that – but I would like to comment on each of the five main principles:
S – Single Responsibility Principle
Classes and methods should do just “One” thing.
The “One” is a matter of judgement viewing all your code in context. It doesn’t mean that each method can only be one line of code!!
You end up with many small classes and methods, which actually are easy to name because although you have a lots of them, because they only do one thing, they are easy to name. Class, methods, variable names should be descriptive (no need for comments).
Also cross cutting concerns can be implemented via helper methods (one place where statics are used) and they can be put in to certain classes (or injected in via DI or PostSharp).
O – Open / Closed Principle
Classes should be open for extension, closed for modification. So inheritance is always needed. One of the key OOD principles is to encapsulate what changes. So when decided what to put in a class and what can be virtual, this is a good guideline.
L – Liskov Substitution Principle
When using a class, you should be able to substitute any other sibling into that code without breaking it. The rectangle/square problem is a good one – I’m not going to go through it all here – but its down to should a rectangle inherit from a square (or vice versa). The answer – not it should not. Because they are different shapes and it would also violate this principle.
I – Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they do not use (Clients being any consumer of an object, i.e. another object). This is about the structure of the interfaces between classes, keeping them small. This does not mean that you alter the layers in a layered system (see Microsoft Application Architecture Guidelines). For example, a DAL could / should? Have lots of small interfaces but containing say all the columns in a given table, the Business Layer could take advantage of whatever it needs without having to change the DAL to add extra columns etc. that are already in the table, but the façade layer that delivers the data to the UI (via WCF or otherwise) could have bigger, amalgamated classes that contain all the data needed in that transaction so only one call is required, specifically for that interaction.
D – Dependency Inversion Principle
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. This is ultimately about having the references in your visual studio project pointing the “Right” way, e.g. if you have circular references you are probably missing a layer of abstraction.
http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html is one of the best intro’s I’ve found on the web.
The book Agile Principles, Patterns and Practices explains SOLID far better than I can – see below.
Whats Next
Now that I’ve summarised what I think are important concepts, in future posts I’ll go into more detail as I come across examples etc.
Further Information – Links
SOLID
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod – definitive guide from Uncle Bob’s Blog
http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html – A good introduction
Microsoft Application Architecture Guidelines
A very good read
https://msdn.microsoft.com/en-us/library/ff650706.aspx
More about Dependency Injection (DI)
(I don’t recommend Unity because its slow but it’s a good tutorial):
https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx
More Links
A couple of interesting shows from Dot Net Rocks:
https://www.dotnetrocks.com/?show=1235 – very interesting bit about technical debt
https://www.dotnetrocks.com/?show=727 – Steve McConnell – author of Code Complete and www.construx.com
Uncle Bobs videos are very good and are available at a price on https://cleancoders.com/.
There may be a few examples on his site that are free – and he is not on Pluralsight unfortunately.
However searching for SOLID on YouTube is another possibility.
Further Reading – Books
If you are going to read just one book, then Head FIrst Object Orientated Design is the one followed by Agile Principles, Patterns and Practices in C#
The books are listed in approximately the order you should read them if you haven’t read anything on the subject.
Beginners
Intermediate
Advanced
This post has not mentioned anything about the core C# programming skills that every C# programmer should have – see my page on C# programming books for further information.
Leave a Reply