До сих пор со стыдом вспоминаю, как молодым стажером, проникшемся идеями ООП, начал писать декодер для потока данных на С++. Первый созданный класс в программе был Byte, в котором был массив из 8 элементов типа Bit. Так начинается ООП головного мозга.
Более того, всякие штуки типа formatNetworkOrder, ByteFactory::create7BitByte и прочая были бы гораздо прозрачнее для людей нежели заборы из амперсандов.
По-моему, ошибка состоит в наивном "моделировании" предметной области с помощью об'ектов. Типа, раз я имею дело с байтами, битами, портами, аппаратными интерфейсами и проч., то надо создать соответствующие классы.
А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.
Да все нормально с ГоФ-ом. Только не надо его применять вместо мозгов - и все отлично будет. Это ж стандартная ситуация: Кумар наваял фигню, не включая голову, сказал, что это "бридж паттерн" - и все, виноват не Кумар, а ГоФ. Мол, бридж паттерн у него неправильный. Фальшивит, картавит и вообще играть не умеет.
С ГоФ'ом все нормально. Для простого незамысловатого C++ программиста (типа меня) это было самое то. Только уже почти 20 лет с тех прошло. А на "вечные ценности" ГоФ-паттерны все-таки не тянут.
Просто с тех пор появились (в смысле, вошли в мейнстрим) другие подходы, другие языки и другие абстракции.
Ошибка преподавания и использования ООП в моделировании предметной области.
А надо бы "разобрать" предметную область на составляющие, и моделировать их. а описание в коде предметной области - собирать их этих составляющих.
на примере обычного языка:
ООП сейчас часто применяется как: видим в предметной области: "... в наивном ..." аха, вот он класс Naively встречаем "... в наивных ..." аха, наследуемся встречаем "... это наивно ..." аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.
встречаем "... глупо ..." новый класс
итого, получаем на вид описание предметной области, а на деле ее "хардкодинг" и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.
а надо бы 1. либо проектировать от правил - части речи, падежи 2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов
то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области. именно в этом суть совета строить не наследованием - B is A, а композицией: В has A
для примера - холивар Rich vs Anemic
3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.
Дело в принципе не в ООП, а в том, когда и как оно применяется.
До сих пор немного в недоумении от симпозиума, на котором лектор сказал, что если в коде есть switch statement, то это плохой дизайн и должно было быть ООП вместо него.
Как попробовал в додельфевском борланд-паскале 5.5 так и в ём родимом, OOP. А нынешняя работа с богатым кроссплотформенным UI-ем "толстый клиент" и network и много чего асинк без OOP вовсе не представляется. Ах да, ещё и C++. Ибо у нас нет Objective C. Жабы не катят, специфика, это серьёзно.
Мне резюме выкладывать сюда, что-ли? Ассемблер чуть ли не в детстве пробовал. SQL забыл за ненадобностью. Не важно, а критики OOP в массе back-end программируют и в вебе один жаба-скрипт клиентский рассматривают, которому все готовые объекты на C++ уже сделали. И не спрашивайте, откуда мне это известно. :)
В C++ 11 и некоторых фреймворках вроде Parallel Patterns async решается вполне в "функциональном" виде. И там есть continuations и вполне всё выглядит как отсюда-действие-сюда. Смотря на это из C++ отчётливо представялется что FP есть пара-тройка "паттернов" (чтобы они бесились), которые отлично ложатся на OOP.
ООП - это способ побеждать сложность, деля ее на части, и упаковывая в куски с относительно простым внешним интерфейсом (классы). А ООД - это способ дизайна, в котором говорится "ну, раз мы умеем побеждать сложность, то давайте не стесняться в дизайне и фигачить объекты на каждый чих, не думая". И в результате создает сложность гораздо быстрее, чем ООП успевает ее разгребать. Собственно, поэтому учения всяких Гради Бучей - на самом деле образец того, как не надо делать.
![[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 04:52 am (UTC)Так начинается ООП головного мозга.
no subject
Date: 2014-08-13 05:00 am (UTC)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)
From:(no subject)
From:no subject
Date: 2014-08-13 03:22 pm (UTC)no subject
Date: 2014-08-13 03:49 pm (UTC)А Вы кроме ООП еще что-нибудь знаете ?
no subject
Date: 2014-08-13 04:13 pm (UTC)no subject
Date: 2014-08-13 04:32 pm (UTC)По-моему, Вы говорите, что без ООП асинхронная работа с нетворком и гуем "не представляется", потому что ничего другого кроме ООП не знаете.
no subject
Date: 2014-08-13 04:39 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-08-13 04:16 pm (UTC)no subject
Date: 2014-08-13 04:39 pm (UTC)no subject
Date: 2014-08-13 06:02 pm (UTC)no subject
Date: 2014-08-13 08:22 pm (UTC)no subject
Date: 2014-08-14 12:13 am (UTC)