컴포지션 객체를 노출해야합니까?

Question

여기에이 디자인을 사용합니다.

외부 세계에서 사용자와 서비스를 구성 할 수 있도록 일부 API를 게시해야합니다. 사용자 구성에는 주로 입력 매개 변수 (예 : id, password, level 등)를 기반으로 새 사용자를 생성하고 새 연결 객체를 만드는 작업이 포함됩니다. 사용자 개체가 생성되면 서비스 구성이 필요합니다. 이것은 서비스를 가능하게하고 서비스 세부 사항을 수정하는 두 단계 프로세스입니다. 서비스 세부 사항 수정은 일련의 조치로 구성됩니다. 이러한 작업은 해당 서비스에만 해당됩니다. 이러한 작업은 다른 서비스와 다를 수 있습니다.

여기에 내 현재 구현

사용자 클래스가 service_manager, 연결, 그룹 수업으로 구성되어있다. service_manager 클래스는 일련의 서비스 (예 : ServiceA, ServiceB ... ServiceN)를 관리합니다. 각 서비스마다 seaparate 클래스가 있습니다.

사용자 클래스에는 공용 함수 assignService가 있습니다. 이 함수는 서비스 클래스를 식별하는 데 필요한 인수를 취합니다. 해당 서비스 클래스의 객체를 반환합니다. 여기에 같은 코드가 있습니다.

serviceObjectA = user.assignService ('A'); 

나중에이 서비스 객체는 해당 서비스에 액션, 특정을 수행 할 수 있습니다. 여기

serviceObjectA.performActionA1(...); 
serviceObjectA.performActionA2(...); 
serviceObjectA.performActionA10(...); 

문제, 난이 구현에 직면하고있다 :

이)가 performAction 기능은 ID, 비밀번호, 위치 등)와 연결 개체처럼 (사용자 클래스의 몇 가지 속성을 필요로

. 이러한 사용자 속성은 요청을 준비하는 데 필요합니다. 연결 개체는 이미 생성 된 연결을 통해이 요청을 보내야합니다. 현재 서비스 클래스 생성자에서 관리하고 있습니다. 여기서 생성자 인수로 이러한 사용자 속성과 연결 객체를 전달합니다. 다양한 서비스 클래스가 서로 다른 사용자 속성을 요구하기 때문에 약간의 관리가 불가능 해지고 있습니다.

일부 대안을 제안하십시오.

b) 서비스 개체를 외부 세계에 노출시키는 것이 실제로 좋은 방법입니까?

나는 아직도 OOP 세계에 처음이다. 그래서 내가 잘못 이해하면 사과한다. 가상 예제로 설명 할 수 있다면 정말 좋을 것입니다. 당신의 몇 가지 문제를 해결하기

Answer 1

한 가지 방법은 builder pattern

그래서 당신이 다른 모든 옵션에 맞게 더 많은 매개 변수와 생성자 등의 규칙을 사용하지 않을 수행하는 것입니다. 생성자에서 필요한 모든 옵션을 요구하는 대신 필요한 모든 옵션을 사용하여 설정할 수있는 "builder"클래스를 만든 다음 제대로 설정된 클래스를 빌드 (인스턴스 반환) 할 수 있습니다.

이것은 공용 생성자가 없지만 정적 팩토리 메소드가없는 다른 옵션과 유사합니다. 이것은 생성자가 구별하기 어려워지고 매개 변수가 제어 불능 상태가되는 경우에 유용합니다. 정적 팩토리 메서드를 사용하면 메서드 이름을보다 잘 설명하고 모호성과 복잡성을 피할 수 있습니다. 실효성있는 Java에는 이와 관련된 몇 가지 주제가 있으며 좋은 디자인 패턴에 대한 심층적 인 토론을 위해 좋은 읽을 거리가 될 것입니다.

디자인과 사용법에 대해 잘 알지 못하면 무엇을 노출시켜야하며 무엇을해서는 안되는지 말하기는 어렵습니다. 클래스의 사용자가 "사용자"와 만 상호 작용하도록하여 여러 가지 서비스로 작업이 수행된다는 사실을 숨기는 것이 나을 것 같습니다. 이렇게하면 복잡성이 약간 줄어들고 나중에 구현을 변경할 수 있습니다.