Принцип разделения интерфейса: ваш единственный способ стать суперкомпетентным разработчиком

Во время разработки код имеет тенденцию быть длинным. В какой-то момент кодовая база становится настолько раздутой, что вы не можете с ней справиться. Тем не менее старшие разработчики каким-то образом заставляют вещи работать. Как они это делают? "Все разработчики корпоративного уровня активно используют интерфейсы". Итак, сегодня я объясню Принцип разделения интерфейса в одном из SOL'I'D PRINCIPLE. Если вы этого не знали, вам следует знать, что вы отстаете.

Что такое интерфейс разделения интерфейса?

Ни один клиент не должен зависеть от методов, которые он не использует

Принцип разделения интерфейсов также называется ISP для сокращения. Когда вы пишете код, довольно легко нарушить правила ISP, потому что ваше программное обеспечение развивается, и вам нужно добавлять новые функции. Цель ISP — свести к минимуму побочные эффекты за счет разделения программного обеспечения на независимые части. Суть в том, "ВАМ СЛЕДУЕТ ОПРЕДЕЛЯТЬ ТОЛЬКО МЕТОДЫ, КОТОРЫЕ БУДУТ ИСПОЛЬЗОВАТЬСЯ".

Плохая практика

interface IMultiFunction {
    public void print();
    public void getPrintSpoolDetails();
    public void scan();
    public void scanPhoto();
    public void fax();
    public void internetFax();
}

Что вы думаете? Как вы думаете, в приведенном выше примере кода нет ничего плохого?

Во-первых, вам нужно спросить себя, связаны ли методы, определенные внутри IMultiFunction. Очевидно, что print() и getPrintSpoolDetails() связаны. А как насчет print() и scan() ? Все ли принтеры поддерживают эти функции?

Я покажу вам другой пример.

class CanonPrinter implements IMultiFunction {

    @Override
    public void print() {}

    @Override
    public void getPrintSpoolDetails() {}

    /* This machine can't scan */
    @Override
    public void scan() {}

    /* This machine can't scan photo */
    @Override
    public void scanPhoto() {}

    /* This machine can't fax */
    @Override
    public void fax() {}

     /* This machine can't fax on internet */
    @Override
    public void internetFax() {}

}

CanonPrinter не могу fax. Но все равно нужно реализовать fax().

В разработке программного обеспечения «Нереализованные методы почти всегда указывают на плохой дизайн».

Итак, что нужно делать?

Надлежащая практика

Интернет-провайдер начинает с разделения больших интерфейсов на более мелкие интерфейсы.

Давайте рефакторинг!

interface IPrint {
    public void print();
    public void getPrintSpoolDetails();
}

interface IScan {
    public void scan();
    public void scanPhoto();
}

interface IFax {
    public void fax();
    public void internetFax();
}

Это гораздо лучший подход. Вы не только разделили большие интерфейсы на более мелкие интерфейсы, но и хорошо определили функциональные возможности, которые также удовлетворяют принципу единой ответственности.

class HPPrintNScanner implements IPrint, IScan {

    @Override
    public void scan() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void scanPhoto() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void print() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void getPrintSpoolDetails() {
        // TODO Auto-generated method stub
        
    }

}

Как видите, HPPrintNScanner реализовал только необходимые методы.

Методы выявления нарушений

1. Узнайте, есть ли в ваших интерфейсах методы с низкой связностью.
2. Проверьте реализации пустых методов

Заключение

Вы узнали несколько отличных методов, которые повысят качество вашего кода. Это еще один шаг к созданию масштабируемого приложения. Иди тренируйся тренируйся!

Другие статьи для твердых принципов