Шаблон состояния: почему класс контекста не реализует и не наследует абстрактный интерфейс / класс состояния?

Я читаю о паттерне «Состояние». Я только начал, поэтому, конечно, я начну с прочтения всей статьи в Википедии об этом.

Я заметил, что в обоих примерах в статье есть некоторый базовый абстрактный класс или интерфейс Java для общих методов / функций состояния. Затем есть несколько состояний, которые наследуются от базы и по-разному реализуют эти методы / функции. Затем есть класс Context, который имеет закрытый член типа State и который в любой момент может быть равен экземпляру одной из реализаций. Этот класс контекста также реализует те же методы и передает их в экземпляр текущего состояния, а затем имеет дополнительный метод для изменения состояния (или, в зависимости от дизайна, я понимаю, что изменение состояния может быть реакцией на один из реализованных методов) .

Почему этот класс контекста специально не «расширяет» или не «реализует» общий базовый класс / интерфейс State?


design-patterns state-pattern
person Ricket    schedule 28.05.2010    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Потому что состояние - это деталь реализации, а не часть ее интерфейса. Т.е. Контекст не Состояние, он только имеет Состояние. Пользователи контекста даже не должны знать о том, что он имеет состояние.

person Péter Török    schedule 28.05.2010
comment
Звучит отлично. Это чисто концептуально. Определенно имеет смысл, и у меня было такое чувство, но я думаю, мне просто нужно было услышать это от кого-то другого. :) - person Ricket; 28.05.2010
comment
@Ricket, еще одно замечание: хотя примеры Википедии показывают, что Контекст имеет тот же интерфейс, что и состояние, ИМО, это не неотъемлемая часть шаблона - интерфейсы могут быть немного или даже полностью разными. - person Péter Török; 28.05.2010
comment
@Ricket, есть и практическая выгода - интерфейс Context может быть проще, чем интерфейс State (как в примере State / StateContext). - person Jeff Sternal; 28.05.2010

arrow_upward
0
arrow_downward

Согласно GOF, это буквально говорит:

'Контекст может передать себя в качестве аргумента объекту State, обрабатывающему запрос. Это позволяет объекту State при необходимости обращаться к контексту ».

Глядя на их пример TCPConnection / TCPState, TCPState содержит конкретную ссылку на TCPConnection.

Таким образом, становясь более абстрактным, конкретное состояние может содержать ссылку на конкретный объект контекста состояния с целью установки нового состояния. Однако я также видел, как Subject / Observer использовался для обновления состояния вместо StateContext-> setState (State).

Я также видел, как у людей есть StateContext, реализующий интерфейс State для интерфейса, зависящего от предметной области.

person Alex. A    schedule 26.12.2019