pattern

There are 5 posts tagged pattern (this is page 1 of 1).

Interface Segregation Principle (ISP) in C#

In my previous articles I wrote about Solid Principles in C#.

In this article, I am going to show you when and how to use the Interface Segregation Principle in C# with an example project. You can find the repository on GitHub.

The master branch shows the initial code used in the example.  There are separate tags and branches for each of the all solid principles that you can review or download as well. Here are links you can use to jump to these tagged versions in your browser:

What is the Interface Segregation Principle (ISP) in C#?

The Interface Segregation Principle is the fourth of the SOLID design principles. Let us take a look at Robert C. Martin’s definition and try to analyse it.

Clients should not be forced to depend on methods that they do not use.

What’s a Client?

It’s the calling code. It’s the code that is interacting with an instance of the interface.

What does Interface mean in C# for the Interface Segregation Principle (ISP)?

In C# we have two kinds of interfaces described by the ISP.

A type’s interface is whatever can be accessed by a client.

Ok nice description but in the end what do we have to do?

Prefer small and related interfaces to fat ones.

Continue reading →

Liskov Substitution Principle (LSP) in C#

In my previous articles I wrote about Solid Principles in C#.

In this article, I am going to show you when and how to use the Liskov Substitution Principle in C# with an example project. You can find the repository on GitHub.

The master branch shows the initial code used in the example.  There are separate tags and branches for each of the all solid principles that you can review or download as well. Here are links you can use to jump to these tagged versions in your browser:

What is the Liskov Substitution Principle (LSP) in C#?

The Liskov Substitution Principle is one of the SOLID design principles. We can always reuse the definition from Wikipedia but this time will be hard to fully understand…

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

We can transform this sentence in:

If S is a subtype of T, then objects of type T should be replaced with the objects of type S.

Which simply stated means that:

Subtypes must be substitutable for their base types.

Continue reading →

Open Closed Principle (OCP) in C#

In my previous articles I wrote about Solid Principles in C# and the Single Responsibility Principle.

In this article, I am going to show you when and how to use the Open Closed Principle in C# with an example project. You can find the repository on GitHub.

The master branch shows the initial code used in the example.  There are separate tags and branches for each of the all solid principles that you can review or download as well. Here are links you can use to jump to these tagged versions in your browser:

What is the Open Closed Principle (OCP) in C#?

The Open Closed Principle is one of the SOLID design principles. We can always reuse the definition from Wikipedia.

The Open Closed Principle states software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

So these software entities should be:

  • Open For Extension This means that the behavior of the module can be extended, for example we could add fields or new elements in the functions with a fixed behavior,
  • Closed for Modification The source code of such a module is inviolate. No one is allowed to make source code changes to it.

Why should you use the Open Closed Principle (OCP)?

  • Application robust. Don’t break existing code, prefer implementing new features in new classes, follow the SRP, no need to change tested class and less bug.
  • Flexible. Working with interfaces, it’s easy to accommodate new requirements and this reduces the cost of a business change requirement.
  • Better testability. Easy to test and less error prone.

Continue reading →

Single Responsibility Principle (SRP) in C#

In my previous article I wrote about what they are and why to use Solid Principles in C#.

In this article, I am going to show you when and how to use the Single Responsibility Principle in C# with an example project. You can find the repository on GitHub.

The master branch shows the initial code used in the example.  There are separate tags and branches for each of the all solid principles that you can review or download as well. Here are links you can use to jump to these tagged versions in your browser:

What is the Single Responsibility Principle (SRP) in C#?

The Single Responsibility Principle is one of the SOLID design principles. We can reuse the definition from Wikipedia. The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program’s functionality, and it should encapsulate that part. Robert C. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed.

To better understand it, we need to divide the definition into two parts:

  • Single Responsibility A class/method/function should have only a single responsibility.
  • A reason to change A class or method should have only one reason to change. About the “reason” Martin clarified that this principle is about people/role. It is people who request changes.

Why should you use the Single Responsibility Principle (SRP)?

  • Reduction in complexity of a code. A code is based on its responsibility and functionality. So, it reduces the code complexity.
  • Increased readability, extensibility and maintenance. As each method has a single functionality so it is easy to read and maintain.
  • Reusability and reduced error. As code separates based functionality so you can reuse the code somewhere else in an application.
  • Reduced coupling. It reduced the dependency code. A method’s code doesn’t depend on other methods.
  • Better testability. In the maintenance, when a functionality changes then we don’t need to test the entire model.

Continue reading →

Solid Principles in C#

It’s time to talk about a topic that every developer should know to work better regardless of the language or framework used: The S.O.L.I.D principles.

What are the S.O.L.I.D. principles?

The S.O.L.I.D. design principles are a collection of best practices for object-oriented design. The term S.O.L.I.D. comes from the initial letter of each of the five principles that were collected in the book Agile Principles, Patterns, and Practices in C# by Robert C. Martin, or Uncle Bob to his friends.

It was written in 2000, 20 years ago since this article was published. But these Principles are still popular and are still being used widely in the world of OOP Paradigm. You can find the original pdf here https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Yes, you’re not reading it wrongly nor I have a typo. It was written in 2000, 20 years ago since this article was published. But these Principles are still quite popular and are still being used widely in the world of OOP Paradigm.

Why should you use the S.O.L.I.D. principles?

Short answer: Software Rot or Code Rot or Software Erosion is either a slow deterioration of software quality over time or its decreasing responsiveness, which will eventually lead to software becoming faulty, unusable, and in need of upgrade.

Long answer: Software rot refers to the slow degradation in the performance of computer software. Such software shows diminished responsiveness, lacks updates, may become faulty overtime owing to changes in the operating system it is running on and thus may need upgrading.

These are some signs for identifying Software Rot:

  • Rigidity: Difficult to modify the code. New requirements or small changes leads to rebuild the entire software.
  • Fragility: New modifications introduce bugs and vulnerability in the code.
  • Immobility: Non-portability of the code. if a component/module/function cannot be used in another system, this is considered as immobile.
  • Viscosity: When implementing and testing are difficult to perform and also take a long time to execute.
  • Changing Requirements or Changing Needs: Often changes need to be made quickly and may be made by engineers who are not familiar with the code. We cannot dodge the new requirements but we must somehow find a way to make our designs/project resilient to such changes and protect them from rotting.
  • Dependency Management: We know changes introduce new and unplanned for dependencies, so inappropriate module dependencies and increased coupling between systems make the source code more difficult to manage. In order to prevent the degradation of the dependency architecture, the dependencies between modules in an application must be managed.

What will you achieve by using the S.O.L.I.D. Principles?

  • Code More Maintainable
    • Using the Single Responsibility Principle (SRP) and the Open closed principle (OCP) you will be easier in maintaining your code.
  • Code More Flexible
    • It’s quite easy when you need to add features in your code because all codes are loosely coupled.
  • Code More Understandable
    • When you come back to your code six months later, you still understand what you wrote back then.

So what are you waiting for? Try opening your own old project and start applying the principles. You will only see improvements.

(S) Single Responsibility Principle – SRP

The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

(O) Open closed principle – OCP

The Open closed principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

(L) Liskov substitution principle – LSP

The Liskov substitution principle – (LSP) states that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.

(I) Interface segregation principle – ISP

The Interface segregation principle – (ISP) states that no client should be forced to depend on methods it does not use

(D) Dependency inversion principle – DIP

The Dependency inversion principle – (DIP) introduces an abstraction that decouples the high-level and low-level modules from each other.

 

If you think your friends/network would find this useful, please share it with them. I’d really appreciate it.

Thanks for reading! 🌟