Что такое “слабая связь?” Обеспечьте примеры

Рассмотрите простое приложение корзины покупок, которое использует класс CartContents для отслеживания объекты в магазинной тележке и классе Порядка для обработки покупки. Порядок должен определить итоговое значение содержания в корзине, это могло бы сделать это как так:

Сильно связанный Пример:

public class CartEntry
{
    public float Price;
    public int Quantity;
}

public class CartContents
{
    public CartEntry[] items;
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        float cartTotal = 0;
        for (int i = 0; i < cart.items.Length; i++)
        {
            cartTotal += cart.items[i].Price * cart.items[i].Quantity;
        }
        cartTotal += cartTotal*salesTax;
        return cartTotal;
    }
}

Уведомление, как метод OrderTotal (и таким образом класс Порядка) зависит от деталей реализации CartContents и классов CartEntry. Если бы мы должны были попытаться изменить эту логику для обеспечения скидок, мы должны были бы, вероятно, изменить все 3 класса. Кроме того, если бы мы изменяемся на использование набора Списка для отслеживания объекты, мы должны были бы изменить класс Порядка также.

Теперь вот немного лучший способ сделать то же самое:

Менее двойной Пример:

public class CartEntry
{
    public float Price;
    public int Quantity;

    public float GetLineItemTotal()
    {
        return Price * Quantity;
    }
}

public class CartContents
{
    public CartEntry[] items;

    public float GetCartItemsTotal()
    {
        float cartTotal = 0;
        foreach (CartEntry item in items)
        {
            cartTotal += item.GetLineItemTotal();
        }
        return cartTotal;
    }
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        return cart.GetCartItemsTotal() * (1.0f + salesTax);
    }
}

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

Слабая связь, в целом, является 2 агентами, работающими друг независимо от друга над той же рабочей нагрузкой. Таким образом, если бы у Вас было 2 веб-сервера с помощью той же базы данных бэкенда, тогда Вы сказали бы, что те веб-серверы слабо связываются. Плотное соединение иллюстрировалось бы при наличии 2 процессоров на одном веб-сервере..., те процессоры сильно связываются.

Hope это несколько полезно.

Можно читать больше об универсальном понятии "слабая связь" .

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

Некоторые длинные ответы здесь. Принцип очень прост все же. Я отправляю вступительную речь от Википедия :

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

Каждый конец транзакции делает свои требования явными и делает немного предположений о другом конце".

В информатике существует другое подразумевать для "слабой связи", что никто больше не отправил о здесь, таким образом... Здесь идет - надо надеяться, Вы дадите мне некоторые голоса, таким образом, это не будет потеряно у основания "кучи"! КОНЕЧНО, предмет моего ответа принадлежит любого всестороннего ответа на вопрос... К остроумию:

термин "Слабая связь" сначала ввел вычисление как термин, использованный как прилагательное относительно архитектуры ЦП в конфигурации мульти-ЦП. Его термин дубликата является "плотным соединением". Слабая связь состоит в том, когда центральные процессоры не совместно используют много ресурсов в связанности общей среды, и Плотное соединение - когда они делают.

термин "система" может сбивать с толку здесь, поэтому проанализируйте ситуацию тщательно.

Обычно, но не всегда, несколько центральных процессоров в аппаратной конфигурации, в которой они существуют в одной системе (как в отдельных полях "PC") были бы сильно связаны. За исключением некоторых супервысокоэффективных систем, которые имеют подсистемы, которые на самом деле совместно используют оперативную память через "системы", слабо связываются все делимые системы.

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

Первый, так как это было тем, чем вопрос был о, некоторые примеры Слабо связанных систем:

• кластеры VaxClusters
• Linux

Напротив, некоторые Сильно связанные примеры:

• Операционные системы Semetrical-Multi-Processing (SMP) - например, Fedora 9
• Многопоточные центральные процессоры
• Многоядерные центральные процессоры

В сегодняшнем вычислении, примеры обеих работ в единственной полной системе весьма распространены. Например, возьмите современный Pentium двойные или четырехъядерные центральные процессоры рабочий Fedora 9 - это вычислительные системы с сильной связью. Затем объедините несколько из них в слабо связанном Кластере Linux, и Вы теперь имеете и свободно и сильно связали продолжение вычисления! О, не современные замечательные аппаратные средства!

Рассмотрите Приложение Windows с FormA и FormB. FormA является основной формой, и это отображает FormB. Вообразите FormB, бывший должный пасовать назад данные к его родителю.

, Если Вы сделали это:

class FormA 
{
    FormB fb = new FormB( this );

    ...
    fb.Show();
}

class FormB 
{
    FormA parent;

    public FormB( FormA parent )
    {
        this.parent = parent;
    }     
}

FormB сильно связывается к FormA. FormB не может иметь никакого другого родителя, чем тот из типа FormA.

, Если с другой стороны, Вы сделали, чтобы FormB опубликовал событие и сделал, чтобы FormA подписался на то событие, тогда FormB мог продвинуть данные назад через то событие любому подписчику, которого имеет событие. В этом случае тогда FormB даже не знает свое возражение к его родителю; посредством слабой связи обеспечивает событие, это просто говорит с подписчиками. Любой тип может теперь быть родителем к FormA.

армированный пластик

Два компонента высоко связаны, когда они зависят от конкретной реализации друг друга.

предположим у меня есть этот код где-нибудь в методе в моем классе:

this.some_object = new SomeObject();

Теперь мой класс зависит от SomeObject, и они высоко связаны. С другой стороны, скажем, у меня есть метод InjectSomeObject:

void InjectSomeObject(ISomeObject so) { // note we require an interface, not concrete implementation
  this.some_object = so;
}

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

можно сделать некоторые части этой работы easer при помощи контейнеров внедрения зависимости. Можно читать больше о DI в Википедии: http://en.wikipedia.org/wiki/Dependency_injection .

иногда легко взять это слишком далеко. В какой-то момент необходимо сделать вещи бетоном, или программа будет менее читаема и понятна. Так используйте это методы главным образом на границе компонентов и знайте то, что Вы делаете. Удостоверьтесь, что Вы используете в своих интересах слабую связь. В противном случае Вам, вероятно, не нужен он в том месте. DI может сделать Вашу программу более сложной. Удостоверьтесь, что Вы делаете хороший компромисс. Другими словами, сохраните хорошее равновесие. Как всегда при разработке систем. Удачи!

Это - довольно общее понятие, таким образом, примеры кода не собираются давать целое изображение.

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

Читать краткую страницу Википедии может дать Вам смысл этого общего:

http://en.wikipedia.org/wiki/Loose_coupling

До определенного примера кода...

Вот одна слабая связь, с которой я работал недавно от Microsoft. Методы. Материал CompositeUI.

    [ServiceDependency]
    public ICustomizableGridService CustomizableGridService
    {
        protected get { return _customizableGridService; }
        set { _customizableGridService = value; }
    }

Этот код объявляет, что этот класс имеет зависимость от CustomizableGridService. Вместо того, чтобы просто непосредственно сослаться на точную реализацию сервиса, это просто указывает, что требуется НЕКОТОРАЯ реализация того сервиса. Тогда во времени выполнения, система разрешает ту зависимость.

, Если это не ясно, можно считать более подробное объяснение здесь:

http://en.wikipedia.org/wiki/Dependency_injection

Предполагает, что ABCCustomizableGridService является реализацией, которую я намереваюсь поднять трубку здесь.

, Если я принимаю решение, я могу дергать это и заменить его XYZCustomizableGridService или StubCustomizableGridService без изменения вообще в классе с этой зависимостью.

, Если бы я непосредственно сослался на ABCCustomizableGridService, тогда я должен был бы делать изменения в это reference/s для загрузки другой реализации услуги.

Определение

По существу связь состоит в том, насколько данный объект или набор объекта полагаются на другой объект или другой набор объектов для выполнения его задачи.

Высокая Связь

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

Слабая связь

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

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

Степень различия между ответами здесь показывает, почему это было бы трудное понятие для схватывания, но помещать его так просто, как я могу описать его:

Для меня, чтобы знать, что, если я бросаю шар в Вас, тогда можно поймать его, я действительно не должен знать, какого возраста Вы. Я не должен знать то, что Вы съели на завтрак, и я действительно не забочусь, кем была Ваша первая давка. Все, что я должен знать, - то, что можно поймать. Если я знаю это, то я не забочусь, бросаю ли Вы я шар в Вас или Вашего брата.

С нединамическими языками как c# или Java и т.д., мы выполняем это через Интерфейсы. Так позволяет, говорят, что у нас есть следующий интерфейс:

public ICatcher
{
   public void Catch();
}

И теперь позволяет, говорят, что у нас есть следующие классы:

public CatcherA : ICatcher
{
   public void Catch()
   {
      console.writeline("You Caught it");
   }

}
public CatcherB : ICatcher
{
   public void Catch()
   {
      console.writeline("Your brother Caught it");
   }

}

Теперь и CatcherA и CatcherB реализуют метод Выгоды, таким образом, сервис, который требует Ловца, может использовать любой из них и не действительно волновать, какой это. Таким образом, сильно связанный сервис мог бы непосредственно instanciate пойманный т.е.

public CatchService
{
   private CatcherA catcher = new CatcherA();

   public void CatchService()
   {
      catcher.Catch();
   }

}

, Таким образом, CatchService может сделать точно, что это намеревалось делать, но это использует CatcherA, и будет всегда пользователь CatcherA. Его твердое кодировало в, таким образом, его пребывание там, пока кто-то не приезжает и осуществляет рефакторинг его.

Теперь позволяет, выбирают другой вариант, названный внедрением зависимости:

public CatchService
{
   private ICatcher catcher;

   public void CatchService(ICatcher catcher)
   {
      this.catcher = catcher;
      catcher.Catch();
   }
}

Так класс, что instansiates CatchService может сделать следующее:

CatchService catchService = new CatchService(new CatcherA());

или

CatchService catchService = new CatchService(new CatcherB());

Это означает, что сервис Выгоды не сильно связывается или к CatcherA или к CatcherB.

существует несколько других stratergies для loosly связывающиеся услуги как это, такие как использование платформы МОК и т.д.

Сильно связанный код полагается на конкретную реализацию. Если мне нужен список строк в моем коде, и я объявляю его как это (в Java)

ArrayList<String> myList = new ArrayList<String>();

тогда, я завишу от реализации ArrayList.

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

List<String> myList = new ArrayList<String>();

Это препятствует тому, чтобы я звонил любой метод на myList, это характерно для реализации ArrayList. Я ограничен только теми методами, определенными в интерфейсе List. Если я решаю позже, что мне действительно нужен LinkedList, я только должен изменить свой код в одном месте, где я создал новый Список, а не в 100 местах, где я выполнил вызовы к методам ArrayList.

, Конечно, Вы можете инстанцировать ArrayList с помощью первого объявления и ограничивать себя от не использования любых методов, которые не являются частью интерфейса List, но использование второго объявления заставляет компилятор сохранить Вас честными.

Извините, но "слабая связь" не является проблемой кодирования, это - вопросы проектирования. Термин "слабая связь" глубоко связан с желательным состоянием "высокой связности", будучи противоположным, но дополнительным.

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

Высокая связность является видом подобного "плотного соединения", но высокая связность является состоянием, где элементы дизайна, которые действительно должны знать друг о друге, разработаны так, чтобы они сотрудничали чисто и изящно.

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

Реализацию этого оставляют как осуществление для читателя:).

Я буду использовать Java в качестве примера. Скажем, у нас есть класс, который похож на это:

public class ABC
{
   public void doDiskAccess() {...}
}

, Когда я назову класс, я должен буду сделать что-то вроде этого:

ABC abc = new ABC();

abc. doDiskAccess();

Пока неплохо. Теперь скажем, у меня есть другой класс, который похож на это:

public class XYZ
{
   public void doNetworkAccess() {...}
}

Это смотрит точно то же как ABC, но скажем, это работает по сети вместо на диске. Поэтому теперь давайте запишем программу как это:

if(config.isNetwork()) new XYZ().doNetworkAccess();
else new ABC().doDiskAccess();

, Который работает, но это является немного громоздким. Я мог упростить это с интерфейсом как это:

public interface Runnable
{
    public void run();
}

public class ABC implements Runnable
{
   public void run() {...}
}

public class XYZ implements Runnable
{
   public void run() {...}
}

Теперь мой код может быть похожим на это:

Runnable obj = config.isNetwork() ? new XYZ() : new ABC();

obj.run();

Видят, сколько инструмента для очистки и более простой понять это? Мы только что поняли первый основной принцип слабой связи: абстракция. Ключ отсюда должен гарантировать, чтобы ABC и XYZ не зависели ни от каких методов или переменных классов, которые называют их. Это позволяет ABC и XYZ быть абсолютно независимыми API. Или другими словами, они "разъединяются" или "слабо связываются" от родительских классов.

, Но что, если нам нужна коммуникация между двумя? Ну, тогда мы можем использовать дальнейшие абстракции как Модель событий , чтобы гарантировать, чтобы родительский код никогда не связывался с API, которые Вы создали.

Много интегрированных продуктов (особенно Apple) такой как iPod , iPad являются хорошим примером плотного соединения: как только батарея перестает работать, Вы могли бы также купить новое устройство, потому что батарея спаяна починенная и не высвободится, таким образом делая замену очень дорогого. Слабо связанный плеер позволил бы легко изменять батарею.

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

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

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

Некоторые примеры:

• Приложение зависит от библиотеки. Под плотным соединением приложение повреждается на более новых версиях lib. Google для "Ада DLL".

• Клиентское приложение считывает данные с сервера. Под плотным соединением изменения в сервере требуют, закрепляет на стороне клиента.

• Два класса взаимодействуют в Объектно-ориентированной иерархии. Под плотным соединением изменения в одном классе требуют, чтобы другой класс был обновлен для соответствия.

• Несколько инструментов командной строки связываются в канале. Если они будут сильно связаны, изменения в версии одного инструмента командной строки вызовут ошибки в инструментах, которые читают его вывод.