Home:ALL Converter>c# interface segregation principle example confusion

c# interface segregation principle example confusion

Ask Time:2014-02-10T00:11:54         Author:user3289921

Json Formatter

I'm fairly new to programming and i'm having trouble to understand how to apply effectively the principle showed in the following link (the ATM one):

http://www.objectmentor.com/resources/articles/isp.pdf

Basically it starts with a design that does not complain the ISP (Interface Segregation Principle), and moves forward to refactor the behavior into different interfaces.

My question is: Don't we use interfaces to express common behaviour among not so (or not) related abstractions?

What's the point of encapsulating methods in an interface, if not even one is going to be shared with the classes that are going to implement them? In which scenario this could be consider useful?

If we continue the line of the example, the following code is given:

public interface ITransaction
{
    void Execute();
}

public interface IDepositUi
{
    void RequestDepositAmount();
}

public class DepositTransaction : ITransaction
{
    private IDepositUi depositUI;

    public DepositTransaction(IDepositUi ui)
    {
        depositUI = ui;
    }

    public virtual void Execute()
    {
        /*code*/
        depositUI.RequestDepositAmount();
        /*code*/
    }
}

public interface WithdrawalUI
{
    void RequestWithdrawalAmount();
}

public class WithdrawalTransaction : ITransaction
{
    private WithdrawalUI withdrawalUI;

    public WithdrawalTransaction(WithdrawalUI ui)
    {
        withdrawalUI = ui;
    }

    public virtual void Execute()
    {
        /*code*/
        withdrawalUI.RequestWithdrawalAmount(); /*code*/
    }
}

public interface TransferUI
{
    void RequestTransferAmount();
}

public class TransferTransaction : ITransaction
{
    private TransferUI transferUI;

    public TransferTransaction(TransferUI ui)
    {
        transferUI = ui;
    }

    public virtual void Execute()
    {
        /*code*/
        transferUI.RequestTransferAmount();
        /*code*/
    }
}

public interface UI : IDepositUi, WithdrawalUI, TransferUI
{
}

As far as i understand this, in order to use the previous design we should have something like:

UI impui = new IMPLEMENTATIONUI(); // Some UI implementation
DepositTransaction dt = new DepositTransaction(Gui);
dt.Execute();

Now, wouldn't we need that the IMPLEMENTATIONUI implements every single method? And if so, wouldn't it break the SRP?.

Author:user3289921,eproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article:https://stackoverflow.com/questions/21661478/c-sharp-interface-segregation-principle-example-confusion
Kyle B :

Don't we use interfaces to express common behaviour among not so (or not) related abstractions?\n\nYes, in SOLID, interfaces are required to express common behavior. Your Transaction interface is a superb example of this. Both the DepositTransaction and WithdrawlTransaction classes depend on it. ISP (Interface Segregation Principle) wants you to split this out because you may have a need to pass a Transaction object into a function to execute it. All of the SOLID principles are designFor example:\n\nvoid ExecuteTransaction(Transaction transaction)\n{\n transaction.Execute();\n}\n\n\nPlease note that this method does not depend on anything but the Transaction interface. This is dependency inversion.\n\nIf you do not create this interface you would need to create two different methods for executing a WithdrawlTransaction or a DepositTransaction; instead, you can use the ExecuteTransaction method and pass in anything that implements Transaction. \n\nExecuteTransation(withdrawl_TransactionObject);\n\n\nor\n\nExecuteTransaction(deposit_TransactionObject);\n\n\nor later in the future:\n\nExecuteTransaction(unanticipatedNewTypeOf_TransactionObject);\n\n\nNow, wouldn't we need that the IMPLEMENTATIONUI implements every single method? And if so, wouldn't it break the SRP?\n\nThe Implementation UI is probably what the user uses to interact with the software. The user won't have a Single Responsibility, theoretically he/she will have to use all the interfaces that are required for the IMPLEMENTATIONUI class.\n\nI doubt the implementation UI would implement all of the interfaces but it would likely use all of these interfaces in order to execute transactions. To paraphrase \"Uncle Bob\" Solid Principles your user interface should be full of Volatile code while your interfaces should be the most non-volatile.",
2017-04-07T13:54:27
yy