Здравствуйте, gandjustas, Вы писали:
S>>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
G>Считаем:
G>1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
G>2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
G>3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
G>Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения,
и вроде (но не точно) работал в ibm. Мой вопрос был про кол-во людей, что много людей для того, чтобы технология взлетела
и не требуется. Сравнивать их не имеет смысл. У DDD роль гораздо меньше.
S>>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
G>Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
Ну не скажите, там иногда читают очень достойные доклады. Вот например:
https://www.youtube.com/watch?v=KTy4rqgPOjg
S>>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>>Т.е. заказчик деньги платит не зря.
G>Повторить аргумент про лженауки?
В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов
по ссылке выше.
S>>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
S>>для решения одной проблемы.
G>То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
А в ООП тоже верят? Ведь есть проекты для которых он избыточен, но все равно будет написано с 95% на каком-нибудь ООП языке.
S>>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
G>Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
Он не про ORM и таблицы в бд.
S>>Он там спрятан за паnтерном Repository.
G>И какой интерфейс выставляет этот Repository?
Можно нагуглить.
G>>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
G>Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
S>>Я пока понять не могу, что в этом плохого?
G>Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь
банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends.
S>>Какой программист больше заработает денег?
G>Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
Едва ли будет ценовая разница, край несколько 10$. Можно считать, что цена одинакова.
S>>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
G>Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
Если сохранять класс, когда у него все ок с инвариантами, то почему нет? Для пользователя класса у него всегда должны
быть инварианты, пользователь затем может этот класс сохранить.
S>>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
G>И как это поможет доказать что DDD имеет какие-то преимущества?
А как это может доказать обратное? Зачем вообще что-либо подсчитывать?
S>>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
G>вот минимальный пример:
G>G>abstract class CollectionBase<T>
G>{
G> public int Count { get; private set; }
G> protected virtual void AddCore(T item)
G> public void Add(T item)
G> {
G> AddCore(item);
G> Count+=1;
G> }
G> protected virtual T GetCore(int index);
G> public T Get(int index)
G> {
G> ArgumentOutOfRangeException.ThrowIfGreaterThanOrEqual(index, Count);
G> ArgumentOutOfRangeException.ThrowIfNegative(index);
G> return GetCore(index);
G> }
G>}
G>
G>Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
G>Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А как люди с коллекциями на Си работали и работают?
S>>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
G>Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
G>Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
Тем не менее пишут же зачем-то на C#.
