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

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

0

Сообщение от CoderHuligan инкапсуляция это выделение АДТ или просто данных в отдельный файл, модуль.

AДТ или данных? Потому что АДТ - это набор функций. А данные - это ссылка неизвестно на что (например void*).

Сообщение от CoderHuligan Функции работают с данными через global.

Что за global? Звучит ужасно.

0

Сообщение от Shamil1 Вы могли бы сделать все методы статическими.

Нет. Тогда мы возвращаемся к анемичным моделям и stateless-сервисам. И как выше было подмечено, теряем возможность инкапсуляции каких-то собственных данных модели.

0

Сообщение от Usaga Нет. Тогда мы возвращаемся к анемичным моделям и stateless-сервисам. И как выше было подмечено, теряем возможность инкапсуляции каких-то собственных данных модели.

Не понял. Можете показать на небольшом примере, что нельзя сделать статическими методами?

0

Shamil1, речь не о "нельзя", а о том, что собственные методы класса могут работать с приватными полями, а статические - нет. Придётся делать поля публичными. А это нарушает инкапсуляцию.

0

Сообщение от Usaga собственные методы класса могут работать с приватными полями, а статические - нет

Не верно. Опровергающий пример я уже постил.
ООП - парадигмы, паттерны, подходы - кратко и доходчиво

0

Shamil1, Вы правда считаете, что набор статических методов, которым ссылку на объект нужно передавать явно лучше, чем методы экземпляра, которые через this могут нормально обращаться к полям?

0

Сообщение от Usaga Вы правда считаете, что набор статических методов, которым ссылку на объект нужно передавать явно лучше, чем методы экземпляра, которые через this могут нормально обращаться к полям?

Не вижу разницы. Различия только в синтаксисе.

0

Shamil1, а я вижу: лишнее телодвижение, с явным обращением к имени класса, с передачей в метод ссылки. Не возможность применения наследования для переопределения поведения. Ну и в коде вам нужно знать не только ссылку на объект, у которого можно было просто дёрнуть метод, но ещё и класс, где этот метод можно найти. Усложнения на пустом месте, без какого-либо профита.

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

0

Сообщение от Usaga лишнее телодвижение, с явным обращением к имени класса, с передачей в метод ссылки

Нужно или не нужно писать имя класса - зависит от синтаксиса конкретного языка программирования. Например, в Си писать не нужно, в C# можно не писать (если использовать using).

В С# cсылка на объект в метод передаётся неявно, но имя объекта всё-равно требуется. Вам больше нравится писать имя объекта перед именем функции, кому-то больше нравится писать имя объекта справа от имени функции. Я не вижу принципиальной разницы - дело вкуса (и синтаксис языка).

Сообщение от Usaga Не возможность применения наследования для переопределения поведения.

Да. А зачем нужно наследование в описанных случаях (АТД)?

0

Сообщение от Shamil1 Нужно или не нужно писать имя класса - зависит от синтаксиса конкретного языка программирования. Например, в Си писать не нужно, в C# можно не писать (если использовать using).

Так в Си вообще классов нет и у нас так и получится - отдельно полностью открытая структура, отдельно набор статических методов. А использование using не отменит необходимости обращаться к имени типа через точку. Только взамен имени типа будет алиас. Разница-то в чём? Опять же лишняя сущность, без которой можно обойтись.

Сообщение от Shamil1 В С# cсылка на объект в метод передаётся неявно, но имя объекта всё-равно требуется. Вам больше нравится писать имя объекта перед именем функции, кому-то больше нравится писать имя объекта справа от имени функции. Я не вижу принципиальной разницы - дело вкуса (и синтаксис языка).

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

Сообщение от Shamil1 Да. А зачем нужно наследование в описанных случаях (АТД)?

Но описанный случай разве про АТД? У нас не коллекция неизвестно чего. А класс с конкретным содержимым (возможно приватным).

0

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

1) структуру можно сделать закрытой.
2) определение структуры и методов можно разместить рядом, в одном файле.

Сообщение от Usaga А класс с конкретным содержимым (возможно приватным).

Конкретное приватное содержимое — деталь реализации. «Пользователи» объекта взаимодействуют с ним через публичный интерфейс, так же, как и в случае АТД.

0

Сообщение от korvin_ Конкретное приватное содержимое — деталь реализации. «Пользователи» объекта взаимодействуют с ним через публичный интерфейс, так же, как и в случае АТД.

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

0

Сообщение от Usaga А использование using не отменит необходимости обращаться к имени типа через точку.

Повторюсь - это синтаксис конкретного языка программирования. В других языках будет по-другому. И я не понимаю, чем имя функции "Math.Pow" хуже имени "Pow". ИМХО это не дополнительная сущность, просто так получилось, что в C# нельзя объявить функцию вне класса (в С++, например, можно).

Сообщение от Usaga Но описанный случай разве про АТД?

Да. У нас есть некий объект (чёрный ящик) и набор функций для работы с ним (начиная с инициализации и заканчивая освобождением ресурсов, если требуется).

0

Сообщение от titan4ik В ООП же инкапсуляция реализуется на уровне каждого объекта (Класса).

В чём разница между классом и модулем? Чем инкапсуляция "на уровне класса" лучше инкапсуляции "на уровне модуля"?

0

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

Во-первых, природу как раз-таки «пальцем делали».
Во-вторых, в природе любой объект можно «разкапсулировать» на различном уровне различными инструментами.
В-третьих, чем это, по-твоему, отличается от АТД?

0

Сообщение от titan4ik Это очень природоподобная идея.

Ага. Класс Вода с методами "нагреть" и "вскипятить". Очень природоподобная идея.

0

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

или
или
?

0

[Forth]
pen paper write
[/Forth]

0

Сообщение от korvin_ Во-первых, природу как раз-таки «пальцем делали».

я не в курсе таких подробностей.

Сообщение от Shamil1 Ага. Класс Вода с методами "нагреть" и "вскипятить". Очень природоподобная идея.

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

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

Сообщение от korvin_ Во-вторых, в природе любой объект можно «разкапсулировать» на различном уровне различными инструментами.

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


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

Сообщение от Shamil1 В чём разница между классом и модулем? Чем инкапсуляция "на уровне класса" лучше инкапсуляции "на уровне модуля"?

Чисто практически, представляется, что класс существенно меньше модуля. Класс - кирпичик. Модуль может состоять из большого числа кирпичиков. Разные модули может могут содержать одинаковые кирпичики. Но поскольку в программировании бардак с терминами, то каждый может представлять себе что хочет.

0

Сообщение от titan4ik я не в курсе таких подробностей.

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

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

Это не обязательно, и по большому счёту language-dependent.

Сообщение от titan4ik Модуль может состоять из большого числа кирпичиков.

Как и объект может состоять из большого числа других объектов.

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

Как и разные классы.

1