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

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

0

Сообщение от titan4ik Поэтому стал переписывать в рамках подхода ООП. Это заняло гораздо больше времени и никак не закончу).

Хех, селяви, никто не обещал что будет просто

Сообщение от titan4ik Может есть какой-то не оч объемный (страниц 100 - 200) "тот самый" фолиант, или статья, или блог, или ещё что, который мне тут может помочь?

Цены бы не было такой книжке, если бы она существовала. Но серебряной пули нет. Можно конечно посоветовать стандартные книжки типа "Роберт Мартин - Чистая архитектура". Но честно говоря, сомневаюсь что это существенно вас продвинет в вашей конкретной задаче. Потому что тут решает опыт, а не паттерны. Зато вы можете впасть в ООП головного мозга, что может сильно мешать. Мартин кстати пишет про это на первых страницах, но кто ж их читает
Также можно посоветовать на первых парах ориентироваться не на паттерны, а на принципы программирования (KISS, SOLID, DRY, YAGNI) - это так сказать основы.

Сообщение от titan4ik В итоге оказалось, что "что-то не так" - очевидно не хватает каких-то системных знаний.

Если есть проблемы в архитектуре конкретной задачи - ну так спрашивайте на форуме, тут любят такие топики, помогут

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

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

Сообщение от titan4ik Постоянно что-то переделываю.

На самом деле это нормально. Нет идеального кода, который нельзя былобы улучшить. Но тут нужно уметь остановиться на "хорошем" или "приемлемом" варианте, но не пытаться сделать "идеальный", иначе вы никогда не сдвинитесь с места, как стрела Зенона.

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

3

Сообщение от Storm23 Зато вы можете впасть в ООП головного мозга, что может сильно мешать.

Я уже заметил у себя этот симптом - например, поймал себя на неуемном желании "всё оборачивать в обёртки объектов". Тут же вся суть в "золотой середине".
Например, вместо обычного ступенчатого массива делаешь объект, который содержит массив объектов (каждый из который содержит поле - массив). До сих пор не пойму правильно это или нет в моем конкретном случае)

Сообщение от Storm23 Потому что тут решает опыт, а не паттерны.

Это обнадеживает. Но и... опыт требует практических действий - труда) Но больше - обнадеживает. Если сам уже понял, что что-то не так. Это уже хорошо) Это уже опыт.

Сообщение от Storm23 можно посоветовать на первых парах ориентироваться не на паттерны, а на принципы программирования (KISS, SOLID, DRY, YAGNI) - это так сказать основы.

Спасибо! Это важное замечание.

0

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

Как раз наоборот: сверху вниз.

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

ООП, по моему, не о "кирпичиках", а о том, как все систематизировать, причем даже то, что систематизировать невозможно (но оно пытается)). Программа это просто набор задач, которые выполняются над неким набором данных - информацией, и все. Тут вопрос стоит просто: как систематизировать набор задач с набором данных, чтобы не потеряться в этом темном лесу, и дело тут вовсе не в ООП. ООП наоборот может создать такой темный лес, что в трех соснах потеряешься. А стоит ли овчинка выделки для небольших проектов?
Можно просто однотипные операции сложить в один файл, данные в другой файл, все это задокументировать что где лежит, чтобы самому не забыть.

0

Сообщение от Storm23 Можно конечно посоветовать стандартные книжки типа "Роберт Мартин - Чистая архитектура".

Видимо, пора прочитать параллельно с (набором опыта)

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

Сообщение от Storm23 принципы программирования (KISS, SOLID, DRY, YAGNI) - это так сказать основы.

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

Добавлено через 13 минут
Немного ссылок по теме:
Что такое SOLID, KISS, DRY и YAGNI? Видео.

1

Сообщение от titan4ik Это такие как бы очевидные вещи

А оно всегда так - по отдельности все понятно. Но как дело доходит до реальной предметной области - то все куда-то девается, стройные модели рушатся, абстракции текут

А вообще, я бы вам предложил обсуждать конкретные проблемы вашей задачи. Обсуждения ООП "в целом" - это не эффективно, будет сплошная вода и разговоры "за жисть"...
Все познается на практике.

0

Storm23,
как "Роберт Мартин - Чистая архитектура" просмотрю, так и начну спрашивать конкретно.
А пока буду набираться... опыта на собственных шишках)

0

попробую кинуть свои пять копеек...

Представьте - у вас есть 100 книг. Сможете запомнить? Есть сомнение.
Теперь отсортируем их по 10 темам... Десять тем по десять книг - уже проще...

ООП сродни такой сортировке.

Добавлено через 14 минут
Да, и еще - строя иерархию можно тоже закопаться.
Поэтому я для себя лично выработал "правило трех"(с) - иерархий больше трех уровней создавать нельзя.
Или почти нельзя. (бывают редкие исключения)

0

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

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

0

Сообщение от Shamil1 Заразная штука, но есть противоядие - использовать паттерн только если есть понимание, какую практическую выгоду приносит его использование в данном конкретном случае.

Пофилософствуем чуток некомпетентно и оффтопно.
О простоте и не простоте использования и неиспользования паттернов.
Сам я никогда никаких паттернов не применял (или не знал, что применял) Ага.
Первый вариант - использовать паттерн. Использовать паттерн не так просто. По крайней мере, для этого необходимо его знать. Но при использовании известного паттерна можно получить известный результат. Что позитивно (хоть и скучновато).
Второй вариант - не использовать паттерн. Но "не использовать паттерн" - это может означать проявление двух диаметрально противоположных ситуаций:
1. Чел не знает паттерна или не понимает, что его можно применить в данном случае - оч низкая квалификация (как у ТС).
2. Чел настолько хорошо знает весь необходимый спектр паттернов, что применяет их "как дышит" - даже не особенно задумываясь над тем что это за паттерн. На таком уровне квалификации, наверное, применяются уже не канонические паттерны, а именно такая их форма и смесь, которая наиболее адекватна ситуации. Но это уже не вполне "применение паттернов". Это оч высокая квалификация. Можно сказать "надпаттерная", это уже другой, оч высокий уровень - то есть, "чел умеет это делать" - можно сказать так, что он уже стал программистом, мастером своего дела. Всё что до этого - подмастерье.
Паттерны условно можно сравнить с некими стандартами, шаблонами, приемами работы. Например, в борьбе тоже есть "приемы", которым долго и упорно обучают новичков. Сначала учат по складам - делай раз, делай два, делай три. Потом учат готовить прием. Потом учат тактике применения. Но самое главное - практика. Когда чел сам начинает пробовать его применять в борьбе. Помнится, в стародавние старорежимные времена, когда я ещё ходил с красным пионэрским галстуком и учился в совковой школе, у меня был приятель старше по возрасту и он занимался классической борьбой. Я часто задавал ему такой вопрос - скажи, а сколько приемов ты уже знаешь? И в зависимости от ответа выстраивал ему свой некомпетентный рейтинг. Только много позже, когда я и сам довольно долго позанимался борьбой, я понял, что я задавал ему глупый вопрос. Знание некоего числа приемов - это просто ликбез, просто минимальный уровень твоей "школы". Потом в ходе "практической деятельности", это все конвертируется и преломляется. И опытный в борьбе чел он уже делает не "приемы", а делает то, что нужно, чтобы достичь цели. То, что оптимально в данной ситуации. Действуя "на автомате" и совершая выбор в пространстве оптимальных возможных действий (упрощенно - в этом n-мерном пространстве число измеренний определяется набором усвоенных им динамических стереотипов). Но это долгий путь.
Вывод - паттерны, приемы - это некие канонические измерения пространства возможного. В этом пространстве нужно освоиться и научиться жить. То есть, правильно применять паттерны можно только при знании достаточного спектра этих паттернов и наличии достаточного опыта их применения. А это достаточно высокая квалификация. Банальный вывод)
То есть, нужно понимать, что ТС, задавший тут такой вопрос, не может воспользоваться таким советом:

Сообщение от Shamil1 использовать паттерн только если есть понимание, какую практическую выгоду приносит его использование в данном конкретном случае.

Потому что для понимания того "какую практическую выгоду приносит его использование в данном конкретном случае" нужно обладать таким уровнем квалификации, при котором данный вопрос уже не задают.
P.S. Начал читать Мартина, умный чувак.

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

Сообщение от Shamil1 ООП - это прежде всего иерархии.

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

Добавлено через 55 минут
Роберт Мартин о парадигмах программирования:

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

Как следует из текста, это:
- Структурное программирование
- Объектно-ориентированное программирование
- Функциональное программирование
Какая хорошая книжка. Всё чётко, ясно, определенно.

Добавлено через 1 час 10 минут
Хммм... но не всё понятно написано. Ок.
Роберт Мартин о том, в чем собственно специфика ООП:

Факт поддержки языками ОО надежного и удобного механизма полиморфизма означает, что любую зависимость исходного кода, где бы она ни находилась, можно инвертировать. ... При таком подходе архитекторы, работающие в системах, которые написаны на объектно-ориентированных языках, получают абсолютный контроль над направлением всех зависимостей в исходном коде. Они не ограничены только направлением потока управления. Неважно, какой модуль вызывает и какой модуль вызывается, архитектор может определить зависимость в исходном коде в любом направлении. Какая возможность! И эту возможность открывает ОО. Собственно, это все, что дает ОО, — по крайней мере с точки зрения архитектора.

Добавлено через 6 минут
и далее:

Заключение Что такое ОО? Существует много взглядов и ответов на этот вопрос. Однако для программного архитектора ответ очевиден: ОО дает, посредством поддержки полиморфизма, абсолютный контроль над всеми зависимостями в исходном коде. Это позволяет архитектору создать архитектуру со сменными модулями (плагинами), в которой модули верхнего уровня не зависят от модулей нижнего уровня. Низкоуровневые детали не выходят за рамки модулей плагинов, которые можно развертывать и разрабатывать независимо от модулей верхнего уровня.

0

Сообщение от titan4ik То есть, нужно понимать, что ТС, задавший тут такой вопрос, не может воспользоваться таким советом:

Смысл совета в том, чтобы различать правильное и неправильное использование паттернов.

Неправильно:
1. Прочитал про паттерн
2. Нашёл в проекте, где его можно использовать
3. Вставил

Правильно:
1. Столкнулся с архитектурной проблемой
2. Сформулировал проблему
3. Выяснил, что решением проблемы может быть паттерн
4. Прочитал про паттерн
5. Вставил

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

Сообщение от titan4ik "Какая возможность! И эту возможность открывает ОО."

Это общая проблема всех книг про ООП. Описывая возможности, которые открывает ОО, авторы делают вид, что только ОО открывает такие возможности. Возможно, они и сами в это верят.

0

Сообщение от Shamil1 Правильно: 1. Столкнулся с архитектурной проблемой...

На мой взгляд, думать нужно до того, как столкнулся с проблемой. В этом же смысл вообще архитектуры ПО.
Думать об архитектуре (и соотв выборе паттерна) стоит на этапе формирования понимания задачи - на этапе разработки ТЗ (явной - написание или неявной - осмысление).

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

Сообщение от Shamil1 Это общая проблема всех книг про ООП.

Вы бы глянули сначала весь текст вокруг этой цитаты. Роберт Мартин весьма основательно знаком с темой)

Добавлено через 1 минуту
"Чистая архитектура" стр 65

0

Сообщение от titan4ik На мой взгляд, думать нужно до того, как столкнулся с проблемой. В этом же смысл вообще архитектуры ПО.

Бесполезно. Если опыта мало, то придумаешь несуществующие проблемы, а реальные проблемы упустишь из вида.

0

Зачем придумывать проблемы? Проблемы не придумываются, а проявляются, выявляются. Нужно решать задачи, а не придумывать проблемы. А об оптимальном способе решения задачи, в том числе, об архитектуре, нужно сразу думать.

0

Сообщение от titan4ik Зачем придумывать проблемы? Проблемы не придумываются, а проявляются, выявляются. Нужно решать задачи, а не придумывать проблемы. А об оптимальном способе решения задачи, в том числе, об архитектуре, нужно сразу думать.

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

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

Сообщение от titan4ik "Чистая архитектура" стр 65

У меня нет этой книги.

0

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

Всё может быть. И опытный может ошибиться. Вывод-то какой?
Мой вывод такой - нужно приобретать знания (книжки + опыт). А опыт это что такое? Это разработал архитектуру (идею хотя бы) и потом проверил идею. Увидел проблемы, решил проблемы, понял в чем ошибся на этапе архитектуры, приобрел опыт. Это же всё тривиальные вещи.
А ваш вывод - нечего заморачиваться с архитектурой, если опыта нет. Делай как бог на душу положит, а потом, когда возникнет проблема, думай, как ее решить. Так не будет опыта разработки архитектуры.
По факту, человек с любым, даже минимальным опытом занимается планированием архитектуры. Может он и не знает, что это так называется.

0

ООП - для больших компаний придуман, чтобы разделять ответственность между группами программистов. Вам то зачем это. Архитектура это совсем другая область чем ООП. Хорошую архитектуру можно создать и в процедурном программировании. Доказано тем, что в таком стиле создано огромное количество хорошо работающего софта. Посмотрите например код редактора AkelPad. Нет там ООП.

0

Сообщение от CoderHuligan Хорошую архитектуру можно создать и в процедурном программировании. Доказано тем, что в таком стиле создано огромное количество хорошо работающего софта. Посмотрите например код редактора AkelPad. Нет там ООП.

То есть, свалить всю логику в один класс и совершенно не заморачиваться с инкапсуляцией и т.п. И будет нам щастье, если проект маленький? Я так уже делал))) Это была программа инженерного расчета на несколько тысяч строк. Ну, не совсем так, но почти так. Классов всё-таки там было поболе, чем 1)
Вы можете дать ссылку на книженцию или что-то ещё, где растолковывается, как, например, на c# нужно писать хороший код в таком стиле процедурного программирования?

0

Сообщение от titan4ik Вывод-то какой?

Не пытаться предвидеть проблемы, а решать их по мере обнаружения. Начал писать. Увидел проблему в своём коде - решил. Продолжил писать.

Сообщение от titan4ik А опыт это что такое?

Лучший опыт - разбираться в чужих хороших проектах. Разрабатывать свои - тоже опыт, но на начальном этапе менее полезный (пока не в состоянии не то что решить, а даже заметить проблемы в своём коде).

0

Гудлиф П. - 97 этюдов для программистов. Опыт ведущих экспертов - 2012

Книга, в которой нет ни строчки кода, но которая "ум в порядок приводит".

Позволю процитировать один из этюдов - в данной теме он мне кажется уместным.


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

Рассел Уиндер

Психология программирования: давно уже известно, что профессионализм программиста непосредственно зависит от количества различных парадигм программирования, которыми он владеет – не просто что-то слышал и знает о них, но умеет реально использовать их в работе. Каждый программист начинает с какого- то одного языка. Этот язык оказывает преобладающее влияние на то, как программист видит программное обеспечение. Но каким бы долгим ни был опыт работы программиста с этим языком, если он работает только с ним одним, то и будет знать только этот язык. Мышление программиста, знающего лишь один язык, ограничено возможностями этого языка. Программист, изучающий второй язык, встретится с трудностями, особенно если вычислительная модель второго языка отличается от первого. C, Pascal, Fortran – все они основаны а одной вычислительной модели. Переход с Fortran на C вызывает некоторые трудности, но их не так много. Переход с C или Fortran на C++ или Ada сопровождается фундаментальными трудностями с пониманием поведения программ. Переход с C++ на Haskell означает существенные изменения, а потому существенные трудности. Переход с языка C на Prolog станет весьма существенным испытанием. Можно перечислить некоторые парадигмы вычислений: процедурная, объектно-ориентированная, функциональная, логическая, парадигма потоков данных и т. д. Переход между этими парадигмами создает наибольшие трудности. Чем полезны такие трудности? Здесь играют роль наши представления о реализациях алгоритмов, а также идиомах и шаблонах этих реализаций. В частности, взаимное обогащение идеями лежит в основе достижения мастерства. Идиомы решения задач, применимые в одном языке, могут оказаться недоступны в другом.
Пытаясь перенести идиомы из одного языка в другой, мы начинаем лучше понимать оба эти языка и задачу, которую решаем. Взаимное обогащение при использовании разных языков программирования дает мощнейшие эффекты. Пожалуй, наиболее
очевидным из них является все растущее применение декларативных режимов описанияв системах, реализованных посредством императивных языков. Любой знаток функционального программирования может легко применить декларативный подход, даже при работе с таким языком, как C. Применение декларативных методов обычно приводит к созданию более коротких и понятных программ. Скажем, C++ определенно выступает за такой подход, обеспечивая всестороннюю поддержку
обобщенного (generic) программирования, в котором декларативный режим описания является почти обязательным. Как следствие всего сказанного выше каждому программисту надлежит уметь хорошо программировать хотя
бы в двух разных парадигмах, а в идеале хотя бы в перечисленных пяти. Программист всегда должен стремиться к освоению новых языков, предпочтительно с незнакомыми ему парадигмами. Даже если в своей повседневной работе он неизменно
использует один и тот же язык программирования, нельзя недооценивать то более искусное применение этого языка, которое станет возможным благодаря идеям из других парадигм. Работодателям следует это учесть и закладывать в бюджет обучение
сотрудников языкам, которые в данное время на проектах не используются, как средство научить работников более искусно применять те языки, которые реально используются. Неделя начального курса – это хорошо, но не достаточно для изучения нового языка. Чтобы приобрести рабочие навыки применения языка, обычно нужно потратить несколько месяцев хотя бы факультативно. Важно практическое освоение идиом, а не просто изучение синтаксиса и вычислительной модели.

Добавлено через 18 минут
ps: Упомянутый Мартин там оказывается в соавторах, полный состав: Пит Гудлиф, Роберт Мартин, Диомидис Спинеллис, Кевлин Хенни и др.

0