디커플링이란 무엇이며 어떤 개발 영역에 적용 할 수 있습니까? [닫은]

나는 최근에 질문에서 주제로 디커플링을 발견했으며 그것이 무엇인지, 어디에 적용 할 수 있는지 알고 싶다.

"어디에 적용 할 수 있습니까?"라는 의미는 다음과 같습니다.

C 및 Java와 같은 컴파일 된 언어가 관련된 경우에만 관련이 있습니까?

웹 개발자로 알고 공부해야합니까?

'커플 링'은 소프트웨어 시스템에서 두 엔티티 (일반적으로 클래스) 간의 관계를 설명하는 용어입니다.

클래스가 다른 클래스를 사용하거나 클래스와 통신 할 때 해당 클래스는 다른 클래스에 '종속'된다고 말하며 이러한 클래스는 '커플 링'됩니다. 그들 중 적어도 하나는 다른 것에 대해 '알고'있습니다.

아이디어는 우리가 시스템의 클래스들 사이의 커플 링을 가능한 한 '느슨하게'유지하도록 노력해야한다는 것입니다. 따라서 '느슨한 커플 링'또는 때때로 '디커플링'(영어로 '디커플링'은 '커플 링이 전혀 없음'을 의미하지만) 종종 엔티티 간 '느슨한 커플 링'을 암시하기 위해 사용합니다).

그래서 : 실제로 느슨한 결합과 강한 결합은 무엇이며, 왜 엔티티를 느슨하게 결합시켜야 하는가?

커플 링은 한 엔티티와 다른 엔티티 간의 종속성 정도를 설명합니다. 종종 클래스 나 객체.

ClassA가 ClassB에 크게 의존하는 경우 ClassB가 변경 될 때 ClassA가 영향을받을 가능성이 높습니다. 이것은 강력한 결합입니다.

그러나 ClassA가 ClassB에 약간 의존하는 경우 ClassA 코드 변경으로 인해 ClassA가 영향을받을 가능성이 낮습니다. 이것은 느슨한 결합 또는 '분리 된'관계입니다.

느슨한 결합은 시스템의 구성 요소가 서로 크게 의존하지 않기 때문에 좋습니다. 우리는 시스템을 모듈 식으로 유지하려고합니다 .

두 부품이 느슨하게 결합되면 서로 독립적이며 다른 부품이 변경 될 때 파손될 가능성이 줄어 듭니다.

예를 들어, 자동차를 제작할 때 엔진의 내부 변경으로 인해 스티어링 휠에서 무언가가 파손되는 것을 원하지 않습니다.

자동차를 만들 때 우연히 이런 일이 발생하지는 않지만 프로그래머에게는 항상 비슷한 일이 발생합니다. 느슨한 커플 링은 그러한 일이 발생할 위험을 줄 이도록되어 있습니다.

강한 결합은 일반적으로 엔티티 A가 엔티티 B에 대해 너무 많이 알고있을 때 발생합니다. 엔티티 A가 엔티티 B의 작동 방식 또는 구축 방식에 대해 너무 많은 가정을하는 경우 엔티티 B의 변경 이 엔티티 A에 영향을 미칠 위험이 높습니다. 엔티티 B에 대한 가정 중 하나가 잘못 되었기 때문입니다.

예를 들어, 운전자로서 자동차 엔진이 어떻게 작동하는지에 대한 특정 가정을 가정한다고 가정하십시오.

다르게 작동하는 (또는 어떤 이유로 든 엔진을 교체 한) 엔진이 장착 된 새 차를 구입하는 날에는 이전의 가정이 잘못되었을 것입니다. 컴퓨터에서 코드를 작성했다면 이제 제대로 작동하지 않는 잘못된 코드가됩니다.

그러나 운전자가 자동차에 대해 가정 한 모든 가정은 다음과 같습니다. 올바른 자세를 유지하십시오. 이것은 느슨한 결합입니다.

느슨한 결합을 달성하는 중요한 기술은 캡슐화입니다. 아이디어는 클래스가 다른 클래스에서 내부 세부 정보를 숨기고 다른 클래스가 클래스와 통신 할 수 있도록 엄격하게 정의 된 인터페이스를 제공한다는 것입니다.

당신은 클래스 자동차를 정의한다면 그래서 예를 들어, 그것의 인터페이스 (공개 방법) 아마 것 drive(), stop(), steerLeft(), steerRight(), getSpeed(). 다른 객체가 Car 객체에서 호출 할 수있는 방법입니다.

Car 클래스의 다른 모든 세부 사항 : 엔진 작동 방식, 사용하는 연료 종류 등은 다른 클래스에서 숨겨져 있으므로 Car에 대해 너무 많이 알지 못합니다.

클래스 A가 클래스 B에 대해 너무 많이 알고있는 순간 : 우리는 클래스 A가 클래스 B에 너무 의존적이고 클래스 B의 변경이 클래스 A에 영향을 줄 수있는 강력한 결합 관계를 가지고 있습니다. 시스템을 확장하고 유지하기 어렵게 만듭니다.

서로에 대해 거의 알지 못하는 두 엔티티 간의 관계 (필요한 것만)는 느슨하게 결합되거나 분리 된 관계입니다.

디커플링은 일반적으로 두 가지가 긴밀히 협력해야하는지 또는 더 독립적이 될 수 있는지 확인하는 것입니다. 독립성은 그 것들을 다른 곳에서 쉽게 변경하거나 사용할 수 있기 때문에 훌륭합니다. 디커플링은 개발뿐만 아니라 많은 분야에 적용될 수 있으며, 이는 특히 일상적인 데 어느 정도 적용 할 수있는 시간적 디커플링에도 적용됩니다. 또한 소프트웨어 개발에는 고려해야 할 여러 유형의 커플 링이 있으며 모든 답변에서 다룰 수는 없습니다. 당신은 당신의 연구를해야합니다.

A 와 B 라는 두 가지 가 종속되어 있으면 결합됩니다. A가 B에 의존하는 경우 A를 고려하지 않고 B를 사용할 수 있습니다. A를 사용하려면 A가 의존하기 때문에 B도 이월해야합니다.

소프트웨어 개발에서 일반적으로 구성 요소 간의 커플 링을 완전히 제거 할 수는 없습니다. 이러한 맥락에서 분리는 일반적으로 기존의 결합을 느슨하게 하는 것을 의미 합니다. 즉, 각 구성 요소가 주변의 다른 구성 요소에 대해 가능한 적게 알고 있어야합니다.

이것은 아마도 야생에서 발견되는 가장 일반적인 유형의 커플 링 일 것입니다.

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = (Friend[])client.GetConnection().ExecuteCommandForResult("getFriends:" + user.Name);
     ...
}

여기서 DisplayFriends는 필요한 것을 얻기 위해 Facebook 클라이언트 뒤의 연결로 불필요하게 수동으로 작동합니다. DisplayFriends의 클래스는 모두 결합 FacebookClient하고 Connection. FacebookClient가 갑자기 사용하는 연결 종류를 변경하면 앱에서 더 이상 Facebook 친구를 사 able 수 없습니다. FacebookClient에 요청하여 Facebook에 요청하여 DisplayFriends의 클래스와 Connection 간의 연결을 제거 할 수 있습니다.

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = client.GetFriends(user);
     ...
}

이제 FacebookClient가 친구를 얻는 방법에 대해서는 신경 쓰지 않습니다. 우리가 정말로 염려하는 것은 그것들을 얻는다는 사실입니다. 내부 행동에 대한 변화는 우리 자신의 수업에 해를 끼치 지 않습니다.

이러한 종류의 디커플링은 기능에 대해 Demeter of Law를 따라 쉽게 달성 할 수 있습니다 (Wikipedia 인용).

함수에 대한 Demeter of Law는 객체 O의 메소드 m이 다음과 같은 객체의 메소드 만 호출 할 수 있어야합니다.

• O 자체
• m의 매개 변수
• m 내에서 생성 / 인스턴스화 된 모든 객체
• O의 직접 컴포넌트 객체
• m 범위에서 O로 액세스 할 수있는 전역 변수

대답의 시작 부분에서 시간적 결합에 대해 언급 했으므로 간단히 설명하겠습니다.

알고리즘을 병렬로 실행하는 응용 프로그램을 설계 할 때는 일반적으로 시간 결합이 고려됩니다. 두 개의 실행 가능 유닛 (실제 명령어, 메소드 또는 유닛을 고려하고자하는 것), A 및 B를 고려하십시오. A를 실행하기 전에 B를 실행해야하는 경우 A는 B에 일시적으로 연결됩니다. A가 B에 일시적으로 연결되어 있지 않으면 A와 B를 동시에 실행할 수 있습니다. 이것에 대한 자신의 예를 만드십시오 : 일상 생활에서하는 평소의 일을 생각하십시오. 한 번에 두 가지 일이 있지만 동시에 할 수있는 일이 있습니까?

마지막으로 마지막 비트에 답하십시오.

웹 개발자로 알고 공부해야합니까?

예. 예를 들어, 웹 개발 (MVC)에 가장 많이 사용되는 디자인 패턴 중 하나는 디커플링에 관한 것입니다.

다른 답변은 디커플링이 무엇인지 설명하는 데 효과적입니다. 마지막 질문에 대해 이야기하고 싶었습니다.

웹 개발자로 알고 공부해야합니까?

정답은 예입니다. 어떤 종류의 개발자인지는 중요하지 않습니다. 웹 개발자이거나 임베디드 시스템 개발자 일 수 있습니다.

웹 페이지에 배치 된 사용자 정의 URL을 생성하는 클래스가 있다고 가정합니다. 클래스가 URL을 페이지에 직접 작성하여 태그의 href에 배치하도록 유혹 할 수 있습니다. 처음에는 더 단순 해 보일 수 있습니다. 그러나 링크를 전자 메일에 넣고 사용자에게 보내도록 변경해야 할 경우 어떻게됩니까? URL 생성기가 사용중인 웹 프레임 워크와 밀접하게 연결되어 있으므로 현재 코드가 작동하지 않습니다.

더 나은 옵션은 URL을 문자열로 반환하는 URL 생성기 클래스를 갖는 것입니다. 이것은 웹 코드에 의해 사용될 수 있고 이메일 코드에 의해 사용될 수도 있습니다. 코드를 분리하는 것이 더 선행적인 것처럼 보이지만 시간이 지남에 따라 그 비용이 지불됩니다.

모듈화 및 분리 된 코드를 사용하면 작업중인 프로그래밍 도메인에 관계없이 코드를보다 이해하기 쉽고 테스트 가능하며 유지 관리하기가 쉬워집니다.