Более того, всякие штуки типа formatNetworkOrder, ByteFactory::create7BitByte и прочая были бы гораздо прозрачнее для людей нежели заборы из амперсандов.
По-моему, ошибка состоит в наивном "моделировании" предметной области с помощью об'ектов. Типа, раз я имею дело с байтами, битами, портами, аппаратными интерфейсами и проч., то надо создать соответствующие классы.
А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.
Да все нормально с ГоФ-ом. Только не надо его применять вместо мозгов - и все отлично будет. Это ж стандартная ситуация: Кумар наваял фигню, не включая голову, сказал, что это "бридж паттерн" - и все, виноват не Кумар, а ГоФ. Мол, бридж паттерн у него неправильный. Фальшивит, картавит и вообще играть не умеет.
С ГоФ'ом все нормально. Для простого незамысловатого C++ программиста (типа меня) это было самое то. Только уже почти 20 лет с тех прошло. А на "вечные ценности" ГоФ-паттерны все-таки не тянут.
Просто с тех пор появились (в смысле, вошли в мейнстрим) другие подходы, другие языки и другие абстракции.
Ошибка преподавания и использования ООП в моделировании предметной области.
А надо бы "разобрать" предметную область на составляющие, и моделировать их. а описание в коде предметной области - собирать их этих составляющих.
на примере обычного языка:
ООП сейчас часто применяется как: видим в предметной области: "... в наивном ..." аха, вот он класс Naively встречаем "... в наивных ..." аха, наследуемся встречаем "... это наивно ..." аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.
встречаем "... глупо ..." новый класс
итого, получаем на вид описание предметной области, а на деле ее "хардкодинг" и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.
а надо бы 1. либо проектировать от правил - части речи, падежи 2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов
то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области. именно в этом суть совета строить не наследованием - B is A, а композицией: В has A
для примера - холивар Rich vs Anemic
3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.
Дело в принципе не в ООП, а в том, когда и как оно применяется.
До сих пор немного в недоумении от симпозиума, на котором лектор сказал, что если в коде есть switch statement, то это плохой дизайн и должно было быть ООП вместо него.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2014-08-13 06:02 am (UTC)no subject
Date: 2014-08-13 06:03 am (UTC)no subject
Date: 2014-08-13 06:11 am (UTC)no subject
Date: 2014-08-13 06:14 am (UTC)no subject
Date: 2014-08-13 06:21 am (UTC)А вот если там будут состояния, то уж лучше в обьекты это упаковывать...
no subject
Date: 2014-08-13 06:32 am (UTC)no subject
Date: 2014-08-13 06:45 am (UTC)no subject
Date: 2014-08-13 09:31 am (UTC)А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.
no subject
Date: 2014-08-13 11:22 am (UTC)no subject
Date: 2014-08-13 03:53 pm (UTC)Просто с тех пор появились (в смысле, вошли в мейнстрим) другие подходы, другие языки и другие абстракции.
no subject
Date: 2014-08-13 11:26 am (UTC)Ошибка преподавания и использования ООП в моделировании предметной области.
А надо бы "разобрать" предметную область на составляющие, и моделировать их.
а описание в коде предметной области - собирать их этих составляющих.
на примере обычного языка:
ООП сейчас часто применяется как:
видим в предметной области:
"... в наивном ..."
аха, вот он класс Naively
встречаем
"... в наивных ..."
аха, наследуемся
встречаем
"... это наивно ..."
аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.
встречаем
"... глупо ..."
новый класс
итого, получаем на вид описание предметной области, а на деле ее "хардкодинг"
и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.
а надо бы
1. либо проектировать от правил - части речи, падежи
2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов
то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области.
именно в этом суть совета строить не наследованием - B is A, а композицией: В has A
для примера - холивар Rich vs Anemic
3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.
no subject
Date: 2014-08-14 03:47 am (UTC)Дело в принципе не в ООП, а в том, когда и как оно применяется.
До сих пор немного в недоумении от симпозиума, на котором лектор сказал, что если в коде есть switch statement, то это плохой дизайн и должно было быть ООП вместо него.
no subject
Date: 2014-08-14 04:29 am (UTC)no subject
Date: 2014-08-14 07:14 am (UTC)no subject
Date: 2014-08-14 02:19 pm (UTC)