[oop] “느슨한 커플 링”이란 무엇입니까? 예를 제공하십시오

나는 “느슨한 커플 링”이라는 개념을 이해하지 못하는 것 같습니다. 나는 “느슨한”이라는 단어가 일반적으로 부정적인 의미를 갖는 데 도움이되지 않는다고 생각하기 때문에 느슨한 결합이 좋은 것임을 항상 잊어 버린다 .

누군가이 개념을 설명하는 “이전”및 “이후”코드 (또는 의사 코드)를 보여 주시겠습니까?



답변

CartContents 클래스를 사용하여 장바구니의 항목과 구매 처리를위한 Order 클래스를 추적하는 간단한 장바구니 애플리케이션을 고려하십시오. 주문은 장바구니에 담긴 내용물의 총 가치를 결정해야합니다.

밀접하게 결합 된 예 :

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 메소드 (및 따라서 Order 클래스)가 CartContents 및 CartEntry 클래스의 구현 세부 사항에 따라 어떻게 달라지는 지 확인하십시오. 할인을 허용하기 위해이 논리를 변경하려고하면 3 개의 클래스를 모두 변경해야합니다. 또한 List 컬렉션을 사용하여 항목을 추적하는 경우 Order 클래스도 변경해야합니다.

이제 동일한 작업을 수행하는 약간 더 나은 방법이 있습니다.

덜 결합 된 예 :

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);
    }
}

장바구니 광고 항목 또는 장바구니 모음 또는 주문의 구현과 관련된 논리는 해당 클래스로만 제한됩니다. 따라서 다른 클래스를 변경하지 않고도 이러한 클래스의 구현을 변경할 수 있습니다. 디자인을 개선하고 인터페이스를 도입하는 등의 방법으로 이러한 분리를 한층 더 발전시킬 수 있지만, 요점을 알 것 같습니다.


답변

iPod , iPad 와 같은 많은 통합 제품 (특히 Apple의 제품) 은 긴밀한 결합의 좋은 예입니다. 배터리가 방전되면 배터리가 고정되어 느슨해지지 않기 때문에 새 장치를 구입할 수도 있습니다. 비싼. 느슨하게 연결된 플레이어는 배터리를 쉽게 교체 할 수 있습니다.

소프트웨어 개발도 마찬가지 입니다. 일반적으로 코드를 느슨하게 결합하여 확장 및 교체를 용이하게하고 개별 부품을 이해하기 쉽게하는 것이 좋습니다. 그러나 매우 드물게 특수한 상황에서는 여러 모듈의 긴밀한 통합으로 더 나은 최적화가 가능하기 때문에 긴밀한 결합이 유리할 수 있습니다.


답변

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와 연결할 필요가 없도록 할 수 있습니다.


답변

죄송하지만 “느슨한 커플 링”은 코딩 문제가 아니며 디자인 문제입니다. “느슨한 커플 링”이라는 용어는 “높은 응집력”의 바람직한 상태와 밀접한 관련이 있으며, 상반되지만 상보 적이다.

느슨한 결합은 단순히 개별 설계 요소를 구성하여 다른 설계 요소에 대해 알아야하는 불필요한 정보의 양을 줄여야한다는 의미입니다.

높은 응집력은 일종의 “긴밀한 결합”과 유사하지만, 높은 응집력은 서로에 대해 실제로 알아야하는 디자인 요소가 깨끗하고 우아하게 함께 작동하도록 설계된 상태입니다.

요점은 일부 디자인 요소는 다른 디자인 요소에 대한 세부 정보를 알아야하므로 실수로 디자인하지 않아야한다는 것입니다. 다른 디자인 요소는 다른 디자인 요소에 대한 세부 정보를 알 수 없으므로 임의로 의도적으로 의도 된 방식으로 디자인해야합니다.

이것을 구현하는 것은 독자를위한 연습으로 남겨둔다 :).


답변

밀접하게 결합 된 코드는 구체적인 구현에 의존합니다. 내 코드에 문자열 목록이 필요하고 이것을 Java로 선언하면

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

그런 다음 ArrayList 구현에 의존합니다.

느슨하게 결합 된 코드로 변경하려면 참조를 인터페이스 (또는 다른 추상) 유형으로 만듭니다.

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

이것은 ArrayList 구현과 관련된 메소드 를 호출 하지 못하게합니다 myList. List 인터페이스에 정의 된 메소드로만 제한됩니다. 나중에 실제로 LinkedList가 필요하다고 결정하면 ArrayList 메서드를 호출 한 100 곳이 아니라 새 List를 만든 곳에서 코드를 변경하면됩니다.

물론, 당신은 할 수 있습니다 첫 번째 선언을 사용하여 ArrayList의 인스턴스를하고, List 인터페이스의 일부가 아닌 어떤 방법을 사용하지만, 솔직히 당신을 계속 컴파일러 두 번째 선언을하게 사용하지으로부터 자신을 억제.


답변

여기에있는 답변의 차이의 정도는 이해하기 쉽지만 설명 할 수있는 것처럼 간단하게 배치하는 것이 어려운 개념을 보여줍니다.

내가 당신에게 공을 던지면 당신이 그것을 잡을 수 있다는 것을 알기 위해 나는 당신이 몇 살인지 알 필요가 없습니다. 나는 당신이 아침 식사를 위해 무엇을 먹었는지 알 필요가 없으며, 나는 당신의 첫 호감이 누구인지 신경 쓰지 않습니다. 내가 알아야 할 것은 당신이 붙잡을 수 있다는 것입니다. 내가 이것을 안다면, 나는 그것이 당신이나 내가 당신의 형제에게 공을 던지고 있는지 상관하지 않습니다.

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는 모두 Catch 메소드를 구현하므로 Catcher를 필요로하는 서비스는이 중 하나를 사용할 수 있으며 실제로 어느 쪽인지는 알 수 없습니다. 따라서 밀접하게 연결된 서비스는 잡힌 즉, 즉

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();
   }
}

따라서 CatchService를 인스턴스화하는 calss는 다음을 수행 할 수 있습니다.

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

또는

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

이는 캐치 서비스가 CatcherA 또는 CatcherB에 단단히 연결되지 않았 음을 의미합니다.

IoC 프레임 워크 사용 등과 같이 이와 같이 느슨하게 결합 된 서비스에는 몇 가지 다른 전략이 있습니다.


답변

(단단하거나 느슨한) 커플 링은 말 그대로 특정 클래스를 다른 클래스에 대한 의존과 분리하는 데 드는 노력의 양이라고 생각할 수 있습니다. 예를 들어, 클래스의 모든 메소드가 마지막에 Log4Net을 호출하여 무언가를 기록하는 블록이 조금만 있으면 클래스가 Log4Net에 단단히 연결되어 있다고 말할 수 있습니다. 클래스에 대신 Log4Net 구성 요소를 호출 한 유일한 장소 인 LogSomething이라는 개인 메서드가 포함 된 경우 (그리고 다른 방법은 모두 LogSomething이라고 함) 클래스가 Log4Net에 느슨하게 연결되었다고 말할 수 있습니다. Log4Net을 꺼내 다른 것으로 교체하십시오.