관리자 클래스가 잘못된 아키텍처의 표시 일 수 있습니까?

최근에는 디자인에 많은 관리자 클래스가있는 것이 좋지 않다고 생각하기 시작했습니다. 이 아이디어는 내가 설득력있는 주장을하기에 충분히 성숙하지 못했지만 몇 가지 일반적인 요점이 있습니다.

• "관리자"에 크게 의존하는 시스템을 이해하기가 훨씬 어렵다는 것을 알았습니다. 실제 프로그램 구성 요소 외에도 관리자가 사용되는 방법과 이유를 이해해야하기 때문입니다.

• 프로그래머는 프로그래머가 Just Work ^TM 프로그램을 만들 수있는 방법을 찾지 못하고 모든 것이 올바르게 작동하도록 관리자 클래스에 의존해야 할 때와 같이 디자인 문제를 완화하는 데 자주 사용되는 것 같습니다 .

물론 관리자가 좋을 수 있습니다. 명백한 예는 EventManager내가 가장 좋아하는 구성 중 하나입니다. : P 내 요점은 관리자가 많은 시간을 과용 한 것으로 보이며, 프로그램 아키텍처의 문제를 가리는 것 외에는 특별한 이유가 없다.

관리자 클래스는 실제로 나쁜 아키텍처의 표시입니까?

관리자 클래스는 몇 가지 이유로 잘못된 아키텍처의 표시 일 수 있습니다.

• 무의미한 식별자

  이름은 FooManager클래스가 실제로 무엇에 대해 아무것도 말하지 않는다 않습니다 어떻게 든 관련된 것을 제외하고, Foo인스턴스를. 클래스에보다 의미있는 이름을 부여하면 진정한 목적을 밝힐 수 있으며 이는 리팩토링으로 이어질 수 있습니다.

• 분수 책임

  단일 책임 원칙에 따라 각 코드 단위는 정확히 하나의 목적을 수행해야합니다. 관리자는 인위적으로 책임을 분담하고있을 수 있습니다.

  인스턴스의 ResourceManager수명과 액세스를 조정 하는 것을 고려하십시오 Resource. 애플리케이션에는 인스턴스를 ResourceManager획득하는 데 사용 되는 단일 애플리케이션이 Resource있습니다. 이 경우 클래스의 ResourceManager정적 메소드 가 인스턴스 의 기능을 제공 할 수 없는 실제 이유는 없습니다 Resource.

• 비정형 추상화

  관리자가 관리하는 객체의 근본적인 문제를 추상화하기 위해 종종 소개됩니다. 그렇기 때문에 관리자는 제대로 설계되지 않은 시스템의 반창고로 악용 될 수 있습니다. 추상화는 복잡한 시스템을 단순화하는 좋은 방법이지만“관리자”라는 이름은 그것이 나타내는 추상화 의 구조 에 대한 단서를 제공하지 않습니다 . 실제로 공장입니까, 프록시입니까, 아니면 다른 것입니까?

물론 관리자도 같은 이유로 악한 것 이상으로 사용될 수 있습니다. EventManager- 어떤 정말입니다 Dispatcher소스에서 -queues 이벤트와 관심을 목표로 전달합니다. 이 경우 개인 Event은 출처 나 목적지에 대한 개념이없는 메시지 일 뿐이 므로 이벤트 수신 및 전송의 책임을 분리하는 것이 좋습니다 .

우리는 쓰기 Dispatcher의 Event우리가 쓰기 본질적으로 같은 이유로 인스턴스 GarbageCollector또는를 Factory:

관리자는 페이로드가 알 필요가없는 것을 알고 있습니다.

내 생각에 관리자와 같은 클래스를 만드는 데있어 최고의 정당성이 있다고 생각합니다. 값처럼 동작하는 "페이로드"개체가있는 경우 전체 시스템이 유연하게 유지되도록 가능한 한 바보가되어야합니다. 개별 인스턴스에 의미를 부여하기 위해 해당 인스턴스를 의미있는 방식으로 조정 하는 관리자를 만듭니다 . 다른 상황에서는 관리자가 필요하지 않습니다.

관리자 는 나쁜 아키텍처의 표시 일 수 있지만, 종종 디자이너를 대신하여 자신의 객체에 대한 더 나은 이름을 만들지 못하거나 단순히 영어가 (그리고 그 문제에 대한 모든 인간의 언어)는 일상적인 실제 개념을 전달하는 데 적합하지만 고도로 추상적이고 고도의 기술 개념은 아닙니다.

내 요점을 설명하는 간단한 예 : 팩토리 패턴의 이름을 지정 하기 전에 사람들이 그것을 사용했지만 호출 방법을 몰랐습니다. 따라서, 자신의 Foo반을 위해 공장을 써야했던 누군가가 그것을 불렀을 것 FooAllocationManager입니다. 그것은 나쁜 디자인이 아니며 상상력이 부족한 것입니다.

그리고 누군가는 많은 공장을 유지하고 그것을 요구하는 다양한 물건에 그것들을 건네주는 클래스를 구현해야합니다. 그리고 그는 FactoryManager그 단어 Industry가 그에게 결코 발생하지 않았기 때문에 그의 반을 부릅니다 . 다시 한 번 상상력이 부족한 경우입니다.

많은 "관리자"클래스를 갖는 것은 빈번한 도메인 모델 의 증상 인 경우가 많으며 , 도메인 로직이 도메인 모델 에서 들어올 려져 대신 트랜잭션 클래스와 같은 관리자 클래스에 배치됩니다 . 여기서의 위험은 기본적으로 절차 적 프로그래밍으로 되돌아가는 것입니다. 프로젝트 자체에 따라 그 자체로는 좋지 않을 수도 있지만 실제로 고려되지 않았거나 실제로 의도하지 않은 것은 실제 문제입니다.

"정보 전문가" 의 원칙에 따라 논리적 작업은 가능한 한 필요한 데이터에 가깝게 있어야합니다. 이것은 도메인 로직을 도메인 모델로 다시 옮기는 것을 의미하므로 도메인 매니저의 상태를 외부에서 변경하는 '관리자'보다는 도메인 모델의 상태에 관찰 가능한 영향을 미치는 것은 논리적 조작입니다.

짧은 대답 : 그것은 달려 있습니다.

"관리자 클래스"에는 몇 가지 뚜렷한 형태가 있으며, 일부는 훌륭하고, 일부는 좋지 않으며, 대부분은 관리자 클래스를 도입하는 것이 옳은 경우 상황에 따라 크게 달라집니다. 올바른 책임을 갖기 위한 좋은 출발점은 단일 책임 원칙 을 따르는 것입니다. 각 관리자 클래스가 무엇을 담당하고 있는지에 대해 정확히 알고 있다면 이해하는 데 훨씬 적은 문제가 발생합니다.

또는 귀하의 질문에 직접 대답하는 것은 잘못된 아키텍처를 나타내는 관리자 클래스의 수가 아니라 명확하지 않은 책임을 가지고 있거나 너무 많은 우려를 처리하는 관리자 클래스의 수입니다.

그것들이 본질적으로 나쁜 디자인을 나타내는 것이라고 말하기는 쉽지만, 단일 작업과 책임을 보편적으로 포괄함으로써 프로젝트 전반에 걸쳐 많은 장점을 가져오고 코드 복잡성과 기타 상용구 코드를 줄이는 데 도움이 될 수 있습니다.

관리자의 유병률은 설계에 대한 판단 부족으로 인한 것일 수 있지만, 구성 요소 화 된 설계 또는 타사 UI 구성 요소의 다른 구성 요소 또는 이상한 인터페이스가있는 타사 웹 서비스와의 불량한 설계 결정 또는 비 호환성 문제를 처리해야 할 수도 있습니다. 예를 들어.

이 예제는 "복잡한 코드"를 한 곳에서 캡슐화하여 전반적인 복잡성을 줄이고 다양한 구성 요소와 계층 간의 느슨한 결합을 촉진하는 특정 상황에 매우 유용한 위치를 보여줍니다. 한 가지 단점은 사람들이 관리자를 싱글 톤으로 만드는 유혹을 느낀다는 것입니다. 나는 이것에 반대하고 다른 사람들이 항상 단일 책임 원칙을 따라야한다고 제안 했으므로 조언합니다.

관리자 클래스가 잘못된 아키텍처의 표시 일 수 있습니까?

당신은 당신의 질문에 대답했습니다 : 그들은 나쁜 디자인의 표시 일 필요는 없습니다.

EventManager에 대한 질문의 예를 제외하고 다른 예가 있습니다. MVC 디자인 패턴에서 발표자는 모델 / 뷰 클래스의 관리자로 볼 수 있습니다.

그러나 개념을 잘못 사용하면 디자인이 잘못되고 아키텍처가 잘못 될 수 있습니다.

수업에서 이름에 "관리자"가 있으면 신 수업 문제 (책임이 너무 많은 문제)에 주의하십시오 . 클래스가 그 이름으로 담당하는 것을 설명하기 어려운 경우, 이는 디자인 경고 신호입니다.

나쁜 관리자 클래스는 제쳐두고 내가 본 최악의 이름은 "DataContainerAdapter"

"데이터"는 이름에서 금지 된 부분 문자열 중 하나 여야합니다. "데이터"는 모든 데이터이므로 "데이터"는 대부분의 도메인에서 많은 것을 알려주지 않습니다.

"-er"로 끝나는 거의 모든 클래스 와 마찬가지로 관리자 클래스 는 악의적이며 OOP와 관련이 없습니다. 나에게 그것은 나쁜 건축의 징조입니다.

왜? "-er"이름은 코드 디자이너가 조치를 취하여 클래스로 변환했음을 의미합니다. 결과적으로 우리는 유형의 개념을 반영하지 않고 어떤 행동을하는 인공적인 개체를 갖게됩니다. 매우 절차적인 소리입니다.

그 외에도 일반적으로 이러한 클래스는 일부 데이터를 가져 와서 작동합니다. 이것은 수동적 데이터와 능동적 인 절차 의 철학이며 절차 적 프로그래밍에서 그 자리를 찾았습니다. 그것을 알고 있다면 Manager 클래스에는 나쁜 것이 없지만 OOP는 아닙니다.

객체 사고는 객체가 스스로 일을한다는 것을 의미합니다. 당신의 영역을 발견 하고 시맨틱 한 그물을 만들고 , 당신의 사물이 살아있는 유기체, 영리하고 책임감있는 인간이되도록하십시오.

이러한 개체는 제어 할 필요가 없습니다. 그들은 무엇을하고 어떻게해야하는지 알고 있습니다. 따라서 관리자 클래스는 OOP 원칙을 두 번 깨뜨립니다. "-er"클래스 일뿐 아니라 다른 객체를 제어합니다. 그러나 그것은 관리자에 달려 있습니다. 그는 통제합니다. 그는 나쁜 관리자입니다. 그가 협조한다면-그는 훌륭한 관리자입니다. 그렇기 때문에 MVC 의 "C"문자 를 "코디네이터"로 표기해야합니다.

이 질문에 대한 정답은 다음과 같습니다.

1. 따라 다릅니다.

소프트웨어를 작성하는 동안 발생하는 모든 상황은 다릅니다. 어쩌면 모든 사람이 관리자 클래스의 내부 작동 방식을 알고있는 팀에 속해 있습니까? 그 디자인을 사용하지 않는 것은 완전히 미친 짓입니다. 또는 관리자 디자인을 다른 사람에게 푸시하려는 경우 나쁜 생각 일 수 있습니다. 그러나 그것은 정확한 세부 사항에 달려 있습니다.