Y>Не подумайте, что мне совсем нечем заняться в рабочее время Y>Спасибо.
Интерфейс говорит только о том, что наследующий его класс реализует два метода GetState() и SetState(), ну и назови его IState, будешь знать, что интерфейс с таким именем добавляет State-методы в класс
:)
Re: Как назвать интерфейс (GetState(), SetState(...))
Хм..
У меня объекты с таким интерфейсом попадают под действие Undo/Redo "движка".
Но это не единственное применение возможности поставить "доменную модель" приложения в какое-либо состояние из тех, в которых она когда-то была.
И по поводу "настолько" общих.
Если добавить, что GetState возвращает штуку, из которой через SetState можно "поставить" объект ровно в такое состояние, которое было, когда GetState эту штуку возвращал, то куда уж конкретнее?
Или глядя на такое объявление интерфейса эта "семантика" не очевидна?
Потому что можно по-разном трактовать слово State для объекта?
ЗЫ: Пока что назвал по-рабочекрестьянски IGetSetState
Re: Как назвать интерфейс (GetState(), SetState(...))
Похоже.
Но у меня, например, это слово вообще никаких ассоциаций не вызывает.
У тех, кому после меня это чудовище достанется, тоже, вероятно, не будет.
Re[2]: Как назвать интерфейс (GetState(), SetState(...))
C>Интерфейс говорит только о том, что наследующий его класс реализует два метода GetState() и SetState(),
А названия методов ни как не намекают на то, что методы должны делать?
(Я не выёживаюьс, тут ниже интерфейс укорят в излишней "общести", а я реально не догоняю, куда уж конкретней)
C> ну и назови его IState
State -- это то, что возвращается и принимается этими методами.
Или пофигу, так делают?
ЗЫ Я бы так не заморачивался, но код не только для внутреннего использования
Re[3]: Как назвать интерфейс (GetState(), SetState(...))
Здравствуйте, ylem, Вы писали:
VS>>А какой смысл в настолько общих интерфейсах?
Y>Хм.. Y>У меня объекты с таким интерфейсом попадают под действие Undo/Redo "движка".
После уточнения автора, что ему нужен Undo/Redo, становится понятно, что это паттерн хранитель (memento): там класс с методами GetState/SetState называется Memento, а приведенный пример кода — Ordinator.
Re[6]: Как назвать интерфейс (GetState(), SetState(...))
Здравствуйте, rsn81, Вы писали:
R>После уточнения автора, что ему нужен Undo/Redo, становится понятно, что это паттерн хранитель (memento): там класс с методами GetState/SetState называется Memento, а приведенный пример кода — Ordinator.
...то есть Originator.
Re[6]: Как назвать интерфейс (GetState(), SetState(...))
Здравствуйте, rsn81, Вы писали:
R>После уточнения автора, что ему нужен Undo/Redo, становится понятно, что это паттерн хранитель (memento): там класс с методами GetState/SetState называется Memento, а приведенный пример кода — Ordinator.
Ага. Только я предпочитаю чтобы из кода было видно для чего код был написан, а не сколько книжек асилил автор
Re[7]: Как назвать интерфейс (GetState(), SetState(...))
Здравствуйте, Sinix, Вы писали:
R>>После уточнения автора, что ему нужен Undo/Redo, становится понятно, что это паттерн хранитель (memento): там класс с методами GetState/SetState называется Memento, а приведенный пример кода — Ordinator. S>Ага. Только я предпочитаю чтобы из кода было видно для чего код был написан, а не сколько книжек асилил автор
Так общепринятое название, которое дают паттерны, вроде бы для того и служит: быть понятным как можно большему числу человек. Конкретно название Memento в таком виде, как обсуждается, есть в промышленном коде, к примеру, того же Eclipse RCP. Несколько лет назад, когда я пользовался этим, не знал, что это описанный паттер. Не гнушаются повсеместно вносить в название слова Observer, Visitor, Adapter/Wrapper и т.п. — вроде бы одна только польза.