“관리자”수업 사용을 줄이는 방법에 대한 팁 / 조언?

프로그램 디자인에 너무 많은 "관리자"클래스가 있으면 코드 냄새가 나고 불필요한 복잡성이 추가되는 경우가 있습니다. 나에게 사람들은 이해하기 쉬운 컨텍스트에서 객체를 조작하고 제어하기 위해 관리자 클래스를 사용하고 싶지만 솔루션없이 솔루션을 작동시키는 방법을 알아내는 것은 혼란 스러울 수 있습니다.

관리자 클래스를 최대한 많이 피해야합니까? 또한 이러한 관리자를 제거 할 수있는 일반적인 / 일반적인 경우에 대안 대안을 구현하는 방법에 대한 기사 / 논문을 읽어야합니까?

이것이 코드 냄새 인 이유는 두 가지가 있습니다. 한 가지 이유는 도메인 객체가 없지만 컨트롤러 또는 관리자 클래스에 의한 조작을 위해 데이터를 저장하는 값 객체가 있다는 의미 일 수 있습니다. 이것은 실제로 매우 일반적이며 OO 언어의 절차 적 프로그래밍에 해당합니다. "많은 관리자"는 실제로 상태 캡슐화를 위해 상태 논리, 유효성 검사 및 기타 직접적인 문제를 도메인 객체에 통합해야한다는 힌트 일 수 있습니다. 물론 getter / setter 이외의 방법이 없다는 사실과 같은 더 큰 힌트가 있습니다.

코드 냄새가 나는 다른 이유는 도메인 객체가 실제로 서로 관련이없는 것을 의미 할 수 있기 때문입니다. 예를 들어 Transaction 클래스에 Transaction이라는 이름을 제외하고 Transaction 클래스에 대해 전혀 알지 못하는 Account 클래스가 있고 그 중 둘 이상이있을 수있는 경우에는 매우 역동적 인 비즈니스 도메인 구현이 없습니다. 예를 들어, SavingsAccount는 accountStatus가 닫히면 DebitTransaction을 승인 할 수 없음을 알아야합니다. 많은 구현은 이것을 관리자에게 맡길 것입니다.

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

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

관리자 클래스의 가장 큰 문제는 클래스가 무엇을해야하는지에 대한 모호한 아이디어 만 나타내는 것입니다. 관리자라고 부르면 관리하는 모든 것과 관련하여 가능한 모든 작업을 수행 할 수 있습니다. 나는 어떤 상황에서는 괜찮을 것이라고 생각하지만, 거의 모든 경우에 당신이 원하는 것이 아니라고 말할 것입니다. 당신은 누군가가 클래스 이름을 볼 수 있기를 원하며 클래스가 무엇을하는지뿐만 아니라 클래스가 무엇을하는지에 대한 감히 좋은 아이디어를 갖기를 원합니다.

관리자 클래스의 또 다른 문제점은 기능을 수행 할 위치를 결정하기가 매우 어렵다는 것입니다. 관리자 클래스가 많으면 관리자 클래스간에 기능이 많이 중복되는 경우가 많습니다. 그런 다음 중복 기능을 구현해야하는 클래스와 다른 사람이 다르게 선택한 클래스를 파악해야합니다. 따라서 기능을 찾고 기대하는 위치를 찾지 못하면 다른 구현의 존재를 알지 못하기 때문에 자신이 속한 것으로 생각하는 곳에서 다시 구현합니다. 다시 말해, 관리자 클래스는 이해하기 어렵고 자주 복잡한 디자인을 만듭니다.