"느슨한 커플 링"이란 무엇입니까? 예를 제공하십시오

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

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

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을 꺼내 다른 것으로 교체하십시오.

정의

본질적으로 커플 링은 주어진 객체 또는 객체 세트가 다른 객체 또는 다른 객체 세트에 의존하여 작업을 수행하는 정도입니다.

높은 커플 링

차를 생각하십시오. 엔진을 시동하려면 시동 장치에 키를 꽂고 돌리고 휘발유가 있어야하며 스파크가 발생하고 피스톤이 작동해야하며 엔진이 작동해야합니다. 자동차 엔진이 여러 다른 물체와 밀접하게 연결되어 있다고 말할 수 있습니다. 이것은 높은 커플 링이지만 실제로 나쁜 것은 아닙니다.

느슨한 결합

사용자가 일부 유형의 정보를 게시, 편집 및 볼 수 있도록하는 웹 페이지에 대한 사용자 정의 컨트롤을 생각해보십시오. 단일 컨트롤을 사용하여 사용자가 새로운 정보를 게시하거나 새로운 정보를 편집 할 수 있습니다. 컨트롤은 새로운 경로와 편집 경로 사이에서 공유 할 수 있어야합니다. 컨트롤에 포함 할 페이지의 일부 데이터 유형이 필요한 방식으로 컨트롤을 작성하면 너무 많이 연결되어 있다고 말할 수 있습니다. 컨트롤은 컨테이너 페이지에서 아무것도 필요하지 않습니다.

꽤 일반적인 개념이므로 코드 예제는 전체 그림을 제공하지 않습니다.

직장에서 한 사람이 저에게 "패턴은 프랙탈과 같습니다. 확대 할 때나 아키텍처 수준으로 축소 할 때 볼 수 있습니다."라고 말합니다.

간단한 위키 백과 페이지를 읽으면 다음과 같은 일반적인 느낌을 얻을 수 있습니다.

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

특정 코드 예제까지 ...

다음은 최근에 Microsoft.Practices.CompositeUI에서 작업 한 느슨한 커플 링입니다.

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

이 코드는이 클래스에 CustomizableGridService에 대한 종속성이 있음을 선언합니다. 서비스의 정확한 구현을 직접 참조하는 대신 단순히 해당 서비스의 일부 구현이 필요하다고 명시합니다. 그런 다음 런타임시 시스템은 해당 종속성을 해결합니다.

확실하지 않은 경우 여기에서 자세한 설명을 읽을 수 있습니다.

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

ABCCustomizableGridService가 내가 여기에 연결하려는 의미라고 상상해보십시오.

내가 선택하면, 그것을 잡아 당겨 XYZCustomizableGridService 또는 StubCustomizableGridService로 대체 할 수 있습니다.이 의존성을 가진 클래스에는 전혀 변경이 없습니다.

ABCCustomizableGridService를 직접 참조한 경우 다른 서비스 구현으로 교체하려면 해당 참조 / 설명을 변경해야합니다.

커플 링은 코드 모듈 (함수, 파일 또는 클래스), 파이프 라인의 도구, 서버-클라이언트 프로세스 등의 시스템 간 종속성과 관련이 있습니다. 종속 관계가 덜 일반적 일수록 하나의 시스템을 변경하면 다른 시스템을 변경해야하므로 더 밀접하게 연결됩니다. 이상적인 상황은 하나의 시스템을 변경할 수있는 "느슨한 커플 링"이며 이에 따라 시스템은 수정없이 계속 작동합니다.

느슨한 결합을 달성하는 일반적인 방법은 잘 정의 된 인터페이스를 통하는 것입니다. 두 시스템 간의 상호 작용이 잘 정의되어 있고 양쪽에서 모두 준수되는 경우 규칙이 손상되지 않도록 한 시스템을 수정하기가 더 쉬워집니다. 실제로는 잘 정의 된 인터페이스가 설정되지 않아서 조잡한 디자인과 긴밀한 결합이 발생합니다.

몇 가지 예 :

• 응용 프로그램은 라이브러리에 따라 다릅니다. 긴밀한 연결에서 앱은 최신 버전의 lib에서 작동하지 않습니다. "DLL 지옥"에 대한 Google.

• 클라이언트 앱은 서버에서 데이터를 읽습니다. 긴밀한 연결에서 서버를 변경하려면 클라이언트 쪽에서 수정해야합니다.

• 두 개의 클래스는 객체 지향 계층에서 상호 작용합니다. 긴밀한 연결에서 한 클래스를 변경하면 다른 클래스를 일치하도록 업데이트해야합니다.

• 여러 명령 줄 도구가 파이프에서 통신합니다. 이들이 밀접하게 연결되어 있으면 하나의 명령 줄 도구 버전을 변경하면 출력을 읽는 도구에 오류가 발생합니다.

커플 링은 서로 다른 클래스가 얼마나 밀접하게 연결되어 있는지를 나타냅니다. 밀접하게 연결된 클래스에는 많은 상호 작용 및 종속성이 포함됩니다.

느슨하게 연결된 클래스는 서로에 대한 종속성이 최소한으로 유지되고 서로 잘 정의 된 공용 인터페이스에 의존한다는 점에서 반대입니다.

SNAP가 함께 결합한 장난감 인 레고는 완만하게 결합 된 것으로 간주됩니다. 그러나 직소 퍼즐에는 단단히 결합 된 조각이 있습니다. 하나의 직소 퍼즐 (시스템)에서 하나의 조각을 가져 와서 다른 퍼즐에 넣을 수는 없습니다. 왜냐하면 시스템 (퍼즐)은 해당 특정 "디자인"에 맞게 제작 된 매우 특정한 조각에 크게 의존하기 때문입니다. 레고는 좀 더 일반적인 방식으로 제작되어 레고 하우스 나 레고 에일리언 맨에서 사용할 수 있습니다.

참조 : https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/

두 구성 요소는 서로의 구체적인 구현에 의존 할 때 밀접하게 결합됩니다.

내 클래스의 메소드 어딘가에이 코드가 있다고 가정하십시오.

this.some_object = new SomeObject();

이제 내 수업은 SomeObject에 의존하며 매우 밀접하게 연결되어 있습니다. 반면에 InjectSomeObject 메소드가 있다고 가정 해 봅시다.

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

그런 다음 첫 번째 예제는 주입 된 SomeObject를 사용할 수 있습니다. 테스트하는 동안 유용합니다. 정상적인 작동에서는 경량의 모의 구현을 통과하는 테스트를 위해 무거운 데이터베이스 사용, 네트워크 사용 클래스 등을 사용할 수 있습니다. 밀접하게 결합 된 코드로는 그렇게 할 수 없습니다.

의존성 주입 컨테이너를 사용하여이 작업의 일부를보다 쉽게 ​​만들 수 있습니다. DI에 대한 자세한 내용은 Wikipedia : http://en.wikipedia.org/wiki/Dependency_injection 에서 확인할 수 있습니다 .

때로는 너무 멀리 가져 가기가 쉽습니다. 어떤 시점에서 당신은 일을 구체적으로 만들어야합니다. 따라서이 기술을 주로 구성 요소 경계에서 사용하고 수행중인 작업을 확인하십시오. 느슨한 커플 링을 이용하고 있는지 확인하십시오. 그렇지 않은 경우 해당 위치에서 필요하지 않을 수 있습니다. DI는 프로그램을 더 복잡하게 만들 수 있습니다. 당신이 좋은 트레이드 오프를 확인하십시오. 다시 말해, 균형을 잘 유지하십시오. 항상 시스템을 설계 할 때와 같습니다. 행운을 빕니다!

FormA 및 FormB가있는 Windows 앱을 고려하십시오. 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의 상위가 될 수 있습니다.

rp

컴퓨터 과학에는 "느슨한 커플 링 (loose coupling)"이라는 또 다른 의미가 있습니다. 여기에 아무도 게시하지 않았습니다. 여기로갑니다. 분명히 내 대답의 주제는 질문에 대한 포괄적 인 대답에 속합니다 ...

"Loose Coupling"이라는 용어는 먼저 다중 CPU 구성에서 CPU 아키텍처에 대한 형용사로 사용되는 용어로 컴퓨팅에 들어갔다. 이에 대한 용어는 "긴밀한 결합"입니다. 루스 커플 링은 CPU가 많은 리소스를 공통으로 공유하지 않는 경우이고 꽉 커플 링은 CPU를 공유하는 경우입니다.

여기서 "시스템"이라는 용어는 혼동 될 수 있으므로 상황을 신중하게 구문 분석하십시오.

일반적으로 항상 그런 것은 아니지만 하드웨어 구성에서 하나의 시스템 내에 존재하는 여러 개의 CPU (개별 "PC"상자 에서처럼)는 밀접하게 연결됩니다. 실제로 "시스템"에서 주 메모리를 공유하는 서브 시스템이있는 일부 초 고성능 시스템을 제외하고 모든 분할 가능한 시스템은 느슨하게 결합되어 있습니다.

Tightly Coupled 및 Loosely Coupled라는 용어는 멀티 스레드 및 멀티 코어 CPU가 발명 되기 전에 도입 되었으므로 이러한 용어는 오늘날 상황을 완전히 설명하기 위해 일부 동반자가 필요할 수 있습니다. 실제로 오늘날에는 하나의 전체 시스템에 두 유형을 모두 포함하는 시스템이있을 수 있습니다. 현재 소프트웨어 시스템과 관련하여 두 가지 공통 아키텍처가 있습니다. 각 아키텍처 중 하나는 공통적이어야하며 공통적이어야합니다.

먼저, 그것이 문제에 관한 것이 었으므로 Loosely Coupled 시스템의 몇 가지 예는 다음과 같습니다.

• VaxClusters
• 리눅스 클러스터

대조적으로, 밀접하게 결합 된 몇 가지 예 :

• SMP (Semetrical-Multi-Processing) 운영 체제-예 : Fedora 9
• 멀티 스레드 CPU
• 멀티 코어 CPU

오늘날의 컴퓨팅에서 단일 시스템 전체에서 작동하는 예는 드문 일이 아닙니다. 예를 들어 Fedora 9를 실행하는 최신 Pentium 듀얼 또는 쿼드 코어 CPU를 사용하십시오. 이들은 밀접하게 결합 된 컴퓨팅 시스템입니다. 그런 다음 느슨하게 결합 된 Linux 클러스터에서 이들 중 몇 가지를 결합하면 느슨하고 밀접하게 결합 된 컴퓨팅이 진행됩니다! 아, 현대의 하드웨어는 훌륭하지 않습니다!

간단히 말해서, 느슨하게 결합 된 것은 발생하는 다른 이벤트에 의존하지 않음을 의미합니다. 독립적으로 실행됩니다.

여기에 긴 답변이 있습니다. 원칙은 매우 간단합니다. 나는 wikipedia 에서 시작 진술을 제출합니다 .

"느슨한 커플 링은 일종의 교환 관계를 가진 둘 이상의 시스템 또는 조직 간의 탄력적 인 관계를 나타냅니다.

트랜잭션의 각 끝은 요구 사항을 명시 적으로 만들고 다른 쪽 끝에 대한 가정은 거의 없습니다. "

매우 간단한 코드 커플 링 테스트를 제안합니다 .

1. 정확성을 유지하기 위해 조각 A의 변경을 강제로 수행 할 수있는 조각 B에 수정이있을 경우 코드 조각 A는 코드 조각 B와 밀접하게 연결됩니다.

2. 피스 A에 대한 변경이 필요한 피스 B에 대한 수정이없는 경우, 코드 피스 A는 피스 B의 코드와 밀접하게 연결되지 않습니다.

이것은 코드 조각들 사이에 얼마나 많은 결합이 있는지 확인하는 데 도움이됩니다. 추론을 위해이 블로그 게시물을 참조하십시오 : http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/

new다른 클래스에서 키워드를 사용하여 클래스의 객체를 만들 때 실제로 타이트 커플 링 (나쁜 연습)을 수행하는 대신 느슨한 커플 링을 사용해야합니다.

--- A.java ---

package interface_package.loose_coupling;

public class A {

void display(InterfaceClass obji)
{
    obji.display();
    System.out.println(obji.getVar());
}
}

--- B.java ---

package interface_package.loose_coupling;

public class B implements InterfaceClass{

private String var="variable Interface";

public String getVar() {
    return var;
}

public void setVar(String var) {
    this.var = var;
}

@Override
public void display() {
    // TODO Auto-generated method stub
    System.out.println("Display Method Called");
}
}

--- 인터페이스 클래스 ---

package interface_package.loose_coupling;

public interface InterfaceClass {

void display();
String getVar();
}

--- 주류 ---

package interface_package.loose_coupling;

public class MainClass {

public static void main(String[] args) {
    // TODO Auto-generated method stub

    A obja=new A();
    B objb=new B();
    obja.display(objb);     //Calling display of A class with object of B class 

}
}

설명:

위의 예에서 우리는 두 개의 클래스 A와 B를 가지고 있습니다

클래스 B는 인터페이스, 즉 InterfaceClass를 구현합니다.

InterfaceClass는 다른 클래스 (예 : A)가 액세스 할 수있는 B 클래스의 추상 메소드를 가지므로 Interface for B 클래스를 정의합니다.

클래스 A에는 InterfaceClass를 구현하는 클래스의 객체를 제외하고 표시 할 수있는 표시 방법이 있습니다 (이 경우 B 클래스입니다). 그리고 클래스 A의 객체 메소드에서 클래스 B의 display () 및 getVar ()를 호출합니다.

MainClass에서 우리는 클래스 A와 B의 객체를 만들었습니다. 그리고 B 클래스의 객체, 즉 objb를 전달하여 A의 디스플레이 메소드를 호출합니다. B 클래스의 객체로 A의 표시 방법이 호출됩니다.

이제 느슨한 결합에 대해 이야기합니다. 나중에 클래스 B의 이름을 ABC로 변경해야한다고 가정하면 클래스 B의 표시 방법에서 이름을 변경할 필요가 없으며 new (ABC 클래스)의 객체를 만들고 MailClass의 표시 방법으로 전달하면됩니다. 클래스 A에서 아무것도 변경할 필요가 없습니다.

참조 : http://p3lang.com/2013/06/loose-coupling-example-using-interface/

"느슨한 커플 링" 의 일반적인 개념에 대해 자세히 읽을 수 있습니다 .

간단히 말해서, 두 클래스 사이의 관계에 대한 설명입니다. 각 클래스는 다른 클래스에 대해 최소한을 알고 있으며 다른 클래스의 존재 여부에 관계없이 다른 클래스의 특정 구현에 의존하지 않고 잠재적으로 계속 잘 작동 할 수 있습니다. 수업.

일반적으로 느슨한 커플 링은 동일한 워크로드에서 서로 독립적으로 작업하는 두 명의 액터입니다. 따라서 동일한 백엔드 데이터베이스를 사용하는 두 개의 웹 서버가있는 경우 해당 웹 서버가 느슨하게 연결되어 있다고 말할 수 있습니다. 하나의 웹 서버에 2 개의 프로세서를 두어 긴밀한 연결을 예로들 수 있습니다. 이러한 프로세서는 밀접하게 연결되어 있습니다.

그것이 다소 도움이되기를 바랍니다.