Должен ли я показывать объект композиции?

Question

Вот использование этого дизайна

Мне нужно опубликовать некоторые API, чтобы внешний мир мог настроить пользователя и его услуги. Конфигурирование пользователя в основном включает создание нового пользователя на основе входных параметров (например, id, password, level и т. Д.) И создание нового объекта подключения. После создания пользовательского объекта требуется настройка службы. Это двухэтапный процесс - включение службы, изменение деталей сервиса. Изменение сведений о сервисе состоит из набора действий. Эти действия относятся только к той службе. Эти действия будут отличаться для других служб.

Вот моя текущая реализация

Класс пользователя состоит из service_manager, связи, групповые занятия. класс service_manager управляет набором сервисов (скажем ServiceA, ServiceB ... ServiceN). Для каждого сервиса есть морской класс.

Пользовательский класс имеет публичную функцию assignService. Эта функция принимает аргумент, необходимый для идентификации класса службы. Он возвращает объект соответствующего класса обслуживания. Вот псевдо-код для того же самого.

serviceObjectA = user.assignService ('A'); 

Позже, этот объект сервиса может быть использован для выполнения действий, конкретных к этой службе.

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

Вот вопрос, я столкнулся с этой реализацией:

а) функция performAction нуждается несколько атрибутов класса пользователя (например, идентификатор, пароль, место и т.д.) и объект подключения. Эти атрибуты пользователя необходимы для подготовки запроса. Объект соединения требуется для отправки этого запроса по уже созданному соединению. В настоящее время я управляю им в конструкторе класса обслуживания, в котором я передаю эти пользовательские атрибуты и объект соединения в качестве аргументов конструктора. Это становится немного неуправляемым, поскольку различные классы обслуживания требуют разных пользовательских атрибутов.

Пожалуйста, предложите альтернативу этому.

b) Действительно ли это хорошая практика разоблачения объекта обслуживания внешним миром?

Я все еще новичок в мире ООП, поэтому извиняюсь, если что-то неправильно понял. Мне будет очень здорово, если вы сможете продемонстрировать это с помощью псевдо-примера.

Answer 1

Один из способов решить некоторые из ваших вопросов будут следовать builder pattern

Таким образом, вы не должны использовать условность, включая все больше и больше параметров и конструктор, чтобы удовлетворить все эти различные варианты. Вместо того, чтобы требовать все необходимые опции в конструкторе, у вас есть класс «строитель», который можно установить со всеми желаемыми параметрами, а затем построить (вернуть экземпляр) вашего класса, который настроен правильно.

Это похоже на другой вариант отсутствия публичных конструкторов, но статических заводских методов. Они полезны, если ваши конструкторы становятся трудно различимыми и параметры выходят из-под контроля. Наличие статических заводских методов означает, что вы можете быть более описательными с именем метода и избегать двусмысленности и сложности. Эффективная Java имеет несколько тем, связанных с этим, и будет хорошо читать для более глубокого обсуждения хороших шаблонов дизайна.

Не зная больше о вашем дизайне и его использовании, трудно сказать, что должно быть раскрыто, а что - нет. Мне кажется, что лучше, чтобы пользователи вашего класса взаимодействовали только с «User», скрывая тот факт, что действия выполняются различными службами. Это немного снижает сложность, и позволяет, если нужно, реализовать изменения позже.