"느슨한 커플 링"이란 무엇입니까? 예를 제공하십시오
나는 "느슨한 커플 링"이라는 개념을 이해하지 못하는 것 같습니다. 나는 "느슨한"이라는 단어가 일반적으로 부정적인 의미를 갖는 데 도움이되지 않는다고 생각하기 때문에 느슨한 결합이 좋은 것임을 항상 잊어 버린다 .
누군가이 개념을 설명하는 "이전"및 "이후"코드 (또는 의사 코드)를 보여 주시겠습니까?
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 곳이 아닌 새 위치를 만든 한 곳에서만 코드를 변경하면됩니다.
물론, 당신은 할 수 있습니다 첫 번째 선언을 사용하여 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 에서 시작 진술을 제출합니다 .
"느슨한 커플 링은 일종의 교환 관계를 가진 둘 이상의 시스템 또는 조직 간의 탄력적 인 관계를 나타냅니다.
Each end of the transaction makes its requirements explicit and makes few assumptions about the other end."
I propose a very simple Test of Code Coupling:
Piece A of code is tightly coupled to Piece B of code if there exists any possible modification to the Piece B that would force changes in Piece A in order to keep correctness.
Piece A of code is not tightly coupled to Piece B of code if there is no possible modification to the Piece B that would make a change to Piece A necessary.
This will help you to verify how much coupling there is between the pieces of your code. for reasoning on that see this blog post: http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/
When you create an object of a class using new keyword in some other class, you are actually doing tight coupling (bad practice) instead you should use loose coupling which is a good practice
---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");
}
}
---InterfaceClass---
package interface_package.loose_coupling;
public interface InterfaceClass {
void display();
String getVar();
}
---MainClass---
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
}
}
Explanation:
In above example, we have two classes A and B
Class B implements Interface i.e. InterfaceClass.
InterfaceClass defines a Contract for B class as InterfaceClass have abstract methods of B class that can be access by any other class for example A.
In Class A we have display method which can except object of class which implements InterfaceClass (in our case it is B class). And on that object method of class A is calling display() and getVar() of class B
In MainClass we have created object of Class A and B. And calling display method of A by passing object of B class i.e. objb. Display method of A will be called with object of B class.
Now talking about loose coupling. Suppose in future you have to change the name of Class B to ABC then you do not have to change its name in display method of class B, just make the object of new (ABC class) and pass it to the display method in MailClass. You do not have to change anything in Class A
ref: http://p3lang.com/2013/06/loose-coupling-example-using-interface/
You can read more about the generic concept of "loose coupling".
In short, it's a description of a relationship between two classes, where each class knows the very least about the other and each class could potentially continue to work just fine whether the other is present or not and without dependency on the particular implementation of the other class.
Loose coupling, in general, is 2 actors working independently of each other on the same workload. So if you had 2 web servers using the same back-end database, then you would say that those web servers are loosely coupled. Tight coupling would be exemplified by having 2 processors on one web server... those processors are tightly coupled.
Hope that's somewhat helpful.
참고URL : https://stackoverflow.com/questions/226977/what-is-loose-coupling-please-provide-examples
'development' 카테고리의 다른 글
| Java에서 (a == 1 && a == 2 && a == 3)을 true로 평가할 수 있습니까? (0) | 2020.05.26 |
|---|---|
| libc ++ abi.dylib : NSException (lldb) 유형의 포착되지 않은 예외로 종료 (1) | 2020.05.26 |
| IntelliJ에서 코드 글꼴 크기를 늘리는 방법은 무엇입니까? (0) | 2020.05.26 |
| 저장하는 동안 iphone Core Data Unresolved 오류 (0) | 2020.05.26 |
| 5 초마다 페이지를 다시로드하는 방법? (0) | 2020.05.26 |