Разница между стратегией и паттерном государственного дизайна. Как государство осознает своего предшественника? - PullRequest
0 голосов
/ 31 декабря 2018

Я читал о шаблонах разработки состояния и стратегии в refactoring.guru веб-сайте на страницах Состояние и Стратегия .Автор говорит:

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

Автор также говорит, что классы ConcereteState хранят переменную context, которая является объектом класса Context, и по этой переменной состояния могут знать друг друга.

Есть две вещи, которые я не могу понять:

  1. Как государство знает о своем предшественнике?
  2. Где я должен реализовать логикупереход между состояниями?Например, state1 по вводу a перемещается в state2, а по b перемещается в state4, где именно эта логика должна быть реализована?

Это простая реализация стратегииЯ реализовал на языке php

<?php
class Algorithms{
    public $algorithm;
    function __construct(AlgorithmsInterface $algorithm){
        $this->algorithm = $algorithm;
    }

    public function run(){
        $this->algorithm->run();
    }
}

interface AlgorithmsInterface{      
    public function run();
}

class Algorithm1 implements AlgorithmsInterface{
    public function run(){
        print "Algorithm1";
    }
}

class Algorithm2 implements AlgorithmsInterface{
    public function run(){
        print "Algorithm2";
    }
}


$payment = new Algorithms(new Algorithm2());
$payment->run();

, и это простая реализация шаблона проектирования State. Я реализовал

<?php
    interface State{
        public function execute();
    }

    class Context{

        public $state;

        public function __construct(State $initialState){
            $this->state = $initialState;
        }

        public function changeState(State $state){
            $this->state = $state;
        }

        public function execute(){
            $this->state->execute();
        }
    }

    class State1 implements State{
        public function execute(){
            print "This is State1";
        }
    }

    class State2 implements State{
        public function execute(){
            print "This is State2";
        }
    }

    $initialState = new State1();
    $state2 = new State2();
    $context = new Context($initialState);
    $context->execute();
    $context->changeState($state2);
    $context->execute();

?>

. Пока я не вижу большой разницы между состоянием и стратегией Я точно знаю, каковы цели этих стратегий .Кроме того, логика движения между состояниями и способ, которым государство должно знать о своем родителе, пропущены в коде.

1 Ответ

0 голосов
/ 02 января 2019

Из ваших примеров две модели выглядят очень похожими.Но ваш пример шаблона проектирования State на самом деле не является шаблоном проектирования State, поскольку вы устанавливаете состояние извне.Типичный шаблон проектирования состояний внутренне изменяет состояние и очень часто делегирует изменение самому состоянию.Давайте посмотрим на простую кнопку переключения.У него есть состояние, метод для его нажатия и метод для описания текущего состояния (toString()):

class ToggleButton {
    enum State {
        ON {
            public State press() {
                return OFF;
            }
         },
         OFF {
             public State press() {
                 return ON;
             }
         };
         abstract public State press();
    }

    State state = State.OFF;
    public void press() {
        state = state.press();
    }
    public String toString() {
        return "Device is " + state;
    }
}

Итак, вы не устанавливаете состояние извне, поэтому вы не знаетекакое это состояние и как оно будет реагировать.Вы используете:

button.press();
System.out.println(button);

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

Но цель паттерна проектирования State состоит в том, что предполагается, что состояние изменяется очень часто внутренне, а с изменением состояния меняется и поведение.Таким образом, даже если мы устанавливаем какое-либо состояние перед вычислением какой-либо задачи, оно может измениться (как правило, меняется) во время выполнения задачи, чтобы выполнить его.Это способ достижения государственного полиморфизма.Также обратите внимание, что это часто связано с государственными автоматами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...