Class структура образец вопрос. Что выбрать?

Question

Что (если таковые имеются) подразумеваемые предположения или ограничения и различия в проектировании, как:

А) это:

class SampleClass1 
{ 
    IWorker workerA; 
    IWorker workerB; 

    void setWorkerA(IWorker w); 
    void setWorkerB(IWorker w); 
    WorkResult doWork(); 
} 

B) по сравнению с этим:

class SampleClass2 
{ 
    WorkResult doWork(IWorker workerA, IWorker workerB); 
} 

Я знаю, зависит от конкретного проекта, но что, если вышеуказанный класс является частью небольшой структуры? Первый класс способен поддерживать состояние и отделять шаги более естественно, но второй класс обеспечивает «связь в реальном времени» с внешним вызывающим абонентом более естественно, поскольку рабочий передается каждый раз, когда вызывается doWork().

Есть ли рекомендуемые способы использования или общие методы, которые определяют выбор между двумя способами? Благодарю.

Answer 1

В опции (A) вы создаете так называемый объект функции или функтор, это шаблон проектирования, который составляет well documented.

Двумя основными преимуществами являются:

• Рабочие могут быть установлены в одном месте, а затем объект, используемый в других
• Объект может сохранять состояние между вызовами

Кроме того, если вам используют конструкцию инъекций зависимостей (Spring, Guice и т. д.), функтор может автоматически инициализироваться и вводиться там, где это необходимо.

Функциональные объекты широко используются в библиотеках, например. C++ Стандартная библиотека шаблонов

Answer 2

Другой вариант:

IWorker Класс:

статическая WorkResult DoWork (Iworker а, Iworker б);

Answer 3

Если более чем один метод зависит от IWorker а и б IWorker, я говорю сделать образец A.

Если только DoWork() использует как IWorker а и б IWorker, затем сделать образец B.

Кроме , какова реальная цель вашего SampleClass? doWork выглядит немного как полезный метод mroe, чем что-либо еще.

Answer 4

A) - плохой дизайн, поскольку он позволяет дефекту объекта (один или оба рабочих класса могут быть не установлены).

B) может быть хорошим. Сделайте это неподвижным, хотя если вы не зависнете от внутреннего состояния SampleClass2

Answer 5

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

Answer 6

Как насчет определения WorkDelegate (или, альтернативно, интерфейса, имеющего единственный метод doWork без аргумента), который просто возвращает WorkResult и позволяет отдельным классам решить, как они его реализуют? Таким образом, вы не ограничиваетесь преждевременными решениями.

Answer 7

SampleClass1

• мне может понадобиться для поддержания состояния рабочих между DoWork
• мне может понадобиться возможность установки Рабочие индивидуально. (doWork с 1 и 2, затем с 2 и 3)
• Я хочу содержать рабочих, потому что от них можно было бы работать несколько раз на тех же рабочих.
• Я не являюсь классом полезности. Экземпляр меня очень важен.

SampleClass2

• Дайте мне два рабочих, и я буду делать с ними работать.
• Мне все равно, кто они, и я не хочу их поддерживать.
• Это чужая работа по поддержанию любых связей между работниками.
• Я могу быть более полезным классом. Может быть, я могу быть просто статичным.

Answer 8

Другой вариант, вариант случая А, имеет следующий вид:

 
class SampleClass3 
{ 
    SampleClass3(IWorker workerA, IWorker workerB); 
    WorkResult doWork(); 
} 

Преимущества:

• Это сложнее сделать объект неисправен, так как вы должны для поставки всем работникам, которые необходимы во время строительства (в отличие от случая A).

• Вы все еще можете переносить состояние внутри SampleClass3 и/или одного из рабочих. (Это невозможно в случае Б.)

Недостатки:

• Вы должны иметь все ваши рабочие готовы, прежде чем построить SampleClass3, вместо того, чтобы быть в состоянии обеспечить их позже. Конечно, вы также можете предоставить сеттеры, чтобы их можно было изменить позже.