Single Responsibility Principle – SRP

This entry is part 3 of 3 in the series SOLID

SRP Definition

In this article, we will look at what is single responsibility principle and look at some simple examples in C# which demonstrate the single responsibility principle and how to adhere to the SRP.
Single Responsibility Principles or SRP in short states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. This is the definition taken from Wikipedia. It’s very hard to understand what does it mean. For example, the first two questions which come to my mind are:

  • how to define those responsibilities?
  • how to calculate the number of responsibilities of a certain class?

Continue reading

Software Architecture: Meta and SOLID Principles in C#

This entry is part 1 of 3 in the series SOLID

Learn how to develop maintainable software systems applying Meta and SOLID Principles.

Teaching Approach

No fluff, no ranting, no beating the air. I esteem your time. The course material is succinct, yet comprehensive. All important concepts are covered. Particularly important topics are covered in-depth. For absolute beginners, I offer my help on Skype absolutely free, if requested.

Take this course, and you will be satisfied!

SOLID is an acronym which stands for SRP, OCP, LSP, ISP and DIP. These five acronyms in their turn stand for:

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

In this course, you’ll learn how to apply meta and SOLID principles so that your application will live a long healthy life. It means you are going to learn how to write code of the high quality: readable, understandable and reliable.

Continue reading

Abstract Class VS Interface in C#

You can open any C# tutorial and you’ll find some information about abstract classes and interfaces. Most likely, you’ll not find any information about what is the difference between abstract class and interface.
This theme was discussed earlier on the Internet several times but I want to consolidate all the most important thoughts regarding the problem of choosing between an abstract class and interface in this post.
Continue reading

Designing and Implementing API in C#

Nowadays I’m writing my new programming video course. I chose an interesting topic for the next course: “Designing and Implementing API in C#”.

How to design API? In this course, you’ll learn how to design and implement types in C# so that the other developers won’t hate you when using one of the types developed by you. It means you are going to learn how to write code of the high quality: readable, understandable and reliable.

Improve your knowledge in object-oriented programming in the context of clean coding and building types of high quality.

  • Understand the characteristics of a well designed type
  • Grasp the principles of the convenient API development
  • Write clean code, get rid of unpleasant smells
  • Learn about what exceptions are intended for and how to throw and catch them properly
  • Protect your types from the incorrect usage making them properly encapsulated

And this is far from the full list of topics we will cover in this course.
Continue reading

MVVM: When EventAggregator (aka MessageBus) is an Anti-Pattern

Very often we can see that developers tend to use static message buses for all kind of interactions between objects. For those, who unaware of this pattern I want to recall that this pattern allows organizing loosely coupled communication channel between objects which don’t want (or can’t) to know each other.
Let’s have a brief look at how a regular example of using this pattern may look like:

public class Sender {
    private readonly IEventAggregator eventAggregator;

    public Sender(IEventAggregator eventAggregator) {
        this.eventAggregator = eventAggregator;
    }

    public void Action() {
        eventAggregator.Publish(new Message());
    }
}

public class Receiver : IHandle<Message> {
    public Receiver(IEventAggregator eventAggregator) {
        eventAggregator.Subscribe(this);
    }
    public void Handle(Message message) {            
    }
}

Continue reading

Money Type as Value Object, or Don’t Rely on Primitive Types!

Primitive Types Obsession Problem

Today I’m going to discuss the problem of using primitive types instead of abstractions. This problem was discussed in the blog of Mark Seemann. Read it, if you haven’t read it yet.
In this post I’m going to talk about Money type as an abstraction instead of using decimal type for representing money-values.
In the last project I’ve been participating in, we relied on a decimal and integer types for a long time. From the beginning, we knew that using primitive types for values of that kind is an anti-pattern, but we stubbornly have been using them. In the US there are cents and dollars. In the Russian Federation – rubles and kopeks. 1 ruble = 100 kopeks. Our system inter-operated with an external system which performed all its calculations in kopeks. So it required kopeks as the input and returned kopeks as the output. If we wanted to pass in 2rubles and 50kopeks, then we passed in Int32 amount = 250;

Continue reading

When Method Is Better Than Property?

That’s a well known question. Actually, I knew the difference between methods and properties long ago. Despite of that, recently I stumbled upon my own incorrect choice between those semantic constructions. That’s why I decided to write this post – in order to solidify the understanding of the difference between property and method.

Method vs Property fail in BCL

The most notorious fail of creating a property inside the BCL (FCL) in .NET instead of a method is the DateTime.Now property. In my opinion, this particular case is not the worst in history, though it’s an embarrassing one. So, what’s wrong with that the DateTime.Now is implemented as a property rather than a method? This isn’t wrong from the point of the actual implementation, it is implemented correctly, the point is that this is semantically wrong from the API design perspective. If every time the getter of a property returns different values, then this is a method, not a property. Why? Because a property is an attribute of an entity. For example, Year is an attribute of a Date, so it would be correct to get the year as it follows: DateTime.Now().Year. Yes, that’s it, that’s how it should look like, not like a chain wreck – DateTime.Now.Year. By the way, similar by the case Guid.NewGuid() member is implemented as a method. In this case, the word “New” dictates that this should be a method, but for example they could have named it Guid.Next and even in this case it should be a method, as well as the DateTime.Now!

Continue reading

Hidden Dependencies as a Smell

Mark Seemann has written a nice post  “Service Locator violates encapsulation”. The name of the post speaks for itself that it’s about a pattern (anti-pattern) named Service Locator. When a programmer arbitrarily inside the code base calls for the IoC-container to resolve a dependency of an object – he uses a Service Locator anti-pattern. Mark provides the following example:

public class OrderProcessor : IOrderProcessor
{
    public void Process(Order order)
    {
        var validator = Locator.Resolve<IOrderValidator>();
        if (validator.Validate(order))
        {
            var shipper = Locator.Resolve<IOrderShipper>();
            shipper.Ship(order);
        }
    }
}

Continue reading