이 코딩 방법을 설명하는 반 패턴이 있습니까? [닫은]

프로그래머가 이해가되지 않는 영역에서 일을 마무리하는 코드베이스가 있습니다. 예를 들어, 오류 로그가 있으면

ErrorLog.Log(ex, "friendly message");

그는 동일한 작업을 수행하기 위해 다양한 다른 수단을 추가했습니다. EG

SomeClass.Log(ex, "friendly message");

간단히 돌아 서서 첫 번째 메소드를 호출합니다. 이로 인해 추가 혜택없이 복잡성이 증가합니다. 이것을 설명하는 반 패턴이 있습니까?

합리적으로 널리 퍼져 있다면 나쁜 코딩 습관을 안티 패턴이라고 부르는 것만으로도 가치가 있습니다.

우리가 방금 "쓰레기 코드"라고 부르는 나머지는 ...

이 나쁜 습관에 대한 이름을 제안한다면 "추상적 추상화 장애"가 될 것입니다 :-)

아니요, 안티 패턴은 아니지만 다음과 같은 문제를 제기합니다.

단일 책임 원칙 위반

SRP는 수업이 바뀌어야 할 한 가지 이유가 있다고 말합니다. 로거 메소드를 추가하면 로깅 로직을 변경해야 할 경우 클래스도 변경해야합니다.

is-a관계 위반

기본 클래스는 몇 가지 편리한 메소드를 추가 할 수있는 도구 상자가 아닙니다.

그렇게하면 상속 된 모든 클래스가 기본 클래스의 구현과 효과적으로 결합됩니다.

컴포지션과 비교하십시오.

이것이 허용되는 것은 아니지만, 이것은 미완성 리팩토링 일 수 있습니다. 어쩌면 SomeClass.log ()는 자체 로직을 가지고 있었으며 처음 구현되었습니다. 그리고 나중에 그들은 ErrorLog.Log ()를 사용해야한다는 것을 깨달았습니다. 따라서 SomeClass.Log ()가 호출되는 100 개의 장소를 변경하는 대신 ErrorLog.Log ()에 위임했습니다. 개인적으로 나는 모든 참조를 ErrorLog.Log ()로 변경하거나 적어도 SomeClass.log ()에 주석을 달아 왜 그렇게 행동하는지 위임합니다.

고려해야 할 것.

"Lasagna Code"라는 용어는 제 생각에 떠오를 것 입니다. 나의 해석은 항상 "계층화를 위해 계층화되어있다".

ErrorLog 메서드 서명 (SomeClass에서 호출 한 메서드)이 변경되면이 메서드를 호출하는 모든 클라이언트 코드가 실패하기 때문에 단일 책임 원칙에 대한 위반으로 이것을 설명 할 수 없습니다.

상속을 사용하거나 로깅 인터페이스를 구현하는 로깅이 필요한 클래스를 만드는 방법이 분명히 있습니다.

또는 우리는 이것을 "교육 가능한 순간"으로 볼 수 있습니다 :)

개발자는 좋은 아이디어의 중간 쯤에있을 수 있습니다. 모든 비즈니스 오브젝트가 지능적으로 로깅 할 수 있어야한다는 요구 사항이 있다고 가정하십시오. 다음을 정의 할 수 있습니다.

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

이제 객체 내부에서 ErrorLog 객체를 사용하여 실제로 로깅을 수행 할 수 있으며 SomeClass 코드는 객체 별 값을 로그 메시지에 추가합니다. 그런 다음 비즈니스 오브젝트를 건드리지 않고 파일 기반, db 기반 또는 메시지 기반 로깅 기능을 구현하도록 로깅 API를 추가로 확장 할 수 있습니다.

이것이 자동으로 악한 지 확실하지 않습니다.

SomeClass.Log를 호출하는 경우 가장 확실하게 악의적이지만 Log가 SomeClass에서만 사용되는 경우 커플 링이 줄어들고 허용됩니다.

이것은 실제로 특정 코딩 스타일에서 매우 일반적이며, 사고 라인의 기본 자체는 반 패턴이 아닙니다.

아마도 더 넓은 코드베이스에 대한 지식없이 필연적으로 코딩하는 누군가의 결과 일 것입니다. "이 코드는 오류를 기록해야하지만 그 기능은 코드의 주요 목적이 아닙니다. 따라서이를 수행 할 메소드 / 클래스가 필요합니다. 나를 위해 ". 좋은 생각입니다. 그러나 ErrorLog가 존재한다는 것을 몰라도 SomeClass를 만들었습니다. 그런 다음 나중에 ErrorLog를 찾았으며, 사용한 메소드의 모든 사용법을 바꾸지 않고 메소드 호출을 ErrorLog로 만들었습니다. 이것이 문제가되는 곳입니다.

우연한 복잡성 은 해결해야 할 문제에 필수적이지 않은 컴퓨터 프로그램 또는 개발 프로세스에서 발생하는 복잡성입니다. 본질적인 복잡성은 피할 수없고 불가피하지만, 우발적 인 복잡성은 문제를 해결하기 위해 선택한 접근 방식으로 인해 발생합니다.

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

외관 패턴을 남용하거나 오해 할 수 있습니다 . 내가 작업 한 코드베이스에서 비슷한 것을 보았습니다. 개발자는 OO 디자인의 중요한 원칙을 이해하지 못하고 디자인 패턴에 열중했을 때 단계를 밟았습니다.

Facade 패턴을 잘못 사용하면 응용 프로그램 계층 전체에서 추상화 수준이 흐려집니다.

이 프로그래머가하는 일은 로깅 모듈에 직접 의존하지 않도록 일부 코드를 래핑하는 것입니다. 더 구체적인 정보가 없으면 더 구체적인 패턴을 지정할 수 없습니다. (이 래퍼가 유용하지 않은 것은 더 많은 정보없이 동의하거나 동의 할 수없는 귀하의 의견입니다.)

이것이 발생할 수있는 패턴은 Proxy , Delegate , Decorator , Composite 또는 통화 래핑, 숨기기 또는 분배와 관련이있는 패턴입니다. 개발이 불완전한 상태 일 수 있습니다.

나는 그것이 문화적 차이라고 상상할 수 있습니다. 이 특정 코드 기반에서 중복 기능을 수행해야하는 충분한 이유가있을 수 있습니다. 그런 이유로 쓰기 편한 이미지를 만들 수 있습니다. 내 안에 파이썬 프로그래머는 여전히 "이후이 나쁘다 말할 것입니다 . 바람직하게 그것을 할 단 하나의 --obvious 방법이 one--이어야하며 "하지만 일부 펄 사람은 "사실에 익숙 할 수있는 하나 이상있다 그것을하는 방법 ".