juan_gandhi | amazingly good reading: Java Shop Politics

До сих пор со стыдом вспоминаю, как молодым стажером, проникшемся идеями ООП, начал писать декодер для потока данных на С++. Первый созданный класс в программе был Byte, в котором был массив из 8 элементов типа Bit.
Так начинается ООП головного мозга.

Да фигня, как упражнение вполне сгодится.

А что было бы в этом плохого, если бы (ну пусть каким-то чудом) производительность внутри была бы такая же как и у «&» и всяких «>>»?

Вот именно. Надо различать концептуальную модель и физическую модель.

Более того, всякие штуки типа formatNetworkOrder, ByteFactory::create7BitByte и прочая были бы гораздо прозрачнее для людей нежели заборы из амперсандов.

Ну для этого классы писать не обязательно. Достаточно вспомогательных функций.

Если там состояние держать не надо, то конечно. Но в этом случае класс будет тоже статическим и будет выпонять скорее роль namespace.

А вот если там будут состояния, то уж лучше в обьекты это упаковывать...

Не факт, что нам нужно это состояние. Может, достаточно immutable структур данных и функций для работы с ними. И namespace еще.

Edited 2014-08-13 11:06 (UTC)

Ну я как бы для maintainability все это и задумывал. Беда была в том, что писалось это для real-time data processing on embedded devices.

По-моему, ошибка состоит в наивном "моделировании" предметной области с помощью об'ектов. Типа, раз я имею дело с байтами, битами, портами, аппаратными интерфейсами и проч., то надо создать соответствующие классы.

А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.

Edited 2014-08-13 11:07 (UTC)

Да все нормально с ГоФ-ом. Только не надо его применять вместо мозгов - и все отлично будет. Это ж стандартная ситуация: Кумар наваял фигню, не включая голову, сказал, что это "бридж паттерн" - и все, виноват не Кумар, а ГоФ. Мол, бридж паттерн у него неправильный. Фальшивит, картавит и вообще играть не умеет.

С ГоФ'ом все нормально. Для простого незамысловатого C++ программиста (типа меня) это было самое то. Только уже почти 20 лет с тех прошло. А на "вечные ценности" ГоФ-паттерны все-таки не тянут.

Просто с тех пор появились (в смысле, вошли в мейнстрим) другие подходы, другие языки и другие абстракции.

Edited 2014-08-13 15:57 (UTC)

именно.

Ошибка преподавания и использования ООП в моделировании предметной области.

А надо бы "разобрать" предметную область на составляющие, и моделировать их.
а описание в коде предметной области - собирать их этих составляющих.

на примере обычного языка:

ООП сейчас часто применяется как:
видим в предметной области:
"... в наивном ..."
аха, вот он класс Naively
встречаем
"... в наивных ..."
аха, наследуемся
встречаем
"... это наивно ..."
аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.

встречаем
"... глупо ..."
новый класс

итого, получаем на вид описание предметной области, а на деле ее "хардкодинг"
и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.

а надо бы
1. либо проектировать от правил - части речи, падежи
2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов

то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области.
именно в этом суть совета строить не наследованием - B is A, а композицией: В has A

для примера - холивар Rich vs Anemic

3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.

Ну в общем да.

Дело в принципе не в ООП, а в том, когда и как оно применяется.

До сих пор немного в недоумении от симпозиума, на котором лектор сказал, что если в коде есть switch statement, то это плохой дизайн и должно было быть ООП вместо него.

Кстати, я как бы поддерживаю - если диспатч делается по типам, то все надежнее.

(no subject)

pechkinoff.livejournal.com - 2014-08-14 07:14 (UTC) - Expand

(no subject)

juan-gandhi.livejournal.com - 2014-08-14 14:19 (UTC) - Expand

Как попробовал в додельфевском борланд-паскале 5.5 так и в ём родимом, OOP. А нынешняя работа с богатым кроссплотформенным UI-ем "толстый клиент" и network и много чего асинк без OOP вовсе не представляется. Ах да, ещё и C++. Ибо у нас нет Objective C. Жабы не катят, специфика, это серьёзно.

и network и много чего асинк без OOP вовсе не представляется

А Вы кроме ООП еще что-нибудь знаете ?

Мне резюме выкладывать сюда, что-ли? Ассемблер чуть ли не в детстве пробовал. SQL забыл за ненадобностью. Не важно, а критики OOP в массе back-end программируют и в вебе один жаба-скрипт клиентский рассматривают, которому все готовые объекты на C++ уже сделали. И не спрашивайте, откуда мне это известно. :)

Спасибо, понятно.

По-моему, Вы говорите, что без ООП асинхронная работа с нетворком и гуем "не представляется", потому что ничего другого кроме ООП не знаете.

Edited 2014-08-13 16:36 (UTC)

В C++ 11 и некоторых фреймворках вроде Parallel Patterns async решается вполне в "функциональном" виде. И там есть continuations и вполне всё выглядит как отсюда-действие-сюда. Смотря на это из C++ отчётливо представялется что FP есть пара-тройка "паттернов" (чтобы они бесились), которые отлично ложатся на OOP.

(no subject)

mikkim08.livejournal.com - 2014-08-13 16:41 (UTC) - Expand

(no subject)

fatoff.livejournal.com - 2014-08-13 17:35 (UTC) - Expand

(no subject)

mikkim08.livejournal.com - 2014-08-13 18:37 (UTC) - Expand

(no subject)

juan-gandhi.livejournal.com - 2014-08-13 19:48 (UTC) - Expand

Это не ООП, это ООД - Объектно-Ориентированный Дизайн. Злой анти-двойник ООП.

А в чем разница ? И почему ООД злее ООП ?

Edited 2014-08-13 16:39 (UTC)

Ну как, Алан Кей же в семь раз мудрей Гради Буча.

ООП - это способ побеждать сложность, деля ее на части, и упаковывая в куски с относительно простым внешним интерфейсом (классы). А ООД - это способ дизайна, в котором говорится "ну, раз мы умеем побеждать сложность, то давайте не стесняться в дизайне и фигачить объекты на каждый чих, не думая". И в результате создает сложность гораздо быстрее, чем ООП успевает ее разгребать. Собственно, поэтому учения всяких Гради Бучей - на самом деле образец того, как не надо делать.

опять детские ушибы напоказ всему честному люду, когда ж это кончится...