InterfaceSegregation.razor

@page "/blogs/interface-segregation-principle-in-solid"
@inherits FragmentNavigationBase
@inject TableOfContents tableOfContents

<Content Description=@Description
         Slug=@Slug
         PosterPath=@PosterPath
         Channel="@Channel"
         ContentType="@ContentType"
         TotalContents=@TotalContents
         Type="SOLID"
         FileName=@nameof(InterfaceSegregation)>
    <ContentBody>
        <p>
            In this article, let's learn about <ContentHighlight>Interface Segregation Principle</ContentHighlight> in <ContentHighlight>SOLID</ContentHighlight> Principles 
            in .NET.
        </p>

        <p>
            <strong>Note:</strong> If you have not done so already, I recommend you read the article on
            <NavLink class="[ underline ]" href="blogs/liskov-substitution-principle-in-solid" Match="NavLinkMatch.All">Liskov Substitution Principle in SOLID</NavLink>.
        </p>

        <h3 class="[ font-semibold text-lg ]">Table of Contents</h3>
        
        <ol class="[ list-decimal ] [ ml-4 ]">
            <li>
                <NavLink class="[ underline ]" href="@($"blogs/{Slug}#introduction")" Match="NavLinkMatch.All">
                    Introduction
                </NavLink>
            </li>
            <li>
                <NavLink class="[ underline ]" href="@($"blogs/{Slug}#when-to-apply-isp")" Match="NavLinkMatch.All">
                    When to apply ISP?
                </NavLink>
            </li>
            <li>
                <NavLink class="[ underline ]" href="@($"blogs/{Slug}#demo")" Match="NavLinkMatch.All">
                    Demo
                </NavLink>
            </li>
            <li>
                <NavLink class="[ underline ]" href="@($"blogs/{Slug}#advantages")" Match="NavLinkMatch.All">
                    Advantages
                </NavLink>
            </li>
            <li>
                <NavLink class="[ underline ]" href="@($"blogs/{Slug}#summary")" Match="NavLinkMatch.All">
                    Summary
                </NavLink>
            </li>
        </ol>

        <h3 id="introduction" class="[ font-semibold text-lg ]">Introduction</h3>
        
        <p>
            The <ContentHighlight>Interface Segregation Principle (ISP)</ContentHighlight> is essential for creating software that is easy to maintain and scale. It ensures 
            that clients are <ContentHighlight>only exposed to the methods they require, and not to methods that are unnecessary</ContentHighlight>. By doing so, it keeps 
            <ContentHighlight>interfaces</ContentHighlight> lean and reduces the complexity of the codebase.
        </p>

        <p>
            Without ISP, interfaces can become bloated, and it can be challenging to maintain them. If an interface has too many methods, it can become a barrier to change. 
            Any modification to the interface requires clients to update their implementation, which can be a time-consuming and error-prone process.
        </p>

        <p>
            The Interface Segregation Principle states that clients <ContentHighlight>should not be forced to implement interfaces they don't use</ContentHighlight>. Instead, 
            interfaces should be designed to be specific to the needs of the clients that use them.
        </p>

        <p>
            To put it simply, this principle suggests that you should break large interfaces into smaller, more specific ones that are easier to manage and maintain. Clients 
            should only depend on the methods that they need, and not on the methods that are irrelevant to them.
        </p>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <h3 id="when-to-apply-isp" class="[ font-semibold text-lg ]">When to apply ISP?</h3>

        <p>
            You should use the Interface Segregation Principle when you have a <ContentHighlight>large interface with many methods, but some clients don't use all of them</ContentHighlight>. 
            You should break this interface into smaller, more specific ones that are easier to manage and maintain.
        </p>

        <p>
            For instance, if you have an interface that has methods for both hot and cold beverages, but some clients only deal with cold beverages, you should separate the 
            cold beverage methods into their own interface. Clients that only need to work with cold beverages can then implement this smaller, more specific interface, while 
            clients that need to work with both hot and cold beverages can implement the larger interface.
        </p>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <h3 id="demo" class="[ font-semibold text-lg ]">Demo</h3>

        <p>
            Let's take an example of a Coffee Machine <ContentHighlight>interface</ContentHighlight>. Assume that there are two classes - <ContentHighlight>ColdBrewCoffeeMaker</ContentHighlight> 
            and <ContentHighlight>MokaEspressoMaker</ContentHighlight>, which implement all the functionality defined in the <ContentHighlight>ICoffeeMachine interface</ContentHighlight>. 
            This <ContentHighlight>interface</ContentHighlight> has four methods - <ContentHighlight>AddCoffee</ContentHighlight>, <ContentHighlight>AddWater</ContentHighlight>, 
            <ContentHighlight>GetColdCoffee</ContentHighlight>, and <ContentHighlight>GetExpressoCoffee</ContentHighlight>.
        </p>

        <GithubGistSnippet Title="ISP - Interface Segregation Principle - Before" UserId="fingers10" FileName="b645c99d92a825768b91660cb522b153"></GithubGistSnippet>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <p>
            The Interface Segragation Principle ensures that we can split the <ContentHighlight>interface</ContentHighlight> as we have not implemented method in both of the them. 
            So we create two additional <ContentHighlight>interfaces</ContentHighlight>: <ContentHighlight>IColdCoffeeMachine</ContentHighlight> and <ContentHighlight>IEspressoMachine</ContentHighlight>. 
            <ContentHighlight>IColdCoffeeMachine</ContentHighlight> extends <ContentHighlight>ICoffeeMachine</ContentHighlight> and adds the <ContentHighlight>GetColdCoffee</ContentHighlight> 
            method, while <ContentHighlight>IEspressoMachine</ContentHighlight> extends <ContentHighlight>ICoffeeMachine</ContentHighlight> and adds the <ContentHighlight>GetEspressoCoffee</ContentHighlight> method.
        </p>

        <GithubGistSnippet Title="ISP - Interface Segregation Principle - After" UserId="fingers10" FileName="68a94018072950b8e36042186365100b"></GithubGistSnippet>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <p>
            This allows us to use the <ContentHighlight>ColdBrewCoffeeMaker</ContentHighlight> with only the <ContentHighlight>IColdCoffeeMachine</ContentHighlight> 
            <ContentHighlight>interface</ContentHighlight>, and the <ContentHighlight>MokaEspressoMaker</ContentHighlight> with only the <ContentHighlight>IEspressoMachine</ContentHighlight> 
            <ContentHighlight>interface</ContentHighlight>. We can no longer use the <ContentHighlight>ColdBrewCoffeeMaker</ContentHighlight> as a general <ContentHighlight>ICoffeeMachine</ContentHighlight>, 
            since it doesn't implement the <ContentHighlight>GetEspressoCoffee</ContentHighlight> method, and vice versa for the <ContentHighlight>MokaEspressoMaker</ContentHighlight> 
            and <ContentHighlight>GetColdCoffee</ContentHighlight>.
        </p>

        <p>
            Using the interface segregation principle in this way results in cleaner and more maintainable code. We no longer have to implement methods that are not relevant 
            to a particular class, and we can prevent accidental misuse of our code by limiting the available methods to only those that are necessary.
        </p>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <h3 id="advantages" class="[ font-semibold text-lg ]">Advantages</h3>

        <p>
            The Interface Segregation Principle has several advantages, including:
        </p>

        <ul>
            <li><ContentHighlight>Encourages Modularity and Extensibility</ContentHighlight>: By segregating interfaces, each interface becomes smaller and focused on a specific functionality. This encourages modularization of code and makes it easy to extend the application by adding new functionality through new interfaces.</li>
            <li><ContentHighlight>Improves Code Readability and Maintainability</ContentHighlight>: Interfaces that are not cluttered with unnecessary methods are easier to read and maintain. This makes the code more understandable and less prone to errors, leading to better quality software.</li>
            <li><ContentHighlight>Reduces coupling and Improves testability</ContentHighlight>: By separating interfaces into smaller, more focused interfaces, we can reduce the coupling between classes. This makes the code more modular and easier to test. We can test each interface in isolation, which helps to identify any issues in the interface early in the development process.</li>
            <li><ContentHighlight>Increases Code Reusability</ContentHighlight>: Interfaces that are designed with the ISP in mind can be reused in multiple projects. This saves time and effort by reducing the need to write new code for each project.</li>
        </ul>

        <GoogleAdSense Type="GoogleAdSenseAdType.InArticle" Format="GoogleAdSenseAdFormat.Fluid" Style="text-align:center;" Slot="3914293965"></GoogleAdSense>

        <h3 id="summary" class="[ font-semibold text-lg ]">Summary</h3>

        <p>
            The <ContentHighlight>Interface Segregation Principle</ContentHighlight> is an essential part of the SOLID principles in object-oriented design. It states that a 
            <ContentHighlight>client should not be forced to depend on methods it does not use</ContentHighlight>. By separating <ContentHighlight>interfaces</ContentHighlight> 
            into smaller, more focused <ContentHighlight>interfaces</ContentHighlight>, we can <ContentHighlight>reduce coupling</ContentHighlight> between classes, improve 
            <ContentHighlight>code readability</ContentHighlight> and <ContentHighlight>maintainability</ContentHighlight>, and increase <ContentHighlight>code reusability</ContentHighlight>.
        </p>
    </ContentBody>
</Content>

@code {
    private string Description = "In this post I will teach you Interface Segregation Principle in SOLID Principles in .NET. All with live working demo.";
    private string Slug = "interface-segregation-principle-in-solid";
    private string PosterPath = "Blogs/SOLID";
    private string Channel = "solid";
    private string ContentType = "blogs";
    private ushort TotalContents => (ushort)tableOfContents.Contents.Count(content => content.Type.Equals("SOLID", StringComparison.CurrentCultureIgnoreCase));
}