ivanov77
Новичок
Приветствую
Для примера возьмем следующий типовой код для Yii2:
Вот этими поведениями расширяется функционал класса, как сказано в доках согласно шаблону "Примесь"(mixins).
Вроде все нормально, класс делегирует всякие доп. обязанности другим классам.
Но появляются следующие вопросы:
1) Как на UML отображать эти отношения? Как зависимость от того каждого конкретного класса? Или как композицию объектов поведения?
2) Вот тот набор поведений, определенный внутри behaviors() - это место как раз подверженное большим изменениям, и есть же принцип ООП - "Инкапсулировать то что меняется" ,но тут оно жестко хардкодиться в этом же классе
3) Что с методом Open Closed, нарушен же? Должны мол быть закрыты для модификации, но тут видно что для изменения дополнит. поведения класса ArticleSettings надо менять именно его код , метод behaviors().
4) Если в 3) ответ положительный, то что если в системе убрать жесткую зависимость от ArticleSettings, так что вместо нее всегда можно подставить подкласс, а в подклассе уже переопределять behaviors(), таким образом можно поправить ситуацию?
5) Если в 4) ответ положительный то уже другой звоночек начинает звенеть - Liskov substitution principle - про то насколько вроде тот же класс но с другим набором поведений, подставляемый для своего суперкласса. Ведь технически мы в ArticleSettings могли вызывать методы из его поведений.
Помогите разобраться в ситуации.
Для примера возьмем следующий типовой код для Yii2:
PHP:
class ArticleSettings extends \yii\base\Model
{
/**
* @var boolean We set it for fields behaviors
*/
public $isNewRecord = false;
/**
* @inheritdoc
*/
public function behaviors()
{
return [
'pathautotemplate' => [
'class' => 'somenamespace1\PathAutoContentTypeSettingsBehavior',
'tokengroup' => 'forpathauto'
],
'whichmenus' => [
'class' => 'somenamespace2\menu\behaviors\WhichMenuBehavior',
],
'comments' => [
'class' => 'somenamespace3\comments\behaviors\CommentContentTypeSettingsBehavior',
],
'sitemaps' => [
'class' => 'somenamespace4\behaviors\sitemap\SitemapContentTypeSettingsBehavior',
],
];
}
// ...
}Вроде все нормально, класс делегирует всякие доп. обязанности другим классам.
Но появляются следующие вопросы:
1) Как на UML отображать эти отношения? Как зависимость от того каждого конкретного класса? Или как композицию объектов поведения?
2) Вот тот набор поведений, определенный внутри behaviors() - это место как раз подверженное большим изменениям, и есть же принцип ООП - "Инкапсулировать то что меняется" ,но тут оно жестко хардкодиться в этом же классе
3) Что с методом Open Closed, нарушен же? Должны мол быть закрыты для модификации, но тут видно что для изменения дополнит. поведения класса ArticleSettings надо менять именно его код , метод behaviors().
4) Если в 3) ответ положительный, то что если в системе убрать жесткую зависимость от ArticleSettings, так что вместо нее всегда можно подставить подкласс, а в подклассе уже переопределять behaviors(), таким образом можно поправить ситуацию?
5) Если в 4) ответ положительный то уже другой звоночек начинает звенеть - Liskov substitution principle - про то насколько вроде тот же класс но с другим набором поведений, подставляемый для своего суперкласса. Ведь технически мы в ArticleSettings могли вызывать методы из его поведений.
Помогите разобраться в ситуации.
