В чем разница между слабой связью и сильной связью в объектно-ориентированной парадигме? - PullRequest
Новая
       71

В чем разница между слабой связью и сильной связью в объектно-ориентированной парадигме?

244 голосов
/ 14 мая 2010

Может ли кто-нибудь описать точную разницу между слабой связью и сильной связью в объектно-ориентированной парадигме?

Ответы [ 15 ]

2 голосов
/ 14 мая 2010

Слабое связывание является ответом на жестко закодированные зависимости старого стиля и связанные с этим проблемы, такие как частая перекомпиляция, когда что-то меняется, и повторное использование кода. Он делает упор на реализации рабочей логики в компонентах и ​​позволяет избежать связывания кода с конкретным решением.

Слабая связь = IoC См. это для более легкого объяснения.

1 голос
/ 25 декабря 2017

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

1 голос
/ 12 апреля 2017

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

0 голосов
/ 24 мая 2019

Здесь много хороших ответов с использованием аналогий, но один знакомый на работе дал мне пример, который мне понравился больше, чем все упомянутые здесь ... Глаза и очки!

Плотная муфта

Тесная связь была бы глазами. Если я хочу исправить свое зрение, мне очень дорого сделать пересадку глаза, и у меня довольно много риска. Но что, если дизайнер (будучи человеческим родом) нашел лучший путь? Добавьте функцию, которая слабо связана с корпусом, чтобы ее можно было легко изменить! (да .. очки)

Слабая связь

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

Резюме

Так что в следующий раз кто-то спросит вас "кого это волнует, если мой код тесно связан?" Ответ заключается в усилиях по изменению, усилиях по поддержанию и риске изменений.

Так как же это сделать в C #? Интерфейсы и внедрение зависимостей!

EDIT

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

0 голосов
/ 10 августа 2018

Если создание / существование объекта зависит от другого объекта, который не может быть адаптирован, его тесная связь. И, если зависимость может быть адаптирована, ее слабая связь. Рассмотрим пример на Java: 

class Car {

    private Engine engine = new Engine( "X_COMPANY" ); // this car is being created with "X_COMPANY" engine
    // Other parts

    public Car() { 
        // implemenation 
    }

}

Клиент класса Car может создать его с ТОЛЬКО механизмом "X_COMPANY".

Подумайте о том, чтобы разорвать это соединение с возможностью изменить это: 

class Car {

    private Engine engine;
    // Other members

    public Car( Engine engine ) { // this car can be created with any Engine type
        this.engine = engine;
    }

}

Теперь Car не зависит от механизма "X_COMPANY", так как его можно создавать с типами.

Примечание, специфичное для Java: использование интерфейсов Java только для разделения не является подходящим подходом к проектированию. В Java цель интерфейса - выступать в качестве контракта, который по сути обеспечивает поведение / преимущество разъединения.

Комментарий Билла Росмуса в принятом ответе имеет хорошее объяснение.

Страница:
...