ООП - парадигмы, паттерны, подходы - кратко и доходчиво

Я не проф программист и никогда им не буду (старый уже). Потихоньку что-то читал и делал на c# WPF. Получалось, работало, но это были относительно простые штуковины и собственно ОПП там особо не использовалось. Но ту взялся сделать (для себя) более сложную штуковину и увидел, что не сделал ещё и малой части, а уже приходится неоднократно переписывать почти всё заново. Чё-то не очень получается делать ладные "кирпичики", из которых будут строиться блоки программы, а из блоков постепенно усложняться большое здание программы. Постоянно что-то "подпиливаю" в кирпичиках и даже их заменяю. Если так и дальше пойдет, то я эту штуку никогда не сделаю. Оказалось, что это очень не просто правильно сделать модель предметной области, правильно определиться со способами реализациями идей, правильно разбить программу на какие-то правильно взаимодействующие части. К тому же, c# имеет богатый функционал средств. Одно и то же можно сделать по разному. Постоянно встает проблема выбора - и так можно и эдак... Код поначалу всё терпит)
В итоге оказалось, что "что-то не так" - очевидно не хватает каких-то системных знаний.
Сама задача достаточно стандартная - анализ исторических данных биржевых курсов акций, выработка и реализация торговых стратегий и т.д. Это интересно, но чувствую, что что-то идёт не так)
Забавно, что в рамках процедурного программирования достаточно быстро "слепил" один небольшой кусочек программы и частично оттестировал микроидею. Усложнять далее в рамках процедурного подхода было уже не рационально. Поэтому стал переписывать в рамках подхода ООП. Это заняло гораздо больше времени и никак не закончу). Постоянно что-то переделываю. Честно говоря, не ожидал, что возникнут такие принципиальные трудности. Одного здравого смысла и соображалки явно не достаточно. И шо же делать?)
Изучить все парадигмы, подходы, паттерны программирования, чтобы потом легко выбирать нужные? Это конечно правильный, но очень долгий путь.
Что подскажут профессионалы? Может есть какой-то не оч объемный (страниц 100 - 200) "тот самый" фолиант, или статья, или блог, или ещё что, который мне тут может помочь? Как-то подтолкнёт в нужном направлении. А далее уже методом проб и ошибок - путём набора опыта.

0

Сообщение от CoderHuligan Во всех книжках по ООП пишут, что ООП есть отражение реальности.

В учебниках для начинающих пишут так, как проще понять, а не так, как на самом деле.

Я так сходу не припомню ни одного паттерна (не путать с антипаттернами), где бы класс представлял из себя "совокупность данных и способов работы с ними". Обычно так бывает только для элементов интерфейса. В остальных случаях класс содержит только свойства (и, возможно, методы для "вычисляемых полей" и т.п.) или только методы (и, возможно, свойства только для чтения для хранения настроек - строка соединения, контекст и т.п.).

0

Сообщение от Shamil1 Я так сходу не припомню ни одного паттерна (не путать с антипаттернами), где бы класс представлял из себя "совокупность данных и способов работы с ними". Обычно так бывает только для элементов интерфейса. В остальных случаях класс содержит только свойства (и, возможно, методы для "вычисляемых полей" и т.п.) или только методы (и, возможно, свойства только для чтения для хранения настроек - строка соединения, контекст и т.п.).

Это вы про разделение на анемичные модели (POCO, DTO) и stateless-сервисы. Мне приходилось сталкиваться с rich моделями, когда в классе и данные и код для манипуляции ими. Это хороший подход, код получается довольно выразительным. Но не везде это может быть нужно. Видимо ваша практика не испытывала нужды в таким моделях.

0

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

Да, это два типа моделей - rich и anemic. И тут все неоднозначно. Например господин Фаулер считает anemic модели лютым антипаттерном и выступает категорически против таких моделей. Аргументируется это тем, что объект по определению - это совокупность данных и методов работы с ним, и для которого важна инкапсуляция. Исходя из такого подхода, действительно все методы работы с объектом должны быть внутри самого объекта - то есть rich модель. С другой стороны, мне кажется такой подход нарушает SRP, поскольку у объекта может быть куча разнообразных функций и соответственно методов для них. Вероятно Фаулер это как-то объясняет, но мне лень искать
Лично я на практике стараюсь не впадать в крайности, и делаю где-то посередине между rich и anemic.

Сообщение от Usaga Это вы про разделение на анемичные модели (POCO, DTO)

Ну вообще-то DTO имеют вполне определенное назначение: передача данных. И они не являются объектами доменной модели. Доменная же модель вполне может быть rich, даже если вне нее используются DTO. Тут как раз и появляется смысл DTO - вы же не будете на клиент отправлять rich объект.
А POCO - это вроде тоже Фаулер придумал, как альтернативу тяжелым rich объектам. Но честно говоря в POCO я не разбираюсь. Это в основном для энтерпрайза, баз данных, ORM и все такое, которыми я не занимаюсь.

0

Сообщение от Storm23 С другой стороны, мне кажется такой подход нарушает SRP, поскольку у объекта может быть куча разнообразных функций и соответственно методов для них.

Нарушает. Кроме того, разные задачи/функции подразумевают разную иерархию. Например, иерархия сериализаторов независима от иерархии документов. То есть, методы рич объекта будут создавать (или использовать готовые) объекты для решения конкретной задачи и дёргать методы этого "решателя". Особого смысла писать такие методы-обёртки нет. Если очень хочется использовать синтаксис "myDoc.Save()", то можно написать методы расширения (или что там предлагает конкретный ЯП).

0

Сообщение от Shamil1 Обфускация нужна, если пишешь программу из трёх строк и хочешь за неё бабла срубить.

Или скрыть хренокод, который стыдно показывать.

Сообщение от Usaga Отцы-основатели не заблуждаются.

Они начали заблуждаться с того самого момента, когда посчитали goto вредным оператором.(профессор Легалов считает что язык без оператора goto не может считаться полноценным ЯП..)
Первая же ошибка привела к последующему валу ошибочных теорий.
Первой ошибочной теорией стала структурная парадигма.
А так как в структурном стиле было очень трудно писать достаточно сложные и умные программы из-за того, что теперь приходилось использовать туеву кучу различных флагов, которые запутывают программу не хуже не правильного использования goto. Достаточно большие программы достигли пределов поддерживаемости. Поэтому задумались о разделении кода. Первые "отцы" пошли путем создания модульных языков - Паскаль, Модула, Оберон. Вторые - пошли путем создания классов (которые в действительности были призваны обеспечить хоть какую-то модульность в объектной парадигме), создавая чисто обьектные языки.
Первые это профессора из академической науки. Вторые = коммерсанты.
Это привело к тому, что код стал очень обьемен и не быстр. если раньше та же программа с той же функциональностью требовала скажем 1 мегабайт, то сейчас 10-100. Налицо кризис и об этом кто только не говорит. Налицо полная разруха, руины, но если деньги продолжают капать приходится делать вид, что все в порядке..

Я лично скорее гребу против течения, и мне по нраву чисто академические теории и разработки.

Добавлено через 15 минут

0

CoderHuligan,
Не могли бы Вы на примере быстрой сортировки показать преимущества автоматного программирования?
(В отдельной теме)

0

Сообщение от Usaga Видимо ваша практика не испытывала нужды в таким моделях.

При написании интерфейса в виде независимых компонентов использование умных объектов довольно удобно.
При написании абстрактных типов данных нет особой разницы между использованием умных и "плоских" объектов.
В большинстве остальных случаев от умных объектов больше вреда, чем пользы.

Сообщение от Usaga Мне приходилось сталкиваться с rich моделями, когда в классе и данные и код для манипуляции ими. Это хороший подход, код получается довольно выразительным.

Можете привести пример?

0

Сообщение от Shamil1 Не могли бы Вы на примере быстрой сортировки показать преимущества автоматного программирования? (В отдельной теме)

Еще раз натянуть кернигана и ритчи "на глобус"? (они приводили традиционный вариант быстрой сортировки в своих работах, а я уже их один раз "натягивал"..).
Позже этим займусь. Сейчас занят обещанным проектом. Когда закончу сообщу.

0

Сообщение от CoderHuligan Первой ошибочной теорией стала структурная парадигма.

Чушь, это самый правильный шаг, и твои любимые "отцы" Паскаль, Модула, Оберон его полностью поддерживают.

Сообщение от CoderHuligan А так как в структурном стиле было очень трудно писать достаточно сложные и умные программы

Наоборот.

Сообщение от CoderHuligan профессор Легалов считает

После таких фраз:

В частности, процедурно-ориентированный стиль содержит императивную и функциональную парадигмы программирования.

Язык программирования CLOS

мнение профессора можно не учитывать. Но раз тебе оно важно, то вот, что он пишет про ненавистное тебе ООП:

Из стилей, представленных в таблице 1, только процедурный и объектно-ориентированный оказались в настоящее время жизнеспособными для разработки больших программных систем. И только ООП послужило основой для разработки всеобъемлющей и сквозной методологии проектирования.

Сообщение от CoderHuligan Позже этим займусь. Сейчас занят обещанным проектом. Когда закончу сообщу.

Т.е. никогда. Понятно. Видимо, в не-структурном стиле слишком просто писать достаточно сложные и умные программы.

0

Сообщение от korvin_ Т.е. никогда. Понятно. Видимо, в не-структурном стиле слишком просто писать достаточно сложные и умные программы.

Причем здесь стиль/не стиль? Сама задача: быстрая сортировка относится к вычислительным алгоритмам, которые используют вычислительные же состояния. А автоматный подход имеет дело с управляющими состояниями. Разница есть? Надеяться, что переделав быструю сортировку в автоматный стиль, пусть даже вместо рекурсии использовав стек, мы сможем её ускорить не стоит потому, что подобные алгоритмы и так оптимизированы донельзя. Поэтому скорость не увеличится. Но может повысится ясность кода, возможность его верифицирования и документирования.
Я не отказываюсь, отнюдь. Просто сейчас задача более сложная решается, а я не хочу отвлекаться.

Сообщение от korvin_ Чушь, это самый правильный шаг

Рефлекторный выпад..
Так и я думал раньше.. Но, к сожалению, структурное программирование упускает такую фундаментальную абстракцию, как состояние, делает его не явным, и не позволяет явно задавать переходы из одного состояния в другое произвольным образом, которые лежат в основе полноты по Тьюрингу. Увы..

Сообщение от korvin_ Наоборот.

Опять рефлексия..
Чем сложнее логика поведения программы, тем больше в ней возможных управляющих состояний. А так как структурный подход в принципе игнорирует "состояние" как абстракцию, то и может реализовывать системы со сложным поведением лишь при помощи многочисленных костыльных конструкций типа флагов. Глупейший подход.
Старые basic-и и то поощряли переходы, и пускай там были числовые метки (состояния, по сути), но программы писались легко и просто. Сложность их понимания была в отсутствии вменяемой системы описания логики поведения кода. Теперь такие средства появились.

0

Сообщение от CoderHuligan Просто сейчас задача более сложная решается, а я не хочу отвлекаться.

Я про неё и писал.

Сообщение от CoderHuligan структурное программирование упускает такую фундаментальную абстракцию, как состояние, делает его не явным

Бред, откуда ты это взял?

Сообщение от CoderHuligan не позволяет явно задавать переходы из одного состояния в другое произвольным образом, которые лежат в основе полноты по Тьюрингу

Ты бы почитал, что такое полнота по Тьюрингу и какие языки являются полными.

Сообщение от CoderHuligan А так как структурный подход в принципе игнорирует "состояние" как абстракцию

Чушь.

Сообщение от CoderHuligan Старые basic-и и то поощряли переходы, и пускай там были числовые метки (состояния, по сути), но программы писались легко и просто.

Нет, не писались.

0

Сообщение от korvin_ Бред, откуда ты это взял?

Состояния идентифицируются по именам. Здесь имен состояний нет, значит состояния не явны, скрыты. Более того: переход здесь осуществляется всегда в одну точку: конец блока, а в автоматах может осуществляться в любую нужную.

0

Сообщение от CoderHuligan Состояния идентифицируются по именам. Здесь имен состояний нет, значит состояния не явны, скрыты.

«написал код без состояний — состояний нет» — логика уровня… CoderHuligan

— состояние

здесь имён состояний нет, значит состояния не явны, скрыты. Более того переход здесь осуществляется всегда в одну точку: начало блока, а в структурированном коде — в любую нужную.

0

Похоже, что мы разные книжки читали, и говорим на разных языках, с разным пониманием смысла языковых конструкций.. И это печалит..

0

Сообщение от CoderHuligan Надеяться, что переделав быструю сортировку в автоматный стиль, пусть даже вместо рекурсии использовав стек, мы сможем её ускорить не стоит потому, что подобные алгоритмы и так оптимизированы донельзя.

Скорость работы меня не интересует. За скорость работы отвечает не язык и не парадигма, а компилятор. Мне интересно, какие преимущества даёт программисту автоматный подход (скорость написания, выразительность, удобство отладки).

Я думаю, что любой средний программист напишет быструю сортировку в структурном стиле за 1 час, включая время на знакомство с алгоритмом, написание кода и отладку. С учётом того, что Вы уже знакомы с алгоритмом (уже кодировали его), у Вас это должно занять 30 минут - меньше, чем написание сообщений в этой теме.

0

Сообщение от Shamil1 у Вас это должно занять 30 минут - меньше, чем написание сообщений в этой теме.

Это при вашем подходе это займет 30 минут. Автоматный подход подразумевает создание вменяемой документации, чтобы через ~30 лет ваш код был понятен другим. Поэтому в 30 минут не уложишься.

0

Сообщение от Shamil1 Мне интересно, какие преимущества даёт программисту автоматный подход (скорость написания, выразительность, удобство отладки).

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

При программной реализации протоколов передачи КА снова оказываются выразительнее и что любопытно - быстрее. (реализовывал как-то протокол I2C программно - написанный мной КА по скорости был близок аппаратному)

А вообще, не бывает идеальных парадигм, каждая удобна в конкретном своем случае. Панацей и граалей не бывает.

ps: пример с quicksort тому пример - автоматное программирование не для этих случаев.

0

CoderHuligan, зачем вы опять киваете на Шалыто? Мы уже выяснили в другой теме, что он нигде не призывает всех перейти на гото лапшу, а приводит подход с метками как один из многих для реализации автоматной парадигмы. Так что возведение гото в абсолют - это исключительно ваша идея, и вам ее и обосновывать. Спрятаться за спину Шалыто не выйдет.

Добавлено через 5 минут

Сообщение от CoderHuligan Это при вашем подходе это займет 30 минут. Автоматный подход подразумевает создание вменяемой документации, чтобы через ~30 лет ваш код был понятен другим. Поэтому в 30 минут не уложишься.

В "нашем" подходе это около 5 минут. А вот что вы собрались документировать больше 30 минут в простейшем алгоритме - загадка. Наверно, первые 15 минут уйдут на написание кода, еще 30 минут - на попытки разобраться в только что написанном, ну и последний час - на описание получившейся лапши.

0

Сообщение от Катафалк Наверно, первые 15 минут уйдут на написание кода, еще 30 минут - на попытки разобраться в только что написанном, ну и последний час - на описание получившейся лапши

И ещё полдня на отлов багов.

0

Сообщение от Shamil1 Можете привести пример?

Да. Самый распространённый (в том числе и в проектах с которыми я работаю) - Value Object. Номер телефона, ZipCode (почтовый индекс), даже возраст. Некая доменная концепция выраженная классом, который содержит единое представление концепции, в не зависимости от того, как она пользователю (или от него) передаётся. Буквально в прошлую пятницу довелось в одной системе сборки статистики вводить класс NibsAge, который может быть создан из чисел (как с ведущим нулём, так и без него) и кодов NN, NB, BB и который реализует средства сравнения, а так же форматированного вывода. Подобных маленьких классов у нас полно. Они безумно удобнее, чем просто примитив и пачка хелперов к нему (string + класс-хелпер для сравнения и прочего).

В виде полноценной модели могу привести агрегат из той же системы сбора статистики. Это большая модель с набором методов для внесения в неё данных. Такие методы сразу реализуют бизнес-правила не дающие перевести эту модель в противоречивое состояние, а так же дополняющие модель комплементарными вещами. К примеру, когда в модель добавляется обвинение по статье "Вандализм", в коллекцию "Пострадавшие стороны" добавляется "Государство". А в "Вещественные доказательства" нельзя добавить "Наркотики", если нет обвинений по нужной статье (получите исключение). Это тоже очень удобно, так как такая модель превращается в чёрный ящик, с которым очень просто работать, о ней вообще ничего не надо знать. Модель или сама будет донастраиваться, или кинет исключение, которое достаточно показать пользователю и пускай он выполняет корректные действия.

Это успешно можно было реализовать анемичной моделью и группой отдельных сервисов, которые выполняют над ней действия и валидацию. Но это уже явные действия, которые ещё надо не забыть выполнить, да ещё и в нужном порядке. Если бы эти сервисы обращались к другим (скажем, к базе), то так и пришлось бы сделать, чтобы не перегружать модель. Но в данном случае все манипуляции шли только с самой моделью и сокрытие этого кода в ней сделало работу с моделью значительно более простой.

Или вот ещё один пример, того, что мне в начале года довелось реализовать. Нужно было определить временной промежуток выгрузки отчётов. Это две даты: от и до. Но даты эти формируются на основе кучки разных факторов, которые можно найти в разных частях системы и которые могут быть противоречивыми. Поэтому был сформирован класс ReportExtractionDateRange, который отправился в пешее сексуальное по этой самой системе, где в него добавляется информация о прошлых выгрузках, типах выгрузок прошлых и текущей запрошенной, квоты пользователя на это дело, прав и прочее и прочее. При этом, моделька проверяет соблюдение бизнес-правил и на полпути может швырнуть исключение о том, что в данной ситуации репорт запросить не можно.

В общем, получаются или маленькие концепции (а-ля НомерТелефона) или модели, которые самостоятельно гарантируют свою непротиворечивость не выставляя наружу кучу бизнес-логики.

Оно может быть звучит переусложнённо. Но я к этому пришёл наевшись вездесущих примитивов для представления каких-нибудь возрастов, цен и почтовых индексов, а так же наевшись чёрно-белого деления на анемичные модели с одной стороны и Statless-сервисы с другой. Некоторые (не все!) вещи в более-менее крупном проекте просто слёзно просят перевести их в rich-модель.

1