느슨하게 결합 된 디자인을 만드는 데 얼마나 많은 노력을 기울여야합니까?

현재 디자인 패턴에 대해 배우고 있습니다.

대부분의 사람들은 이러한 패턴이 훌륭한 도구이지만 모든 것에 대한 대답이 아니라 적당히 사용해야한다는 데 동의 할 것입니다. 그것들을 너무 많이 사용하면 응용 프로그램을 거의 복잡하게 만들지 않을 것입니다. 패턴은 최상의 솔루션을 만들거나 좋은 솔루션을 만드는 데 도움이 될 수있는 곳에서만 사용해야합니다 (동의합니까?).

이것을 염두에두고 :

제가 읽고있는 책 (Head First Design Patterns)은 종종 느슨한 결합 의 중요성을 강조합니다 . 이 느슨한 결합은 '구현이 아닌 인터페이스에 대한 프로그램'과 '다양한 것을 캡슐화'와 같은 원칙에 따라 달성됩니다.

기본적으로 지금까지 배운 대부분의 패턴은 대부분 디자인이 느슨하게 결합되어 더욱 유연 해졌습니다.

느슨한 결합의 중요성과 이점을 이해합니다.

그러나 제 질문은 느슨하게 결합되고 유연한 디자인을 만드는 데 실제로 얼마나 많은 노력을 기울여야 하는가입니다.

디자인 패턴에 반대하는 사람들은 이러한 패턴을 사용하는 데 드는 비용이 종종 이점보다 중요하다고 말합니다. 실제로는 느슨한 커플 링, '구현이 아닌 인터페이스에 프로그래밍'및 이러한 모든 원칙이 실제로 중요하지 않을 수있는 패턴을 사용하여 느슨하게 결합 된 디자인을 만드는 데 많은 시간을 투자합니다 .

내가 알고 싶은 것은 추가 수준의 추상화와 디자인을 실제로 만드는 데 얼마나 많은 노력을 기울여야하는지, 내 응용 프로그램이 느슨한 커플 링, 인터페이스에 대한 프로그래밍과 같은 OO 원칙을 따를 수 있도록하는 것입니다. 그것? 이것에 얼마나 많은 노력을 기울여야합니까?

뚱뚱한 답변 :할수록 노력이 적습니다.

기본적으로 느슨하게 결합 된 코드를 작성하는 것은 그리 어렵지 않습니다. 반면에 느슨한 커플 링 측면에서 생각하도록 마음을 훈련시키는 것입니다. 그리고 나는 그것이 그만한 가치가 있다고 믿습니다.

지난 20 년 동안 대부분의 사람들이 권장 한대로 소프트웨어 개발에 반복적 인 접근 방식을 사용하는 직업을 가정 해보십시오. 반복 1에서 아름답게 작동하는 무언가를 만듭니다. 반복 2에서는 새로운 기능을 추가하고 반복에 맞지 않을 때 하나 또는 두 가지를 약간 구부립니다. 1 작동 방식에 대한 개념 . 이제 반복 3이 제공되며 기본 아키텍처를 다시 생각해야하는 요구 사항을 알 수 있습니다. 코드를 찢어 내고 다시 정사각형으로 돌아 가지 않고 다시 빌드하는 방법은 무엇입니까?

이런 일이 발생합니다. 많이. 프로젝트를 늦게 만들거나 나중에 반복 할 때 수행해야하는 작업을 수행하기에 너무 무서워합니다. 가장 좋은 경우에, 당신은 진흙의 큰 공을 얻습니다. 느슨한 결합 및 단일 책임 원칙과 같은 것은 이러한 문제를 크게 완화시킵니다. 이것이 바로 SOLID 원칙이 선포 된 이유이며 실제로 도움이됩니다.

벨트 아래에 느슨하게 결합 된 디자인이 몇 개 나면 자연스럽게 나오기 시작합니다. 패턴은 사람들이 찾은 것들로 그들에게 효과가 있었으므로 문서화했습니다. 그것들은 자연스럽게 시간이 흘러도 유용한 도구입니다.

필요한 노력이 항상 충분한 정보를 제공하지는 않습니다. 더 나은 방법은 비율을 갚기위한 노력이라고 생각합니다. 그러나 그 대가가 무엇인지 알아내는 것이 항상 간단하고 오류가있는 것은 아닙니다.

유연성을 높이는 패턴을 염두에 두어야 할 점은 패턴을 삽입하는 데 약간의 노력이 필요하다는 것입니다. 필요한 이유를 정확히 알 수 없으면 코드에 문제가 생길 수 있지만 결코 사용하지 않을 수 있습니다. 융통성이 결코 구부러지지 않으면 거기에 없을 수도 있습니다.

소프트웨어의 개별 구성 요소 (OOP 용 객체, 기능 또는 절차 적 프로그래밍을위한 기능)를 블랙 박스로 만드는 것이 항상 있어야합니다 (또는 합리적으로 얻을 수있는 한). 블랙 박스는 우리가 모르거나 신경 쓰지 않는 내부 (구현)입니다.

작동 방식에 대해 잘 모르거나 신경 쓰지 않으면 인터페이스 이외의 다른 것을 사용하려고 시도하지 않으므로 인터페이스를 변경하지 않고 구현이 변경되면 블랙 박스 내부에서만 문제가됩니다. 영향을받을 수 있습니다. 또한 전체 프로그램의 모든 세부 사항을 머리 속에 담을 필요가 없기 때문에 프로그램에 대한 생각을 쉽게 만듭니다. 합법적으로 잊을 수있는 세부 사항이 많을수록 중요한 세부 사항을위한 공간이 더 많이 있습니다.

디자인 패턴에 대한 반대 의견을 오해했다고 생각합니다. 나는 그들의 팬이 아니지만 인터페이스에 대한 느슨한 결합 및 프로그래밍 원리를 매우 좋아합니다. 그들에 대한 나의 반대 의견은 그것들이 그들 뒤에있는 원리를 이해하도록 장려하지 않고 오히려 세부 사항을 암기하도록 미리 포장 된 솔루션으로 제시된다는 것입니다. 나는 당신이 그것들을 공부하지 말 것을 권장하지는 않지만, 그렇게 할 때, 그 뒤에있는 원리를 이해하는 것이 특정 패턴의 구체적 사항보다 중요하다는 것을 기억하십시오.

디자인 패턴에 대한 반대 의견 중 하나는 패턴이 '명확하지 않다'거나 '그 이름이 아닌 그 패턴을 듣기 전에 사용하고 있었다'는 것입니다. 사람들이 이러한 반대 의견을 제기 할 수있는 이유 또는 디자인 패턴의 창시자가 처음부터이를 제기 할 수있는 이유는 그들이 배후의 원칙을 이해했기 때문입니다.

블랙 박스를 사용하면 코드를 깔끔하게 정리할 수 있으며 일반적으로 비용이 많이 들지 않습니다. 어디서나 사용하십시오. 추상화 패턴을 추가하거나 사물을 복잡하게하는 디자인 패턴이나 다른 기술을 사용하면 비용이 발생합니다. 예쁘거나 깔끔하거나 영리하기 때문에 절대 사용하지 마십시오. 그들이 문제에 맞고 비용을 지불 할 가치가있을 때 사용하십시오.

귀하의 질문은 디자인 패턴과 느슨한 결합을 동일시하는 것처럼 보이지만 실제로는 별개이지만 관련이 있습니다.

느슨한 결합은 프로그래밍에서 근본적인 관심사입니다. 기계어 코드에서 기호 언어로 옮겨가 자마자 프로그램은 실행과 느슨하게 결합되었습니다. 기타.

OO 자체는 기본적으로 느슨하게 연결된 구성 요소를 만들기위한 모델입니다. 캡슐화는 객체의 내부를 다른 객체와 느슨하게 결합시킵니다. 함수 실행은 극단적으로 다른 함수의 실행과 느슨하게 결합되기 때문에 기능 프로그래밍은 훨씬 더 그렇습니다.

거의 모든 정의에 따르면 느슨한 설계가 필요합니다. 부주의하게 밀접하게 결합되도록 할 수있는 방법이 있지만, 실제로 누군가가 시스템을 보다 밀접하게 결합 하도록 설계 한 사례는 몇 가지뿐입니다 .

(언제나 미래의 개발자가 특정 프레임 워크 아티팩트에 정적 참조를 임베드하여 의도적으로 사용하도록 설계함으로써 디자인 선택을 방지하려는 누군가와 협력하고 있습니다. 그러나 실제로는 예외입니다. 많은 맥락에서 재사용하십시오.)

패턴은 최상의 솔루션을 만들거나 좋은 솔루션을 만드는 데 도움이 될 수있는 곳에서만 사용해야합니다 (동의합니까?).

디자인 패턴을 구현 세부 사항으로 엄격하게 본다. 공개 API 및 프로그램을 해당 문서에 문서화하면 일반적으로 디자인 패턴이있는 위치는 중요하지 않습니다. 즉, "여기에는 다리 패턴이 있으며 그 위에 방문자를 구현할 것입니다." 대신, "이 클래스는 다양한 운영 체제에서 다른 구현을 가지므로 브리지 패턴을 사용하여 구현됩니다". 그런 다음이를 사용할 때는 브리지 패턴이 아닌 공개 API를 보므로 브리지로 구현되는 데 무관심합니다.

느슨하게 결합 된 유연한 디자인을 만드는 데 실제로 얼마나 많은 노력을 기울여야합니까?

간단한 규칙 세트를 따르면 느슨한 결합을 달성 할 수 있습니다. 이것을 존중한다면, 코드를 작성할 때 코드가 느슨하게 결합 될 것입니다 (즉, 노력은 이미 개발 프로세스의 일부입니다).

규칙 중 (전체 목록이 아님) :

• 클래스가 수행 할 작업이 아닌 클라이언트 코드 (클래스 사용 방법)를 생각 (또는 작성)하여 인터페이스를 정의합니다 (예 : 구현이 아닌 인터페이스를 요구)
• "말하지 말아라"
• 이미 작성된 부품으로 객체 생성
• 사용할 실제 객체 (구성원에 대한 팩토리, 매개 변수의 팩토리에 대한 매개 변수 등)를 생성자에 전달하십시오.
• DRY (두 곳에서 같은 순서로 두 줄이 나타나는 경우 별도의 함수 등으로 추출)
• 객체 생성이 더 복잡한 작업 인 경우, 중간 파트 생성을 팩토리 메소드 / 클래스 (생성자 본문이 아닌)로 구현하십시오.
• YAGNI (이전이 아니라 필요에 따라 생성)

이러한 규칙은 언어, 개발 방법론, 팀 (예 : TDD), 시간 예산 제약 등에 따라 다르게 적용됩니다.

예를 들어, Java에서는 인터페이스를 정의 interface하고 클라이언트 코드를 작성 하는 것이 좋습니다 (그런 다음 구현 클래스로 인터페이스를 인스턴스화하십시오).

반면 C ++에서는 인터페이스가 없으므로 인터페이스를 추상 기본 클래스로만 작성할 수 있습니다. C ++에서는 강력한 요구 사항이있을 때만 상속을 사용하므로 불필요한 가상 함수의 오버 헤드를 피할 수 있으므로 인터페이스를 별도로 정의하지 않고 클래스 헤더 만 정의하면됩니다.

디자인 패턴에 반대하는 사람들은 이러한 패턴을 사용하는 데 드는 비용이 종종 이점보다 중요하다고 말합니다.

나는 그들이 잘못하고 있다고 생각합니다. 느슨하게 결합 된 (및 DRY) 코드를 작성하는 경우 디자인 패턴을 코드에 통합하면 추가 노력이 최소화됩니다. 그렇지 않으면 디자인 패턴을 구현하기 위해 코드를 수정해야합니다.

디자인 패턴을 구현하기 위해 많은 변경을해야하는 경우 문제는 디자인 패턴 이 아니라 코드 기반이 모 놀리 식이며 밀접하게 결합 된 것입니다. 이것은 디자인 패턴 문제가 아니라 나쁜 / 최적의 디자인 문제입니다.

내가 알고 싶은 것은 추가 수준의 추상화와 디자인을 실제로 만드는 데 얼마나 많은 노력을 기울여야하는지, 내 응용 프로그램이 느슨한 커플 링, 인터페이스에 대한 프로그래밍과 같은 OO 원칙을 따를 수 있도록하는 것입니다. 그것? 이것에 얼마나 많은 노력을 기울여야합니까?

귀하의 질문은 느슨한 결합의 유일한 이점은 설계 패턴을 쉽게 구현할 수 있다는 것입니다. 그렇지 않습니다.

느슨한 커플 링의 장점은 다음과 같습니다.

• 리팩토링 및 재 설계 유연성
• 덜 낭비되는 노력
• 테스트 가능성
• 코드 재사용 가능성 증가
• 디자인 단순성
• 디버거에서 보낸 시간이 줄어 듭니다

... 지금 내 마음에 오지 않는 다른 몇 사람.