Issue #9: DotNet (.NET)

This issue would be about some?topics for DotNet (.NET)?developers.

Notes:

• If you like the content, you can always follow me on?Medium?and?Twitter.
• If you don't already have a?Medium.com?account, you can subscribe through my?referral link?to help me get something back ??
• All article links are?Friend Links. This means that you?don’t?need?Medium.com?Premium Membership to view the articles ??
• I would appreciate?? if you Clap ?? and Comment ?? on my articles on?Medium?following the steps on this GIF (https://lnkd.in/gRM9875z)

When Implementations Affect Abstractions

If you ask a developer if the knowledge of the available implementations could affect his abstractions design, most probably he would say:

No, if this happens then my knowledge of the system is not enough for designing the abstractions.

At some point on my career as a Software Engineer, I would have agreed with this. Actually, I would have provided the same answer if someone asked me the same question.

However, on more than one occasion I came across some solutions which made me change my mind on this.

Long story short, yes, you need to understand your system and the capabilities that should be provided by each module to be able to design your abstractions.?However, this is not enough.

Exploring some of the possible implementations could help you enhance your abstractions.

Ok, let’s say that your knowledge of the system you are designing and all its interactions is a part of your job and you actually need it to do your job.?However, being creative about building this knowledge is something else.

What we are discussing now is how to build this knowledge. One of the best and creative ways is that once you have an abstraction in mind, you try to explore the possible implementations. This would put your mind in an effective state that would help you link too many loose ends.

Mediator Design Pattern In .NET C#

The?Mediator Design Pattern?is one of the behavioral design patterns.

According to?Wikipedia, the definition is as follows:

The essence of the Mediator Pattern is to “define an object that encapsulates how a set of objects interact”. It promotes loose coupling by keeping objects from referring to each other explicitly, and it allows their interaction to be varied independently. Client classes can use the mediator to send messages to other clients, and can receive messages from other clients via an event on the mediator class.

Therefore, to put it in simple words, the?Mediator Design Pattern?is used to manage the interactions between group of objects (similar or not) keeping the the objects isolated from each other.

To understand this, let me explain more with a simple example.

Let’s say that you are implementing a Chat Room. So, you have unlimited number of users who can join the room and once any user sends a message, the message should be received by all other users on the Chat Room.

So, implementing this, you would have a?User?class with?SendMessage?method.

However, you still need to have access to the other Users so that you can direct your the message to them. Also, whenever, a User leaves the Chat Room, you would also need to remove this User from all other Users so that they don’t send a message to him.

You have more than one way to achieve this:

1. Defining a list of Users inside each User and keeping these lists updated whenever a User enters or leaves the Chat Room.
2. Using another class or module to act as the middle man to handle the Users list and the way of sending and receiving the messages between different Users.

The first option would work, but, it is not good because:

1. The?User?class would be doing too many things which are not actually related to its main job.
2. Every?User?now knows about the other users which is not logical.
3. If we want to apply some business rules on which User is allowed to communicate with which User, it would be so hard.
4. Too much processing for maintaining all lists of Users.

Now, if we explore the second option:

1. The?User?class does its job and only job.
2. All the logic of maintaining the Users list is centralized into one class or module.
3. This enables us to easily apply business rules and aggregations if needed.

As you can see, it would be better to go with the second option. Now, let me tell you that what you are going to implement in the second option is the?Mediator Design Pattern.

That’s it, hope you find reading this newsletter as interesting as I found writing it ??

#ahmed_tarek_hasan?#dotnet #csharp #coding #code #programming #development #devcommunity #computerscience #softwaredesign #softwaredevelopment #softwareengineering #softwarearchitecture #bestpractices #designpattern #webdev