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

Scrum teams have too many meetings is perhaps the most common criticism of Scrum. But is it valid? [...]

- mike@mountaingoatsoftware.com

Here are five key lessons I learned that were instrumental in my career. See if learning them could [...]

- mike@mountaingoatsoftware.com

A team’s sprints should be the same length every sprint. Here are four reasons why. [...]

- mike@mountaingoatsoftware.com

Read this special Halloween post about five things in agile transitions that are can seem as scary a [...]

- mike@mountaingoatsoftware.com

If you want to overcome problems and improve how you work with user stories, register now through Oc [...]

- Scott Hanselman

In 2016 and 2015 I made a list of best Christmas STEM Toys for kids! If I may say so, they are still [...]

- Scott Hanselman

I'm glad you have a 1080p 60fps accelerated graphics setup, but I'm old school. Impress me [...]

- Scott Hanselman

Visual Studio Code has a HUGE extension library. There's also almost two dozen very nice Azure [...]

- Scott Hanselman

I got an email this week asking how to download some of my Azure Friday video podcast videos from ht [...]

- Scott Hanselman

There's a couple of great utilities that have come out in the last few weeks in the .NET Core w [...]

Meta