Skip to main content

SOLID (4/5) - Interface segregation principle

Interface segregation principle


In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

using System;

namespace interfacesegregation
{
    public class Document 
    {

    }

    public interface IMachine 
    {
        void Print(Document d);
        void Scan(Document d);
        void Fax(Document d);
    }

    public class MultiFunctionPrinter : IMachine 
    {
        public void Print(Document d
        {
            //
        }

        public void Scan(Document d)
        {
            //
        }

        public void Fax(Document d)
        {
            //
        }
    }

    // The interface has too much functionaly that won't be used
    public class Printer : IMachine 
    {
        public void Print(Document d
        {
            //
        }

        public void Scan(Document d)
        {
            throw new NotImplementedException();
        }

        public void Fax(Document d)
        {
            throw new NotImplementedException();
        }
    }    

    // We should separate the interface into smaller ones 
    public interface IPrinter 
    {
        void Print(Document d);
    }

    public interface IScanner 
    {
        void Scan(Document d);
    }

    public class Photocopier : IPrinterIScanner
    {
        public void Print(Document d
        {
            //
        }

        public void Scan(Document d)
        {
            //
        }
    }

    public interface IMultiFunctionDevice : IPrinterIScanner
    {        
    }

    public class MultiFunctionMachine : IMultiFunctionDevice
    {
        public void Print(Document d
        {
            Console.WriteLine("Printing...");
        }

        public void Scan(Document d)
        {
            Console.WriteLine("Scanning...");
        }
    }


    public class Program
    {
        static void Main(string[] args)
        {
            var machine = new MultiFunctionMachine();
            machine.Scan(new Document());
            machine.Print(new Document());
        }
    }
}

Comments

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...

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 {      ...

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; }   ...