Getting Started with Software Architecture in C# or VB.NET (Part 2)

Home » Agile Techniques » C# » Software Architecture and Design » Getting Started with Software Architecture in C# or VB.NET (Part 2)
Cartoon of a person sitting at a computer with lots of code windows

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

www.hanselminutes.com

www.dotnetrocks.com

http://www.dnrtv.com/

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.

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

It’s important for most agile teams to estimate both their product and sprint backlogs. But why? [...]

- mike@mountaingoatsoftware.com

This new video series is the perfect primer for Scrum. It’s great prep for the Certified Scrum Maste [...]

- mike@mountaingoatsoftware.com

An agile product backlog should evolve over time, with product backlog items and user stories rising [...]

- mike@mountaingoatsoftware.com

Succeeding with Scrum is easier when you know when and why to conduct each ceremony during the sprin [...]

- mike@mountaingoatsoftware.com

Are you struggling to find a catchy name for your agile team? Use this fun, mostly silly, generator [...]

- Scott Hanselman

OK, maybe not technically a microservice, but that's a hot buzzword these days, right? A few we [...]

- Scott Hanselman

I've been doing .NET image processing since the beginning. In fact I wrote about it over 13 yea [...]

- Scott Hanselman

This blog post is an update to these two Diabetes Technology blog posts: The Promising State of Diab [...]

- Scott Hanselman

I was looking at a Well Known Open Source Project on GitHub today. It had like 978 Pull Requests. A [...]

- Scott Hanselman

I got a very strange warning recently when building a .NET Core app with "dotnet build."MS [...]

Meta