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

@titan4ik · 03.06.2020, 16:34. **Показов** 17687. **Ответов** 153

Студворк — интернет-сервис помощи студентам

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

@titan4ik · 15.06.2020, 18:11 **[ТС]**

Сообщение от korvin_

Эволюция и естественный отбор.

Может ли естественный отбор привести к неестественным последствиям?!
Это я о личной яхте длиной в футбольное поле (и стоимостью в миллион добрых дел) подумал. Тут явно чей-то указующий перст просматривается, который корректирует естественные процессы.

Добавлено через 50 секунд

Сообщение от korvin_

language-dependent.

Я c# зависимый.

@Shamil1 · 15.06.2020, 18:11

Сообщение от titan4ik

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

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

Сообщение от titan4ik

Чисто практически, представляется, что класс существенно меньше модуля.

Мо́дуль — функционально законченный фрагмент программы. Модуль вполне может состоять из всего одной функции.

@Storm23 · 15.06.2020, 19:01

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

Сообщение от korvin_

Вопрос к знатокам ООП, как правильно спроектировать классы и методы для написания текста:

Я понимаю, что это скорее риторический вопрос, с целью поддеть ООП.
Но тем не менее: все три варианта допустимы. Выбор зависит от утилитарных требований и общей архитектуры.
Если большинство кейсов таковы, что мне удобно вызывать методы у paper - я сделаю метод у paper. Если мне удобно, что бы текст сам по себе записывался в абстрактный paper - я сделаю метод у something и т.д. Еще в других случаях - я сделаю отдельный сервис, не привязанный к этим классам.
А однозначного "правильного" проектирования в ООП нет.

@korvin_ · 15.06.2020, 19:36

Сообщение от Storm23

Я понимаю, что это скорее риторический вопрос, с целью поддеть ООП.

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

Сообщение от Storm23

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

Вот у тебя отдельный сервис с методом:

Java
1
2
3
4
5
6
class Writer {
 
    void write(Writable something, WriteTool tool, Media target) {
        // ...
    }
}

что будет в теле метода?

Сообщение от Storm23

А однозначного "правильного" проектирования в ООП нет.

В этом и проблема: поверх простой техники наворотили столько «идеологии», что даже в рамках подхода есть множество поводов для споров и разногласий. Как будто вместо «инкапсуляции, наследования и полиморфизма» у вас «лебедь, рак и щука».

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

Сообщение от Storm23

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

Не все, а сервисы о моделях. Проблема в том, что при rich model получается то же самое, но наоборот: анемичные «сервисы», которые используются внутри модели для доступа, например, к БД, ФС, сети и т.п., и модели оказываются зависящими от этих сервисов.

Сообщение от Storm23

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

Наследование далеко не всегда нужно.

@Storm23 · 15.06.2020, 19:56

Сообщение от korvin_

что будет в теле метода?

Не могу понять смысла вопроса. Ну например будет вот так:

C#
1
2
3
void write(Writable something, WriteTool tool, Media target) {
        target.Items.Add(new Item(something, tool));
    }

Сообщение от korvin_

В этом и проблема: поверх простой техники наворотили столько «идеологии», что даже в рамках подхода есть множество поводов для споров и разногласий. Как будто вместо «инкапсуляции, наследования и полиморфизма» у вас «лебедь, рак и щука».

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

Если вам не нравится ООП, ну не используйте его. Я не собираюсь быть адвокатом ООП.
Могу лишь заметить, что лично мне ООП (плюс весь набор паттернов, построенных поверх него) позволяет успешно решать мои задачи. Что еще нужно?

Сообщение от korvin_

Наследование далеко не всегда нужно.

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

@korvin_ · 15.06.2020, 20:15

Сообщение от Storm23

Ну например будет вот так:

Ага, т.е. возвращаемся к одному из трёх перечисленных вариантов и вопросу почему target выбран в качестве «основного» объекта, а не tool или something.

Сообщение от Storm23

У меня нет никакой проблемы. И три принципа ООП никак не противоречат друг другу.

Речь не о противоречии принципов (которые, за исключением наследования и некоторыми оговорками про полиморфизм, не являются «принципами ООП»), а о том, что в мире ООП есть множество разных точек зрения о том, как «правильно» проектировать, которые, бывает, противоречат друг другу, а на практике нередко не соблюдаются.

Сообщение от Storm23

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

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

Сообщение от Storm23

Если вам не нравится ООП, ну не используйте его.

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

Сообщение от Storm23

И что? Всем перестать использовать ООП из-за этого?

Всем перестать использовать ООП везде, где нужно и не нужно, а начать применять его осмысленно и по назначению.

Даже в предложенном мной примере с тремя объектами, вместо того, чтобы предположить, что тут может подойти другой подход (или хотя бы не классическое ООП), ты всё равно попытался использовать привычный инструмент. =)

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

Сообщение от Storm23

Мы вообще-то про то и говорим, что иногда есть смысл в анемичных моделях

С точки зрения ООП анемичные модели — это не ООП. =)

@vantfiles · 16.06.2020, 00:30

Не по теме:

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

@Shamil1 · 16.06.2020, 01:03

Сообщение от Storm23

Вы приводите пример, где статические методы внутри класса модели. А Usaga имеет ввиду анемичную модель, где модель - это один класс, а сервис - это другой класс (со статическими методами).

Это две разные ситуации.

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

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

Сообщение от Storm23

И три принципа ООП никак не противоречат друг другу.

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

@titan4ik · 16.06.2020, 01:15 **[ТС]**

Сообщение от Shamil1

Мо́дуль — функционально законченный фрагмент программы. Модуль вполне может состоять из всего одной функции.

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

@CoderHuligan · 16.06.2020, 12:36

Сообщение от titan4ik

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

У айтишников конечно все иначе, иначе бы они не были бы айтишниками.. И модулем раньше называли просто процедуру. Сейчас модуль это - пусть даже одна функция, но обязательно с АТД в придачу. Без АТД модуль теряет свое значение модуля и превращается просто в библиотеку, пусть даже из одной функции..
Более современный взгляд на модуль: функции + структуры + интерфейсы. Уже три компонента. Раньше был один: функции, и сейчас пришли к трем..
Вопрос в том, правильная ли эволюция развития понятия "модуль", "класс"..
Вопрос, также в способах ухода от сложности и прихода к неэффективности.
Что понятней и эффективней?:

Code
1
2
3
4
5
6
7
8
9
10
11
12
функция  приготовить(что)
{
   если(что=="суп")
     варим суп;
   иначе
     если(что=="рагу")
       варим рагу;
     иначе
       если(что=="китайская_лапша")
         варим лапшу;
         и т.д.
}

и другой вариант:

Code
1
2
3
функция приготовить_суп();
функция приготовить_рагу();
функция приготовить_лапшу();

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

Во втором случае мы вызываем необходимую функцию сразу, и не тратим время на выбор вариантов в функции, а просто делаем необходимую нам работу. Enum не нужен. Вот это то, что я называю компонентом. Компонент делает только одно дело. И за этим надо следить. Эти компоненты пользуются услугами других компонентов общих для всех остальных.

@Shamil1 · 16.06.2020, 13:04

Сообщение от titan4ik

Под функцией вы что имеете ввиду?

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

@titan4ik · 16.06.2020, 13:19 **[ТС]**

Господа айтишники, после чтения ваших сообщений (не только в этой теме) встаёт закономерный вопрос. Скажите пожалуйста, а нет ли такого букваря (глоссария, словаря) в котором все термины программирования трактуются однозначно и он признан "скрижалью" сообществом программистов?
Это должна быть книга по теории программирования без привязки к ЯП.
А то у вас наблюдается настоящее вавилонское столпотворение. Вам для того, даже чтобы просто понять друг друга, нужно сначала определяться в терминах какой области программирования вы общаетесь. Иначе - бардак.
Такое бывает, когда практика шагает семимильными шагами (в разные стороны) впереди теории.
P.S.
Я уж не говорю о сленге, который в общем-то, как правило, объединяет специалистов и позволяет им быстрее понять друг друга. Тут же... Хуже всего когда сленг используют люди, которые слабо себе представляют что стоит за этими терминами. И которые нормальных терминов (не сленговых) не знают.

@Shamil1 · 16.06.2020, 14:09

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

Добавлено через 4 минуты
Можете попробовать почитать "Concepts, Techniques, and Models of Computer Programming" (можно найти и на русском). Хотя, возможно, она покажется Вам скучной.

@korvin_ · 16.06.2020, 14:34

Сообщение от CoderHuligan

Сейчас модуль это - пусть даже одна функция, но обязательно с АТД в придачу.

Не обязательно.

Сообщение от CoderHuligan

Без АТД модуль теряет свое значение модуля

Не теряет.

Сообщение от CoderHuligan

теряет свое значение модуля и превращается просто в библиотеку

Это ортогональные вещи.

Сообщение от CoderHuligan

В первом случае необходимо еще создать перечисление имен для функции "приготовить" (не показано). К тому же при каждом вызове приходится тратить время на переключение для поиска подходящего варианта. примерно то же самое происходит в ООП незаметно от глаза программистов.

Нет, в ООП будет

Code
1
2
3
класс суп: функция приготовить();
класс рагу: функция приготовить();
класс лапша: функция приготовить();

без всяких перечислений и, тем более, «если-иначе».

@CoderHuligan · 16.06.2020, 15:12

Сообщение от korvin_

Нет, в ООП будет

Методы будут переопределяться если эти классы будут объединены супер классом "блюдо". А они будут. А там таблица виртуальных функций тот же свитч. Может быть немного быстрее, но не намного.

@korvin_ · 16.06.2020, 15:33

Сообщение от titan4ik

Скажите пожалуйста, а нет ли такого букваря (глоссария, словаря) в котором все термины программирования трактуются однозначно и он признан "скрижалью" сообществом программистов?

Нет. Если бы такой был, мы бы тут ничего не обсуждали, а занимались бы полезными делами. =)

Сообщение от titan4ik

Это должна быть книга по теории программирования без привязки к ЯП.

Ну, в некотором смысле, SICP и упомянутая выше "CTM CP". Но прям про все в рамках одной книги всё равно не рассказать.

Сообщение от titan4ik

А то у вас наблюдается настоящее вавилонское столпотворение.

Ну так и есть. Добро пожаловать. =)

Мой совет: изучай «снизу», конкретные техники и концепции, а не «сверху», от «парадигм».
На примере того же ООП:

1) изучение «сверху»:
– читаешь описание (хотя бы на той же википедии), про «инкапсуляцию», «наследование», «полиморфизм»
– начинаешь углубляться, натыкаешься на кучу холиваров и мнений как по каждому из этих трёх слов, так и по их отношению к ООП и значимости
– узнаёшь, что не во всех языках, поддерживающих ООП, инкапсуляция строгая, и её можно обойти, есть разные модификаторы доступа (private/protected/public) и в разных языках присутствуют разные их комбинации, нет никакой «каноничной» инкапсуляции
– узнаёшь, что есть «определение ООП от Алана Кея» и что по мнению мистера Кея C++ — не ООП-язык, хотя многие будут говорить иначе
– находишь Design Patterns, изучаешь, вроде круто. А потом читаешь кучу критики паттернов
– узнаёшь, что наследование, оказывается, бывает разное (одиночное/множественное, разделение на «наследование реализации» и «реализация интерфейса»)
– узнаёшь, что полиморфизм бывает разный с совершенно разными свойствами
– читаешь про SOLID, какие это правильные принципы, а потом, возможно, находишь критику SOLID, как отдельных его компонентов, так и всего в принципе
– может быть, если совсем не повезёт, где-то в этом процессе читаешь Гради Буча, про UML и всё такое, потом обнаруживаешь, что на практике UML почти никто не использует
– может, узнаёшь, что ООП бывает и без классов (так называемое prototype-based ООП)
– и т.д. и т.п.
– ??????
– тонешь в этом океане понятий, принципов, подходов и их толкований разными людьми и реализаций в разных языках.

2) изучение «снизу»:
– читаешь, например, SICP
– узнаёшь про data directed programming: понимаешь, как (примерно) сделан «ООП-шный полиморфизм» через vmt (virtual method table), как работает и для чего нужен. Теперь ты знаешь, для каких задач и как его применять (и даже реализовать самому, если нужно), независимо от языка, можешь задавать конкретные вопросы и находить конкретные, полезные ответы
– узнаёшь про message passing: понимаешь, чем это отличается от vmt, чем ООП Алана Кея отличается от ООП C++. Понимаешь, чем отличаются class-based и prototype-based ООП. На этом этапе уже способен сам реализовать свою простую ООП-систему
– в процессе узнаёшь про области видимости, окружения и замыкания, в результате понимаешь, что такое инкапсуляция в принципе, в отрыве от языка, и как это связано с ООП
– про наследование там ничего нет, но ты уже понимаешь, что оно не столько определяюще свойство ООП, а лишь удобный инструмент. Легко можешь имитировать простое наследование (точнее это будет делегирование) в своей простой ООП-системе
если ООП интересно глубже:
– читаешь «A Theory of Objects» Cardelli & Abady — про «внутренню кухню» и формализацию. Вообще узнаёшь много нового. Книга не простая, но хотя бы с парой-другой первых глав ознакомиться стоит. Без привязки к языкам
– читаешь «SmallTalk 80» (The Blue Book) — узнёшь, собственно, про объектно-ориентированное программирование, т.е., не про то, как устроены объекты внутри, а как ими пользоваться и с их помощью решать задачи. Хотя, там вроде и про внутреннюю реализацию, хотя и на примере SmallTalk, что, в общем-то не плохо
– ?????
– PROFIT: знаешь, что такое ООП, на каких конкретных техниках строится, для чего используется, без всяких терминологических споров и разношёрстных толкований

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

Сообщение от CoderHuligan

Методы будут переопределяться если эти классы будут объединены супер классом "блюдо". А они будут.

1) Не обязательно.
2) И что?

Сообщение от CoderHuligan

А там таблица виртуальных функций тот же свитч.

Нет там свитча.

Добавлено через 15 минут
titan4ik, ещё порекомендую ознакомиться с «Types and Programming Languages» Pierce, книга не очень простая (а есть ещё «Advanced TAPL» =)), но толковая, даже беглое ознакомление будет весьма полезно.

@CoderHuligan · 16.06.2020, 16:27

Сообщение от korvin_

Мой совет: изучай «снизу», конкретные техники и концепции, а не «сверху», от «парадигм».
На примере того же ООП:

Пока он это будет изучать кто-то напишет 100 проектов.

@vantfiles · 16.06.2020, 16:42

Сообщение от CoderHuligan

Пока он это будет изучать кто-то напишет 100 проектов.

Но так и не сумеет их отладить...

@Shamil1 · 16.06.2020, 17:01

В моей подписи 4 книги (sicp, aima, ctm, tpl), которые я считаю классикой программирования. Желательно читать в указанном порядке.

Добавлено через 5 минут
sicp - как писать программы
aima - основные (ключевые) алгоритмы
ctm - подробней о парадигмах
tpl - подробней о типах

@titan4ik · 16.06.2020, 17:31 **[ТС]**

Сообщение от korvin_

Нет. Если бы такой был, мы бы тут ничего не обсуждали, а занимались бы полезными делами. =)

+100

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@titan4ik Заблокирован

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

@vantfiles
	16.06.2020, 00:30
	Не по теме: Когда я знакомым программистам начинаю рассказывать, что в прототипном ооп можно убирать методы после наследования, у них как правило случается вывих мозга... 0

@titan4ik Заблокирован
	16.06.2020, 13:19 [ТС]
	Господа айтишники, после чтения ваших сообщений (не только в этой теме) встаёт закономерный вопрос. Скажите пожалуйста, а нет ли такого букваря (глоссария, словаря) в котором все термины программирования трактуются однозначно и он признан "скрижалью" сообществом программистов? Это должна быть книга по теории программирования без привязки к ЯП. А то у вас наблюдается настоящее вавилонское столпотворение. Вам для того, даже чтобы просто понять друг друга, нужно сначала определяться в терминах какой области программирования вы общаетесь. Иначе - бардак. Такое бывает, когда практика шагает семимильными шагами (в разные стороны) впереди теории. P.S. Я уж не говорю о сленге, который в общем-то, как правило, объединяет специалистов и позволяет им быстрее понять друг друга. Тут же... Хуже всего когда сленг используют люди, которые слабо себе представляют что стоит за этими терминами. И которые нормальных терминов (не сленговых) не знают. 0

@Shamil1 Модератор 3140 / 2288 / 469 Регистрация: 26.03.2015 Сообщений: 8,898
	16.06.2020, 14:09
	Авторы книг по разным языкам используют разную терминологию. Так исторически сложилось. Добавлено через 4 минуты Можете попробовать почитать "Concepts, Techniques, and Models of Computer Programming" (можно найти и на русском). Хотя, возможно, она покажется Вам скучной. 1

@Shamil1 Модератор 3140 / 2288 / 469 Регистрация: 26.03.2015 Сообщений: 8,898
	16.06.2020, 17:01
	В моей подписи 4 книги (sicp, aima, ctm, tpl), которые я считаю классикой программирования. Желательно читать в указанном порядке. Добавлено через 5 минут sicp - как писать программы aima - основные (ключевые) алгоритмы ctm - подробней о парадигмах tpl - подробней о типах 0