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

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

0

Сообщение от titan4ik Хммм... но не всё понятно написано. Ок. Роберт Мартин о том, в чем собственно специфика ООП: Факт поддержки языками ОО надежного и удобного механизма полиморфизма означает, что любую зависимость исходного кода, где бы она ни находилась, можно инвертировать.

Идея инверсии зависимости непонятна?
Вот тут Общий код базового класса месяц назад разбирался такой случай.
Если правильно помню (лень Мартина листать) - ситуация/пример проще, чем у Мартина.
Плюс указано, как данный конкретный приём называется в паттернах проектирования.

0

Кстати, в довесок к паттернам не мешает ознакомиться и с антипаттернами - это тоже очень хороший опыт.

На английском тут: http://wiki.c2.com/?AntiPatternsCatalog

Если кратко, там упомянуты и спагетти и индусский и многое другое...

0

Сообщение от VTsaregorodtsev Вот тут Общий код базового класса месяц назад разбирался такой случай.

Только в том примере сама модель неправильная. Если вдруг (а точнее - когда) появится животное которое не умеет есть, то будет попаболь. Вместо того, что бы пихать метод Eat в базовый класс, нужно сделать интерфейс ICanEat, и наследники Animal будут его реализовывать.

0

Сообщение от titan4ik Роберт Мартин о парадигмах программирования: Парадигма — это способ программирования, не зависящий от конкретного языка. Парадигма определяет, какие структуры использовать и когда их использовать. До настоящего времени было придумано три такие парадигмы. По причинам, которые мы обсудим далее, едва ли стоит ожидать каких-то других, новых парадигм... Как следует из текста, это: - Структурное программирование - Объектно-ориентированное программирование - Функциональное программирование

А как же логическое программирование и многие другие?

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

Инверсия зависимостей возможна практически в любой системе, ООП и полиморфизм подтипов тут не при чём.

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

Это всё прекрасно делается и в большинстве других парадигм.

Никогда особо не «восхищался» Мартином, но тут он совсем разочаровал ограниченностью своего кругозора.

1

Сообщение от korvin_ Инверсия зависимостей возможна практически в любой системе, ООП и полиморфизм подтипов тут не при чём.

Сообщение от korvin_ Это всё прекрасно делается и в большинстве других парадигм.

Большинство ОО программистов считает, что это всё возможно только в ООП. Они даже полиморфизм подтипов называют просто полиморфизмом, как будто это единственный вид полиморфизма.

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

Сообщение от Storm23 Только в том примере сама модель неправильная. Если вдруг (а точнее - когда) появится животное которое не умеет есть, то будет попаболь. Вместо того, что бы пихать метод Eat в базовый класс, нужно сделать интерфейс ICanEat, и наследники Animal будут его реализовывать.

Согласен, так лучше.
Ещё лучше сделать миксин, чтобы можно было наследовать интерфейс сразу вместе с дефолтной реализацией.
А ещё лучше сделать классы типов (как в Хаскеле), чтобы не нужно было прописывать это наследование при написании класса.

0

Сообщение от Shamil1 А ещё лучше сделать классы типов (как в Хаскеле), чтобы не нужно было прописывать это наследование при написании класса.

Классы типов всё-таки немного не то. Тут подоходящим вариантом были бы объектные типы Ocaml или интерфейсы в Go.

0

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

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

Сообщение от titan4ik Вы можете дать ссылку на книженцию или что-то ещё, где растолковывается, как, например, на c# нужно писать хороший код в таком стиле процедурного программирования?

Конкретно с# заточен именно на ООП. Это объектный язык. Что познать дзен модульного подхода, нужно изучать оберон технологии. Почитать статьи Вирта и Гуткнехта, познакомится с языками которые обеспечивают модульность.

0

Сообщение от CoderHuligan Класс "автомобиль". Потом создают его потомков (ага - у автомобиля есть потомки, ну, ну..) - "двигатель", "дверь", "багажник", "кузов". Допустим от кузова порождают - "трансмиссия", от трансмиссии - "колеса"..

Вы совершенно не понимаете смысла наследования (или делаете вид, что не понимаете, учитывая сколько раз вам на это указывали).
Наследование означает связь является. Разве дверь является автомобилем? Нет. Поэтому и не должна наследоваться от автомобиля. Дверь наследуется от автомобиля только в вашем разгоряченном воображении.

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

Сообщение от CoderHuligan Ведь подшипники есть и в других частях машины? Да, они есть в рулевой колонке, в двигателе и т.д.

Отношение "есть в", "содержится" выражается агрегацией, а не наследованием.

Сообщение от CoderHuligan Проблема в иерархических классификациях, которые все усложняют

Классы позволяют сделать декомпозицию задачи на более простые подзадачи, принцип "разделяй и властвуй".

Сообщение от CoderHuligan Для корпораций это просто находка: чем более запутаннее код, тем сложнее в нем разбираться конкурентам.

Ну блин, ну очевидная же глупость....

1

Сообщение от CoderHuligan Для корпораций это просто находка: чем более запутаннее код, тем сложнее в нем разбираться конкурентам.

Напоминает теорию всемирного заговора.

Сообщение от CoderHuligan Конкретно с# заточен именно на ООП. Это объектный язык.

Но модульность он обеспечивает. Так что вполне можно писать в модульном стиле. И почти в любом другом (хотя, для некоторых стилей пришлось бы фремворк писать).

0

Сообщение от korvin_ Никогда особо не «восхищался» Мартином, но тут он совсем разочаровал ограниченностью своего кругозора.

Беда) Хорошо, что я на время оставил чтение)
А вы бы кого порекомендовали вместо Мартина по архитектуре?

0

Сообщение от titan4ik А вы бы кого порекомендовали вместо Мартина по архитектуре?

Архитектуре чего?

0

0

0

Сообщение от Storm23 Наследование означает связь является. Разве дверь является автомобилем? Нет.

Мне то до этого.. Я говорю о том как реально пишут свои произведения.

Сообщение от Storm23 Кроме того (и это даже важнее в архитектуре) модели не строятся для "отображения реальности".

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

Сообщение от Storm23 Программа отображает только определенный аспект предметной области.

Угу, но речь тут идет об ООП, а не о программе вообще.

Сообщение от Storm23 Например, если это ПО по продаже автомобилей, то там будет только модель, цвет кузова и цена.

Конечно. Там реляционная модель. В реальности. Зачем же приводить эти бесконечные примеры: фигура-треугольник-круг, город-дома-улицы, автомобили-кузова-транссмиссии? Отцы-основатели заблуждаются, а только одни Вы лучше всего поняли сущность ООП? Ну тогда поделитесь с ТС своими наработками.

Сообщение от Storm23 Отношение "есть в", "содержится" выражается агрегацией, а не наследованием.

Я же не против такого деления: авомобиль-кузов-трансмиссия. Просто не надо это жестко в структуру зашивать. Есть еще отношение "состоит из". И может выражаться более гибкой сетевой моделью помимо иерархической.

Сообщение от Storm23 Классы позволяют сделать декомпозицию задачи на более простые подзадачи, принцип "разделяй и властвуй".

Процедурное как бы тоже.

Сообщение от Storm23 Ну блин, ну очевидная же глупость....

Да.. Только почему-то все коммерсы пытаются обфусцировать свой код, причем даже иногда исходники. Например так делают в PHP: убирают переводы строк, пробелы, табуляцию. В итоге получается неудобочитаемая каша. Спрашивается: а на фига козе баян?. Вопрос риторический..

0

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

Всё есть отражение реальности.
Storm23 только совершенно справедливо заметил, что отражается не реальность как таковая, а реальность с точки зрения решаемой задачи. Иными словами, отражается модель реальности. А модель эта строится сообразно решаемой задачи.
Иначе можно докатиться то того, что строить иерархии вплоть до атомов и молекул. А они ведь тоже структуры.
Речь о разумной (с точки зрения критериев именно решаемой задачи) модели реальности. И эта модель и отражается в ПО.

Добавлено через 1 минуту
Но всё это уже немного не по теме. Или по теме?) Возможно)

Добавлено через 1 час 13 минут
Интересный момент.
Я там вначале писал, что только начал делать проектик, а уже переписываю. Так я опять это "начало" переписываю. И дело тут в основном в том, что изначально не вполне представлял себе эту самую модель предметной области в контексте задачи. То есть, дело не столько в самом программировании, и даже не в архитектуре ПО, дело, в основном, именно в этом - потихоньку приходит понимание модели в контексте задачи. А если контекст не понимать или не верно его понимать, то можно столько химер тупиковых наплодить даже с хор умением программировать и архитектурировать.
Вообще, правильная постановка задачи - это уже, как минимум, пол дела. Хорошее ТЗ (во всех областях деятельности) - это так редко встречается! Когда сам себе ТЗ выдаешь, то методом последовательных итераций можно придти к хор варианту без межличностных конфликтов

0

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

0

Сообщение от CoderHuligan А модель к архитектуре не имеет отношения.

я бы некомпетентно сказал, что принципы архитектуры не имеют отношения к модели. Но сама архитектура конкретного ПО, на своем уровне (на своем уровне асбтракции, как это любят говорить пр-ты), тоже естественно отражает супперпозицию модель-задача.
Хотя эти архитектурные паттерны могут быть и общими у задач одного класса.
Как называются арх и прочие паттерны для реализации некой автоматики (упр процессами)?
Тут в муравьиной теме упоминалось автоматное программирование, по каким ключевым словам погуглить?
Чтобы хоть знать как правильно модули называть)

0

Сообщение от titan4ik Как называются арх и прочие паттерны для реализации некой автоматики (упр процессами)?

Автоматизированная система управления - https://ru.wikipedia.org/wiki/... 0%B8%D1%8F
Полезно начинать изучение программирования именно с азов философии управления, пусть даже технологическими процессами. Она достаточно развита в научном смысле, в отличие от ООП, которое под науку до сих пор не подведено (математики нет).

Сообщение от titan4ik Тут в муравьиной теме упоминалось автоматное программирование, по каким ключевым словам погуглить? Чтобы хоть знать как правильно модули называть)

Автоматное программирование и есть та серебрянная пуля, имхо, которую все ищут, или прямой путь к ней. (Математика есть - теория конечных автоматов) Приведу несколько ссылок.
1. https://ru.wikipedia.org/wiki/... 0%B8%D0%B5
2. http://is.ifmo.ru/
3. http://is.ifmo.ru/books/_book.pdf

0

Сообщение от CoderHuligan Мне то до этого.. Я говорю о том как реально пишут свои произведения.

Никто так не пишет. Это вы нагло врёте, приписывая самопридуманный бред нормальным разработчикам.

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

Так же в этих книжках пишут о детализации такого отражения, о чём господин Storm23 прямо и сказал. "Реальность" отражается ровно настолько детально, насколько требуется для решения задачи. Если у вас приложение по учёту автомобилей на платной парковке, то моделировать автомобиль дальше класса "Аватомобиль" с набором свойств описывающих номер и владельца, не надо.

Сообщение от CoderHuligan Угу, но речь тут идет об ООП, а не о программе вообще.

А ООП ничего такого, что вы ему приписываете, не требует.

Сообщение от CoderHuligan Конечно. Там реляционная модель. В реальности. Зачем же приводить эти бесконечные примеры: фигура-треугольник-круг, город-дома-улицы, автомобили-кузова-транссмиссии? Отцы-основатели заблуждаются, а только одни Вы лучше всего поняли сущность ООП? Ну тогда поделитесь с ТС своими наработками.

Отцы-основатели не заблуждаются. Это вы не так всё понимаете и придумываете себе аргументы.

Сообщение от CoderHuligan Я же не против такого деления: авомобиль-кузов-трансмиссия. Просто не надо это жестко в структуру зашивать. Есть еще отношение "состоит из". И может выражаться более гибкой сетевой моделью помимо иерархической.

Так никто ничего жёстко и не вшивает, если это не нужно.

Сообщение от CoderHuligan Да.. Только почему-то все коммерсы пытаются обфусцировать свой код, причем даже иногда исходники. Например так делают в PHP: убирают переводы строк, пробелы, табуляцию. В итоге получается неудобочитаемая каша. Спрашивается: а на фига козе баян?. Вопрос риторический..

Обфускация нужна для защиты кода от посторонних глаз. Может быть ещё минификация, для уменьшения размера кода и ускорения его разбора парсером. Это делается не с кодом, с которым работают, а с тем, который деплоят.

0

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

0