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

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

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

@Usaga · 16.06.2020, 17:46

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

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

Так обсуждение шло в том ключе, что торчание наружу всеми данными не всегда есть хорошо (или удобно). Как вы собрались гарантировать непротиворечивость модели, если всё её содержимое торчит наружу без защиты в виде логики?

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

и можно вообще без классов обойтись, так как АТД не имеют никакого отношения к ООП.

Можно. Но согласитесь, что удобнее воспринимать некую сущность как целостный объект (в коде), а не как размазанный по коду (пускай и в рамках файла) набор структур и функций.

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

korvin_,
На самом деле, для меня обсуждение было полезным. Правда, не вполне уверен, что смогу быстро воспользоваться этой пользой)
Однако, спасибо!

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

@korvin_ · 16.06.2020, 18:00

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

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

Ты пока ни одного не написал.

@CoderHuligan · 16.06.2020, 18:19

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

Ты пока ни одного не написал.

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

@Usaga · 16.06.2020, 18:21

titan4ik, почитайте Эрика Эванса. Гарантированно с первого раза не усвоите, но никто не запрещает перечитать) Лично мне очень сильно понравилось. Ещё народ Гари Буча сильно хвалит.

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

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

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

Мне кажется, или это лично вы сами разделили всё на "классику" и "корпоратив"? При этом в само корпоративе даже не работали. Попробовать непредвзято (т.е. без эмоций) посмотреть на мир вы не пробовали?

@korvin_ · 16.06.2020, 18:31

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

Но согласитесь, что удобнее воспринимать некую сущность как целостный объект (в коде), а не как размазанный по коду (пускай и в рамках файла) набор структур и функций.

Не вижу никакой разницы между

F#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
type positioned =
  <
    coordinates : float * float
  >
 
class point (label : char) (coords : float * float) =
  object
    val x = fst coords
    val y = snd coords
    method coordinates = coords
    method to_string = Printf.sprintf "%c(%.2f, %.2f)" label x y
    method distance_to (p : positioned) =
      let (x2, y2) = p#coordinates in
      sqrt ((x -. x2) ** 2. +. (y -. y2) ** 2.)
  end

и

F#
1
2
3
4
5
6
7
8
9
10
11
module Point : sig
  type t
  val create    : char -> float * float -> t
  val to_string : t -> string
  val distance  : t -> t -> float
end = struct
  type t = char * float * float
  let create label (x, y) = (label, x, y)
  let to_string (label, x, y) = Printf.sprintf "%c(%.2f, %.2f)" label x y
  let distance (_, x1, y1) (_, x2, y2) = sqrt ((x1 -. x2) ** 2. +. (y1 -. y2) ** 2.)
end

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

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

Ещё народ Гари Буча сильно хвалит.

Его зовут Гради Буч. =)
Максимум на что годится его творчество — вызывать сон. Лучше уж Мейера почитать — и интересней и полезней.

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

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

Куча недописанного

Ясно-понятно.

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

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

Я приверженец классики.

Ты приверженец не классики, а ископаемых, подумой.

@Shamil1 · 16.06.2020, 18:52

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

Но согласитесь, что удобнее воспринимать некую сущность как целостный объект (в коде), а не как размазанный по коду (пускай и в рамках файла) набор структур и функций.

Если брать C#, то у Вас и так класс, и так класс (только методы статические). Не вижу большой разницы. Если брать другой язык (не ОО), то слово "класс" меняется на слово "модуль". Разница ещё меньше.

@Usaga · 16.06.2020, 19:01

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

Не вижу никакой разницы между

Я тоже. Потому, что не сильно понимаю, что там делается.

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

Его зовут Гради Буч. =)

Я знаю. Я опечатался) Лошара)

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

Если брать C#, то у Вас и так класс, и так класс (только методы статические). Не вижу большой разницы. Если брать другой язык (не ОО), то слово "класс" меняется на слово "модуль". Разница ещё меньше.

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

@Shamil1 · 16.06.2020, 19:24

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

Как вы собрались гарантировать непротиворечивость модели, если всё её содержимое торчит наружу без защиты в виде логики?

Единственный способ гарантировать непротиворечивость (сложной) модели - это её проверить (валидировать). Делать это в сеттерах бессмысленно, так как каждое свойство может фигурировать в нескольких правилах.

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

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

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

статические методы лишают возможности использования наследования\реализации интерфейсов

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

@korvin_ · 16.06.2020, 19:30

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

Как вы собрались гарантировать непротиворечивость модели, если всё её содержимое торчит наружу без защиты в виде логики?

Что ты подразумеваешь под торчанием наружу без защиты? Модель может быть immutable, а непротиворечивость гарантируется конструкторами. Кроме того, обмазка полей геттерами и сеттерами — это всё то же торчание наружу, а не rich model, у rich model нет банальных геттеров и сеттеров (сеттер с валидацией — тоже банальный сеттер), а есть методы а ля doSomething, которые инкапсулируют логику работы с данными модели. Егор Бугаенко об этом подробно рассказывает.

@Shamil1 · 16.06.2020, 19:45

p.s. Знание нескольких языков хотя бы на уровне решения учебных задач позволяет отличать ограничения парадигмы от ограничений конкретного языка. А так же отличать код, специфичный для некой парадигмы, от универсального кода. Например, циклы используются в ОО языках, но не являются признаком ОО языка.

@korvin_ · 16.06.2020, 21:34

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

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

Ну, что поделать. В целом, не обязательно пытаться прочитать всю книгу «за раз». Из нарекомендованных, по-моему, лучше начать с SICP, она попроще остальных и читается легко.

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

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

статические методы лишают возможности использования наследования\реализации интерфейсов

Вместо наследования можно использовать делегирование, а реализация интерфейса:

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class FooModule {
 
    static class T {
        // data
    }
 
    static void foo(T value) {
        // impl
    }
}
 
interface Fooable {
 
    void foo();
}
 
import static FooModule.*;
 
T x = new T();
Fooable fx = () -> foo(x);

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

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

не сильно понимаю, что там делается.

:okay:

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Point {
    
    private char label;
    private double x;
    private double y;
 
    public Point(char label, double x, double y) {
        this.label = label;
        this.x = x;
        this.y = y;
    }
 
    public String toString() {
        return String.format("%c(%.2f, %.2f)", label, x, y);
    }
    
    public double distanceTo(Point other) {
        return Math.sqrt(Math.pow(x - other.x, 2) + Math.pow(y - other.y, 2));
    }
}

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class PointM {
 
    public static class T {
        private char label;
        private double x;
        private double y;
    }
 
    public T create(char label, double x, double y) {
        var point = new T();
        point.label = label;
        point.x = x;
        point.y = y;
        return point;
    }
 
    public static String toString(T point) {
        return String.format("%c(%.2f, %.2f)", point.label, point.x, point.y);
    }
 
    public static double distance(T a, T b) {
        return Math.sqrt(Math.pow(a.x - b.x, 2) + Math.pow(a.y - b.y, 2));
    }
}

@titan4ik · 20.06.2020, 17:30 **[ТС]**

Задал новый безутешный вопрос (Средства C# для реализации механизмов взаимодействия модулей программы) и опять стал читать Роберта Мартина (с самого начала, ибо забыл уже то, что прочитал в начале месяца, когда открыл эту книгу и потом на время забросил) - читаю как новую книгу и что-то даже стало доходить)))

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

Ну, меня-то интересует практика, а не теория. Однако. Однако, Роберт Мартин умный чувак. Полезно его почитать.

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

@titan4ik · 24.06.2020, 00:03 **[ТС]**

Дочитывая Дядюшку Боба наткнулся на сакраментальную фразу (стр 348)

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

не, ну чё-то полезное из этой книженции, наверное, нельзя не почерпнуть!(?).

@Shamil1 · 24.06.2020, 12:34

Это то, о чём я писал в самом начале темы (не нужно использовать паттерны, пока не ...).

@titan4ik · 25.06.2020, 23:16 **[ТС]**

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

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

@korvin_ · 25.06.2020, 23:33

titan4ik, а что мистер Эванс говорит про предментно-ориентированные языки (domain specific languages)?

@titan4ik · 25.06.2020, 23:58 **[ТС]**

Пока не знаю) Он исходит из ООП языков. Вроде даже упоминания пока не было (дальше стр 76 не читал).

@vantfiles · 26.06.2020, 07:50

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

если используется такой язык, как С

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

Процедурные языки отличаются тем, что

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

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

но эти типы - все-таки не более чем организованные данные

Демагогия.

@titan4ik · 26.06.2020, 10:54 **[ТС]**

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

Новые блоги и статьи Все статьи Все блоги /
Программа для com-порта Uhbif79 05.06.2026 Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу. До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .	Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .	21 мат мед. Планы на развитие модели здравоСохранения anaschu 01.06.2026 AnyLogic: план развития симуляционной модели рабочего коллектива — динамический абсентеизм, реальные данные, три сценария сравнения Продолжаю серию постов о дискретно-событийной модели рабочего. . .	20. Мат мед. Абсентеизм как отдельный тип простоя anaschu 29.05.2026 Апдейт модели: исправленные баги, абсентеизм и новые механизмы Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .
19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип anaschu 28.05.2026 Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .	"Прокси" для последовательного порта Eddy_Em 28.05.2026 Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .	Рефакторинг программы уравнивания. Massaraksh7 26.05.2026 Пример по предыдущей записи в блоге. Но, надо заметить, что, во-первых, там оптимизация не только математики, но и работы с базой данных, и с графами, а во-вторых, это ещё не всё.	Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .

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

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

@titan4ik Заблокирован
	16.06.2020, 17:54 [ТС]
	korvin_, На самом деле, для меня обсуждение было полезным. Правда, не вполне уверен, что смогу быстро воспользоваться этой пользой) Однако, спасибо! Добавлено через 6 минут Раз уж тут нарекомендовали увесистую подборку книг и тем, не могу не вспомнить, что когда я задал вопрос по "литературе по базам данных", мне кто-то порекомендовал "начать с Дейта". Я его прочитал с большим интересом. Дейт умный чувак. Не жалею. Но, прочитав, я понял, что начинать изучение "баз данных" с этой книги - это преступление против головного мозга, ресурсы которого, да и наше время, имеют свойство быть ограниченными) 0

@Shamil1 Модератор 3138 / 2286 / 469 Регистрация: 26.03.2015 Сообщений: 8,894
	16.06.2020, 19:45
	p.s. Знание нескольких языков хотя бы на уровне решения учебных задач позволяет отличать ограничения парадигмы от ограничений конкретного языка. А так же отличать код, специфичный для некой парадигмы, от универсального кода. Например, циклы используются в ОО языках, но не являются признаком ОО языка. 0

@Shamil1 Модератор 3138 / 2286 / 469 Регистрация: 26.03.2015 Сообщений: 8,894
	24.06.2020, 12:34
	Это то, о чём я писал в самом начале темы (не нужно использовать паттерны, пока не ...). 0

@korvin_ 4576 / 2775 / 491 Регистрация: 28.04.2012 Сообщений: 8,781
	25.06.2020, 23:33
	titan4ik, а что мистер Эванс говорит про предментно-ориентированные языки (domain specific languages)? 0

@titan4ik Заблокирован
	25.06.2020, 23:58 [ТС]
	Пока не знаю) Он исходит из ООП языков. Вроде даже упоминания пока не было (дальше стр 76 не читал). 0

@titan4ik Заблокирован
	26.06.2020, 10:54 [ТС]
	vantfiles, Вы цитируете цитаты так, как будто это мои высказывания. Вы же в данном случае не со мной тут дискутируете (я не имею на то должной компетенции), а с Эриком Эвансом. Это хорошо бы отмечать явно. 0