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) {
    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>();

Continue reading

Handling Exceptions and Errors. Part 1 – Intro.

In this article we will discuss exception handling best practices. There is a lack of meaningful information about exception handling on the Internet, so let’s go.
Have you ever seen that recommendation to avoid exception handling like this:

try { 
    //do something 
catch(Exception ex) { 

Well, indeed, I agree that this exception handler looks pretty bad. But is it helpful to know only that? No, it is not. The problem of proper errors\exceptions handling is very far from being popular. There are some articles on the Internet, but I feel like there’s a lack of information on that topic, and this problem should be popularized among at least junior and middle developers.

Continue reading

Null-Checking Semantics Obscurity

This topic is going to be simple, yet an interesting one. I’ll try to expose here my feelings about a certain case of null-checking.
It’s a well-known fact that introducing null-values considered by its inventor, Tony Hoare, as a billion-dollar mistake. Despite of some “modern” practices like making classes immutable, applying Null-Object pattern or using Code Contracts extensively, we still often want to declare an instance of an object as null (no instance). I’m not going to discuss the fundamental problem of null-values. Instead of that, I just want to consider a specific case concerning null-checking.
Several months ago I was reading some code in a ViewModel and stumbled upon a method implemented as it follows:

bool CheckCard(CardDescription description, out CardReadingResult readingResult) {
    readingResult = null;
    if (description != null) {
        CardReadingResult r = device.SearchForCard(description.CardType);                
        if (r == null)
            Notify("Card was not inserted.");               
        else {
            var info = CardInfoParser.GetInfo(r.CardInfo);
            if (info.Number == description.Number) {
                readingResult = r;                        
    return readingResult != null;

Continue reading

Refactoring: Extract a Method, When It’s Meaningful

Big Functions Hell

Well, now it’s hard to remember the moment, when I first time realized that it’s actually a good idea to extract functions from the massive chunks of useful code. Either I got this knowledge from the “Complete Code” or “Clean Code” – it’s hard to recall. Actually, it does not matter so much. We all know that we should split the business logic into well named functions. The longest function I’ve seen in my life was longer than 5k lines. I’m personally acquainted with that “programmer”. I remember when I first time faced that function. It’s not difficult to predict, that my very first reaction was – “WTF!!! Who made this piece of shit???” Yep, and that “programmer” is still hanging around in the office where I’m working on. I don’t want to get deeper into this story, but I want to mention that the 5k-lines-function was the core of the ~150k-lines program. That program was eventually driven to a corner because of that piece of shit, which tremendously influenced on the whole architecture of the application. In the end, the decision was made to rewrite that program completely from the ground.

Continue reading