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

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

0

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

1

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


Добавлено через 13 минут
Я не пояснил. Инфраструтурный слой у Эванса ещё ниже модели, то бишь, он самый глубинный по Эвансу. У Эванса верхний слой зависит от нижнего.
P.S. Они с Мартином ещё и верх и низ перепутали. Зачем? Не понятно.

0

Сообщение от titan4ik программирование это не наука

Это инженерное творчество. И как любое творчество - индивидуально.

0

0

Сообщение от korvin_ «рекламщиков»

korvin_, что значит "рекламщики"?
То есть, вы полагаете, что их святая цель не поделиться истинными и сокровенными знаниями, которые прошли достаточно серьезную верификацию на основе их личного опыта и опыта сообщества программистов, а "несколько иная"?!)

0

Сообщение от titan4ik что значит "рекламщики"?

Потому что постоянно спорят, чьё кун фу сильнее.

Ситуация осложняется тем, что наука довольно молодая. Проекты усложняются, на первый план выходят другие задачи (цифровые технологии проникают в новые сферы). Паттерны меняются. Например, для сохранения в БД - активная запись, репозиторий, команда-запрос... Думаю, лет через 100 более-менее утрясётся всё.

У каждого паттерна есть свои преимущества и недостатки. Баланс часто зависит от типа и размера задачи... и даже от привычки (у каждого свой стиль).

0

Сообщение от Usaga titan4ik, почитайте Эрика Эванса. Гарантированно с первого раза не усвоите, но никто не запрещает перечитать) Лично мне очень сильно понравилось.

Usaga,
Я сейчас его читаю. Но у меня возникли смутные сомнения.
На стр 133-140 идут рассуждения о полезности шаблона Фабрика. Сейчас слегка глянул что это такое и задумался - "а оно мне нужно"? Не использовать конструкторы классов? New - это уже криминал и т.п.
Вопрос. На каком уровне сложности проекта всё это может быть полезно? Я имею ввиду и всю книгу Эванса и конкретно паттерн Фабрика. Очень многое из книги Мартина "чистая архитектура" и этой Эванса связано именно с масштабом проекта и с тем, что он разрабатывается большим коллективом людей.
Но я-то один и мыслю сейчас только о десктоп приложениях для 1 компьютера (+ немного веб).
Меня собственно в эти дебри затащила проблема того, как организовать взаимодействие между функциональными модулями программы.
Средства C# для реализации механизмов взаимодействия модулей программы
Ну и ещё, конечно, проблема моделирования предметной области (тут я из Эванса кое-что черпаю, но боюсь в нём зарыться)
Чувствую, что читая книги этих достойных людей, я черпаю мизер полезного для себя.
Вон и Эванс Мартин в итоге честно признался -

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

То есть, знания они конечно лишними не бывают но...
P.S. А вообще, пришел к выводу, что наиболее быстро можно получать знания по программированию только работая в команде программистов. Всё остальное (чтение книг и т.п.) важно, но без первого компонента теряет свою эффективность на порядок.

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

Сообщение от Shamil1 Ситуация осложняется тем, что наука довольно молодая.

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

Добавлено через 2 минуты
Не ну для любой рутинной задачи, конечно, есть способ ее решения. проблема в том, что этот способ не один))) И знать и/или выбрать его - это искусство.

0

Сообщение от titan4ik Это не наука.

Скорее так: это не только наука. Так же как, например, строительная архитектура — это не только дизайн («красивость» здания, «эргономичность»), но и теоретическая механика, и сопротивление материалов, и наверняка, много что ещё.

Сообщение от titan4ik что значит "рекламщики"?

Сообщение от titan4ik Но у меня возникли смутные сомнения.

Вот потому и сомнения: подобные книги не являются научными трудами, они излагают субъективный опыт отдельных людей. Это не значит, что знакомство с этим опытом бесполезно, напротив, но нужно помнить о его субъективности и специфичности, о том, что это не своды законов математики/логики или что-то такое. И одна из целей авторов — продать эти книги (и себя в том числе). В этом мало плохого, в общем-то, но стоит помнить об этом.

1

Сообщение от korvin_ они излагают субъективный опыт отдельных людей.

Проблема в другом - в том, что читателю нужно ИЗНАЧАЛЬНО понимать насколько этот их личный опыт может помочь читателю в задачах его уровня.
Например, человек собирается на охоту на уток с двустволкой. Но наткнулся у инете на книгу по теории обнаружения, сопровождения и поражения низколетящих целей средствами дивизионной ПВО. Насколько это ему полезно прочитать перед охотой?!)

Добавлено через 1 час 40 минут
Эванс стр 167 об антипримере разбиения на модули программы для организации поставок грузов:

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

0

Сообщение от titan4ik Это не наука. Это способы, методы и средства решения практических задач. Причем, в основном - бизнес-задач.

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

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

0

Ботаника это раздел биологи. Безусловно - ботаника это наука. Без всяких "даже".

Сообщение от Shamil1 Но рано или поздно всё это систематизируют, подведут под это дело математику

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

0

0

Сообщение от titan4ik рассуждения о полезности шаблона Фабрика. Сейчас слегка глянул что это такое и задумался - "а оно мне нужно"?

Я писал уже в самом начале. Не нужно впихивать паттерны. Паттерны нужно использовать, тогда когда в них возникает необходимость. То есть если без них - никак.
Вам нужно реализовать принципы SOLID, DRY, YAGNI, KISS. Если же принципы не выполняются, то делаем рефакторинг. Если принципы продолжают не выполняться и нас это смущает - подбираем паттерн, который решает проблему.
То есть используйте паттерны, когда без них обойтись нельзя.

В реальности из всех паттернов вам скорее всего нужен только MVC/MVP/MVVP/MV*. Все остальное - только по явной необходимости.

Сообщение от titan4ik Все попытки создать строгую научную (математическую) дисциплину так и остались попытками

Во-первых, научная математическая база для программирования - есть. Это теория алгоритмов и автоматов. В том числе машина Тьюринга. Другой математики там не нужно.
Во-вторых. Вы поймите, что тру язык - это только язык машинных кодов. Все остальное - это просто надстройка для удобства программиста. Поэтому непонятно какую научную базу вы собрались там подводить? Если изначально это просто вопрос удобства и проблема ограниченности мозгов человека. Языки высокого уровня ничего не делают такого, чего не может сделать машина тьюринга. Паттерны - тем более.
Все это нужно просто потому, что: задача не четко сформулирована, человек может ошибаться, работает одновременно несколько человек и т.д. Все это субъективные проблемы, и не имеют отношения к точным наукам. Поэтому и непонятно какую точную науку вы там ожидаете увидеть. Никакая точная наука не заставит вашего заказчика точно сформулировать то, что он хочет увидеть в ПО. Никакая наука не заставит Васю не ошибаться в интерпретации ТЗ, и т.д.

Сообщение от titan4ik что Мартин помещает сущности (модель предметной области) в самый центр (или на самый верх)

Сообщение от titan4ik По Эвансу же, те слои, что выше модели, зависят от неё, а сама модель зависит от инфраструктурного слоя.

Да нет там особых противоречий. Ну решил Эванс сделать еще один слой "инфраструктура". Он скорее всего имеет ввиду какие то банальные вещи типа базовых классов фреймворка или паттерны взаимодействия типа шины сообщений или издатель-подписчик.
Понятное дело, что вы в модели данных будете использовать классы типа List<int>. Но это и так очевидно. Поэтому Мартин это отдельным слоем не считает.

Сообщение от Shamil1 Думаю, лет через 100 более-менее утрясётся всё.

Аминь...
Через 100 лет на земле останутся только роботы, и им ЯПы вообще не нужны будут.

0

Сообщение от Storm23 Поэтому непонятно какую научную базу вы собрались там подводить?

Я? Никакой. Это старина Дейт (и прочие) хотел. Да и вы пишите о такой базе. Она безусловно есть (в какой-то степени). Я не вижу тут темы для обсуждения.

0