SOLID : Open / Closed Principle

The Open / Closed Principle focuses on one basic requirement, the classes should be Open for extensions, but closed for modification.

The better way to explain the principle would be to first express the issue in hand. Consider the below class.

image

The class itself looks good, but what if in future one needs to add another Shape, say Circle. This would raise need to modify our existing class which is violation of OCP.

The solution to problem lies in achieving extension by deriving from abstraction. Let’s rewrite the code.

image

As you can see in the above implementation, we have created an abstract class with the function we might require extension. The corresponding classes, Square and Circle, implement this abstract class and extend its functionality. So when the requirements changes, and you need to extend, you needn’t change the existing classes. This means the classes which are properly tested needn’t be touched again and thereby reduce chances of introducing bugs in existing classes.

The Chain Of Responsibility Pattern is yet another way of achieving Open Closed Principle

SOLID : Single Responsibility Principle

While OOPs is rich with features like inheritance, polymorphism, encapsulation and overloading enabling developers to extract more from modern day programming languages like C#, it is equally important to understand when to use these features based on design principles.

SOLID, is a set of 5 principles which when properly applied intend to guide a programmer to make systems that is scalable and maintainable with ease.

The first of SOLID Principles, (S) – Single Responsibility Principle (SRP) demands that a class should have only a single responsibility and that responsibility should be fully encapsulated by that a class.

Consider the following class. The class is intended to Book Movie Tickets.

image

If you observe the class, the method BookTicket is divided into two parts. First, it books the tickets and then it notify the User about the same. That is, the class has two responsibilities – Book Tickets and Notify User, in other words, there are two reasons for which the class can be changed.

Suppose few years later, the company decides to change the notification mechanism and include SMS support as well. This would mean our MovieTicket Class needs to be altered for a reason (user notification), which has nothing to do with the core functionality of the class (booking ticket).

This is violation of SRP and the obvious solution would be to separate the responsibilities to separate classes.

image

This ensures that each class has only one responsibility and there would be only reason to change it.

Composite Primary Key using Data Annotations

When developing domain classes in Entity Framework using Code First Approach, the default code conventions creates a primary key of a property named “ID” or <ClassName>ID. But if you wanted to use another property as your primary key , you can use DataAnnotations and decorate the property using “Key” attribute.

What is more interesting is that you could actually create a composite primary key. All you need to do is use another attribute along with “Key”, namely, “Column”.

image

The above example creates a Table with a Composite Primary Key made up of Dept1 and Dept2. Entity Framework is surely letting the developers live in the comfort zone of Visual Studio rather than dig up SQL Server.

Singleton using Lazy(T)

Singleton Design Pattern is probably the simplest and most straightforward design pattern. So instead of explaining further, let me get to the code.

image

The whole idea behind the above implementation of Singleton is to make use of the Lazy(T) class provided by Framework 4.0 and provide a lazy initialized version of the pattern, in addition to being thread-safe.

Evil Code 0002 Optional Parameter Vs Method Overloading

Again one of those things which looks so simple, but could drive one mad during debugging.

Much before Optional Parameters came in, C# developers used to depend on Method Overloading for mimicking Optional Parameters. Consider a scenario where both exists, what would be the output ?

Image

The output would be :

Image

The reason behind this is the overload resolution method adopted when we have a overloaded method and a method with optional parameter. Here is what MSDN says.

If two candidates are judged to be equally good, preference goes to a candidate that does not have optional parameters for which arguments were omitted in the call. This is a consequence of a general preference in overload resolution for candidates that have fewer parameters.