Skip to main content

SOLID (1/5) - Single Resposibility Principle

 SOLID (1/5) - Single Resposibility Principle


The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.

In the following example we have a TodoList class which only handles it's own functionality logic, and then we have a Persistance class which handles the saving logic, hence keeping the concerns separeted.

using System;
using System.Collections.Generic;

namespace Journal
{
    public class TodoList
    {
        private readonly List<string> _entries = new List<string>();
        private static int _count = 0;

        public int AddEntry(string entry)
        {
            _entries.Add($"{++_count} : {entry}");
            return _count;
        }

        public void RemoveEntry(int index)
        {
            _entries.RemoveAt(index);
        }

        public override string ToString()
        {
            return string.Join(Environment.NewLine, _entries);
        }
    }

    public class Persistance
    {
        public void Save(TodoList todoList)
        {
            // saving logic
        }
    }


    class Program
    {
        static void Main(string[] args)
        {
            var todoList = new TodoList();
            todoList.AddEntry("dentist");
            todoList.AddEntry("shopping");
            todoList.AddEntry("wash the car");

            Console.WriteLine(todoList);

            var persistance = new Persistance();
            persistance.Save(todoList);
        }
    }
}
Labels:

Comments

Post a Comment

Popular posts from this blog

Software Development

Software Development Agile Agile is an insurance policy for market changes. By designing your solution according to this methodology, your project remains flexible and is always ready for change. It is always better to correct the mistake early in the process. With this method, you keep your finger on the pulse of a dynamic market and changing user expectations. As a result, you can continuously adapt, change your strategy, and create a product that will be in demand by the target audience, even if preferences have changed during the development process. DevOps DevOps is one more way to optimize the development budget of your application. A key DevOps approach is that this practice and its culture allow team members to better interact with each other and the customer. The software development team and those responsible for the operation of the application share responsibilities clearly, and it helps you avoid shifting responsibilities from one team member to another. DevOps involves th...
Post a Comment
Read more

Abstract Factory Pattern

Abstract Factory Pattern  Gamma Categorization: Creational Design Patten Summary: When the object construction is complicated, needing multiple arguments, we should create a separate function (Factory Method) or class (Factory), which is responsible for the creation of the all object. Problem examples Suport of multiple databases Multiple data sources: Serial port, ethernet port, device driver Diferent report types Solution Abstract class Generalized interface A Factory creates instances of the concrete classes Sample Code The abstract factory public   interface   IPhotoFactory {      IAnaloguePhoto   CreateAnaloguePhoto ();      IDigitalPhoto   CreateDigitalPhoto (); } The abstract products public   interface   IAnaloguePhoto {      string   GetName (); } public   interface   IDigitalPhoto {      ...
Post a Comment
Read more

SOLID (3/5) - Liskov substitution principle

  SOLID (3/5) - Liskov substitution principle Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. using   System ; namespace   Liskov {      public   class   Rectangle     {          //public int Width { get; set; }   ...
Post a Comment
Read more