안티 패턴이란 무엇입니까?

패턴과 반 패턴을 공부하고 있습니다. 패턴에 대한 명확한 아이디어가 있지만 안티 패턴이 없습니다. 웹과 위키 백과의 정의는 저를 혼동합니다.

반 패턴이 무엇인지 간단한 단어로 나에게 설명 할 수 있습니까? 목적은 무엇입니까? 그들은 무엇을합니까? 나쁜 것입니까 좋은 것입니까?

안티 패턴은 소프트웨어 개발에서 특정 프로그래밍 패턴으로 간주되는 특정 패턴입니다.

반대로 디자인 패턴 공식화되었으며, 일반적으로 좋은 개발 관행을 고려 일반적인 문제에 대한 일반적인 접근하고, 안티 패턴은 반대하고 바람직하지 않다.

예를 들어, 객체 지향 프로그래밍에서 아이디어는 소프트웨어를 객체라고하는 작은 조각으로 분리하는 것입니다. 객체 지향 프로그래밍의 안티 패턴은 다른 객체로 더 잘 분리되는 많은 기능을 수행하는 God 객체 입니다.

예를 들면 다음과 같습니다.

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

위의 예제에는 모든 것을 수행하는 객체가 있습니다 . 객체 지향 프로그래밍에서 코드를 덜 결합하고 궁극적으로 더 유지하기 쉽도록 다른 객체에 대해 잘 정의 된 책임을 갖는 것이 바람직합니다.

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

결론은 일반적으로 사용되는 패턴 ( 디자인 패턴 ) 으로 소프트웨어를 개발하는 좋은 방법이 있지만 문제를 일으킬 수있는 소프트웨어가 개발되고 구현되는 방법도 있습니다. 잘못된 소프트웨어 개발 관행으로 간주되는 패턴은 안티 패턴입니다.

안티 패턴에 대해들을 때마다 또 다른 용어 인 viz를 회상합니다. 냄새를 디자인하십시오.

"디자인 냄새는 기본 디자인 원칙을 위반하고 디자인 품질에 부정적인 영향을 미치는 디자인의 특정 구조입니다."( "소프트웨어 디자인 냄새에 대한 리팩토링 : 기술 부채 관리")

위반하는 설계 원칙에 따라 분류 된 많은 설계 냄새가 있습니다.

추상화 냄새

누락 된 추상화 : 이 냄새는 클래스 나 인터페이스를 만드는 대신 데이터 덩어리 나 인코딩 된 문자열을 사용할 때 발생합니다.

명령형 추상화 : 이 냄새는 작업이 클래스로 바뀔 때 발생합니다.

불완전한 추상화 : 이 냄새는 추상화가 상보 적이거나 상호 관련된 방법을 완전히 지원하지 않을 때 발생합니다.

다각적 추상화 : 이 냄새는 추상화에 하나 이상의 책임이 할당 된 경우 발생합니다.

불필요한 추상화 : 이 냄새는 실제로 필요하지 않은 (따라서 피할 수있는) 추상화가 소프트웨어 디자인에 도입 될 때 발생합니다.

사용되지 않은 추상화 : 이 냄새는 추상화가 사용되지 않은 상태 (직접 사용되지 않거나 도달 할 수없는 상태) 인 경우에 발생합니다.

중복 추상화 : 이 냄새는 둘 이상의 추상화가 동일한 이름 또는 동일한 구현 또는 둘 다를 갖는 경우에 발생합니다.

캡슐화 냄새

불충분 한 캡슐화 : 이 냄새는 하나 이상의 추상화 멤버의 선언 된 접근성이 실제로 필요한 것보다 더 관대 할 때 발생합니다.

누출 캡슐화 : 이 냄새는 추상화가 공용 인터페이스를 통해 구현 세부 정보를 "노출"또는 "누설"할 때 발생합니다.

캡슐화 누락 : 이 변형은 구현 변형이 추상화 또는 계층 구조 내에 캡슐화되지 않은 경우에 발생합니다.

Unexploited Encapsulation : 계층 구조 내에 이미 캡슐화 된 유형의 변형을 악용하는 대신 클라이언트 코드에서 명시적인 유형 검사 (객체 유형을 확인하는 체인 if-else 또는 switch 문 사용)를 사용할 때 발생합니다.

모듈화 냄새

부서진 모듈화 : 이 냄새는 이상적으로 단일 추상화로 지역화해야하는 데이터 및 / 또는 방법이 분리되어 여러 추상화에 분산 될 때 발생합니다.

불충분 한 모듈화 : 이 냄새는 완전히 분해되지 않은 추상화가 존재할 때 발생하며, 추가 분해로 크기, 구현 복잡성 또는 둘 다를 줄일 수 있습니다.

순환 종속 모듈화 : 이 냄새는 둘 이상의 추상화가 직간접 적으로 서로 의존 할 때 발생합니다 (추상화 사이에 긴밀한 결합 생성).

Hub-Like Modularization : 이 냄새는 추상화에 많은 다른 추상화와 종속성 (들어가고 나가는)이있을 때 발생합니다.

계층 적 냄새

계층 구조 누락 : 이 냄새는 코드 세그먼트가 조건부 논리 (일반적으로 "태그 유형"과 함께)를 사용하여 계층 구조를 생성하고 해당 변형을 캡슐화하는 데 사용할 수있는 동작의 변형을 명시 적으로 관리 할 때 발생합니다.

불필요한 계층 : 이 냄새는 전체 상속 계층이 불필요 할 때 발생하며, 이는 특정 디자인 컨텍스트에 대해 상속이 불필요하게 적용되었음을 나타냅니다.

Unfactored Hierarchy (계층화되지 않은 계층) : 이 냄새는 계층 구조의 유형간에 불필요한 복제가있을 때 발생합니다.

넓은 계층 : 이 냄새는 상속 계층이 "너무"넓 으면 중간 유형이 누락 될 수 있음을 나타냅니다.

추론 적 계층 구조 : 이 냄새는 계층 구조에서 하나 이상의 유형이 추론 적으로 제공 될 때 발생합니다 (즉, 실제 요구 사항이 아닌 상상의 요구에 기초 함).

딥 계층 : 이 냄새는 상속 계층이 "과도하게"깊을 때 발생합니다.

반항적 계층 : 이 냄새는 하위 유형이 상위 유형이 제공하는 방법을 거부 할 때 발생합니다.

부서진 계층 : 이 냄새는 상위 유형과 하위 유형이 개념 상“IS-A”관계를 공유하지 않아 대체 가능성이 깨진 경우에 발생합니다.

다중 경로 계층 : 이 냄새는 하위 유형이 계층에서 불필요한 상속 경로로 이어지는 수퍼 유형에서 간접적으로 또는 간접적으로 모두 상속 될 때 발생합니다.

순환 계층 : 이 냄새는 계층의 상위 유형이 하위 유형에 의존 할 때 발생합니다.

위의 정의와 분류는 "소프트웨어 디자인 냄새에 대한 리팩토링 : 기술 부채 관리"에 설명되어 있습니다. 좀 더 관련 리소스는 여기 에서 찾을 수 있습니다 .

패턴은 어떤 클래스의 문제를 해결하는 방법에 대한 아이디어입니다. 안티 패턴은 그 아이디어를 구현하면 디자인이 나빠질 수 있으므로 해결하지 않는 방법에 대한 아이디어입니다.

예를 들어 "패턴"은 코드 재사용을위한 함수를 사용하고 "패턴 안티"는 복사 붙여 넣기를 사용하는 것입니다. 둘 다 같은 문제를 해결하지만 함수를 사용하면 일반적으로 복사하여 붙여 넣기보다 더 읽기 쉽고 유지 관리가 쉬운 코드가 만들어집니다.

안티 패턴은 문제를 해결하지 않는 방법입니다. 그러나 더 많은 문제가 있습니다. 또한 문제를 해결하려는 시도에서 자주 볼 수있는 방법이기도합니다.

AntiPatterns를 공부하고 싶다면 AntiPatterns (ISBN-13 : 978-0471197133)를 참고하십시오.

이 문서에서 "안티 패턴은 결정적으로 부정적인 결과를 초래하는 문제에 대해 일반적으로 발생하는 솔루션을 설명하는 문학적 형식입니다."라고 정의합니다.

따라서 나쁜 프로그래밍 관행이지만 하나의 응용 프로그램, 한 회사 또는 한 명의 프로그래머로 제한되는 일반적인 관행이 아닌 경우 AntiPattern 정의의 "Pattern"부분을 충족하지 않습니다.

혼란을 일으키는 일반적인 방법입니다. 예를 들어, 신 / 주방 싱크 클래스와 같이 (모든 것을 수행함).

흥미롭게도 문제를 해결하는 주어진 방법은 패턴과 반 패턴 일 수 있습니다. 싱글 톤이 대표적인 예입니다. 두 문헌에 모두 나타납니다.

안티 패턴은 a의 보완 디자인 패턴 . 안티 패턴은 특정 상황에서 사용해서는 안되는 템플릿 솔루션입니다.

단지와 같은 디자인 패턴 , 안티 패턴은 템플릿과 특정 문제를 해결하는 반복 가능한 방식으로하지만, 최적이 아닌 비효율적 인 방법이기도하다.

오늘날 소프트웨어 공학 연구자와 실무자들은 종종“반 패턴”과“냄새”라는 용어를 서로 바꿔서 사용합니다. 그러나 개념 상으로는 동일하지 않습니다. 안티 패턴의 Wikipedia 항목은 안티 패턴이 적어도 두 가지 요소에 의해 나쁜 습관이나 나쁜 생각과 다르다는 것을 나타냅니다. 반 패턴은

"처음에 문제에 대한 적절하고 효과적인 대응으로 보임에도 불구하고 일반적으로 사용되는 프로세스, 구조 또는 행동 패턴은 일반적으로 유익한 결과보다 더 나쁜 결과를 초래합니다."

그것은 반 패턴이 제시된 문제에 대한 좋은 해결책 (패턴으로서)이라는 믿음으로 선택되었음을 분명히 나타냅니다. 그러나 혜택보다 부채가 더 많습니다. 반면, 냄새는 단순히 소프트웨어 시스템의 품질에 부정적인 영향을 미치는 나쁜 습관입니다. 예를 들어, Singleton은 안티 패턴이며 God 클래스 (또는 불충분 한 모듈화)는 디자인 냄새입니다.

안티 패턴은 사람들이 잘못된 방식으로 프로그래밍하는 경향이 있거나 적어도 그렇게 좋지 않은 방식으로 프로그래밍하는 일반적인 방법입니다.

주어진 소프트웨어 개발 환경에 좋지 않은 것보다 더 해로운 디자인 패턴은 안티 패턴으로 간주됩니다.

일부 반 패턴은 명백하지만 일부는 그렇지 않습니다. 예를 들어 Singleton은 많은 사람들이 좋은 오래된 디자인 패턴을 고려하지만 그렇지 않은 사람들도 있습니다.

당신은 질문을 확인할 수 있습니다 싱글 톤에 대해 무엇이 그렇게 나쁜가요? 그것에 대한 다른 의견을 더 잘 이해합니다.

알고리즘에서와 같이 Brute force를 사용하여 솔루션을 달성 할 수 있지만 상황이 복잡해지면 많은 비용을 지불해야합니다.