• И снова о Legacy. Вечная боль техдира
    +1
    Вы сделали одно допущение, что в монолите есть «публичные контракты»!
    Если для микросервисов это всегда так (by default).
    Я не делал такого допущения, просто считаю что накладные расходы, сложность проектирования распределённой системы, и сложность правки контрактов перевешивают этот спорный плюс.
    Спорный потому, что публичные контракты можно делать в монолите — вопрос желания, и потому, что я видел и микросервисы без
    задокументированных публичных контрактов — чтобы глянуть api лезли в код. Так что, при желании можно и…
  • И снова о Legacy. Вечная боль техдира
    +1
    В микросервисной архитектуре они не гадят в одну кодовую базу годами.
    А гадят в маленькие изолированные приложения.
    Только в том случае если они изолированны, при плохой архитектуре это не так. А при хорошей и в монолите можно делать независимые модули. По поводу переписывания микросервисов по одному, выше уже писали про публичные контракты.
    Чем больше связей, тем сложнее переписывать, и тем более переписывание по одному не поможет их исправить, нужно будет собирать общую картину из многих кодовых баз, и править всю цепочку, разбираясь во всех происходящих при этом событиях и эффектах.
  • И снова о Legacy. Вечная боль техдира
    +3
    Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.
    Вы исходите из предположения что микросервисы которых потопталось 3-4 поколения программистов лучше чем монолит в котором потопталось 3-4 поколения программистов, в чём я лично не уверен.
    С одной стороны — да, границы чуть более явные, с другой — как я писал, нарушения границ сложнее фиксить + накладные расходы на построение распределённого приложения.

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

    P.S. А что до:
    И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.
    Ну или размазанную бизнес логику между БД и приложением.
    Я немного наслышан про некоторые конторы, и о том, чего они творят с микросервисами, тоже волосы дыбом встают. Десятки микросервисов на запрос, сотни микросервисов при условии что в компании всего с сотню разработчиков, отдельный микросервис который ходит в БД с которым общаются все-все сервисы и пр.
  • И снова о Legacy. Вечная боль техдира
    +5
    Суть проблемы в том что в системе слишком много связей, а не в том что она монолитная или микросервисная. И да, рефакторить паутину в монолите будет проще чем рефакторить паутину из микросервисов.

    Ваше предложение из первого комментария верно, только слово «микросервисы» стоит заменить на модули, и грамотно декомпозировать приложение на независимые модули сложно.
    Микросервисы лишь проводят чуть более жёсткие границы между модулями, но и нарушения таких границ фиксить сложнее.

    А вот когда у вас есть грамотное декомпозированное приложение, и вам нужно масштабировать разработку, ещё меньше конфликтов в коде, добиваться CI/CD(нормального CI, а не «пайплайн настроить»), можно задуматься о микросервисах для большего контроля за границами модулей.
    Время идёт, инфраструктура совершенствуется, конечно, но микросервисы по прежнему несут за собой значимые накладные расходы.
  • Эх, айти, куда ж ты котишься? 
    0
    Если недостаточно — берёте async-pool и радуетесь жизни.
    Я, воодушевлённый как-то статьёй «сложность простоты», взял. Заработало медленее чем я ожидал, и чем больше общее число асинхронных задач, тем больше деградирует производительность, предположительно из-за этого — github.com/jwiegley/async-pool/issues/20, запуск с профайлером из подозрительного говорит об огромном количестве аллокаций.

    Видимо, для большого количества тасок, нужна какая-то другая библиотека.
  • Microsoft удвоит число темнокожих в своем руководстве
    +3
    А где нет «цирка»?

    Без подвоха вопрос, правда интересно, где иначе.
  • Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем
    +3
    Странно что про go не сказано ни слова.
    А чего сказать? Скудный язык с невыразительной системой типов (+), вряд ли можно назвать безопасным, ну и rust более низкоуровневый.
  • Коннекционизм
    0
    И я ещё раз напоминаю о существовании бирюзовых организаций, почитайте. Например, кейс Valve — там бирюзовый принцип работает для всех, а не только для программистов, и они как-то справляются с ответами на ваши вопросы. Почитайте про внутреннее устройство таких компаний.
    Особенно примечательный пример, в контексте возможных разногласий о которых пишет 0xd34df00d, учитывая что в итоге в «бирюзовой» valve внутри появились неявные иерархии, команды старичков, и проблемы с той самой оценкой сотрудников другими сотрудниками, а рейтинг компании от сотрудников на glassdoor упал уже до 3.3, с тезисами «Feels like a disorganized trap» и «Highly toxic work environment», «Advertising flat structure when there actually isn't».
  • PHP-Дайджест № 181 (18 мая – 1 июня 2020)
    +6
    У этого языка еще не накопилось достаточно опыта использования имеющегося синтаксиса ООП, чтобы принимать решения ломать стандарты, десятилетиями устоявшиеся в Java, C#.
    Java стандарты — последняя вещь, на которую стоит ориентироваться, когда речь идёт о выразительности языка или грамотных подходах к проектированию.
  • PHP 8 в восьми кусочках кода
    0
    Асинхронность хотя бы как в JavaScript
    yield есть, а экосистема — ну что поделать, не нужна среднестатистическому пхп разработчику асинхронность, вот и не популярно.

    Дженерики a.k.a. шаблоны
    Есть в psalm — psalm.dev/docs/annotating_code/templated_annotations

    Больше возможностей для типизации, например, возможность указать, что аргумент является массивам с элементами такого-то типа
    Также есть в psalm — psalm.dev/docs/annotating_code/type_syntax/array_types
    От тайпхинтов самих по себе без каких-либо статических гарантий пользы нет +- никакой
  • Эффективен ли TDD?
    0
    Вы путаете деление юнит-тесты/интеграционные тесты (что на самом деле вопрос про размер сайд-эффектов) и вопрос «код вперёд или тесты вперёд».

    «Тесты вперёд»(test first) и TDD это разные вещи, и TDD про написание конкретно юнит-тестов.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    По-моему, обобщением занимается именно автор — экстраполирует свой однобокий опыт с JS-разработкой и противопоставляет ей TS в качестве панацеи,
    Автор таки, насколько известно из его статей, не js- и не ts- разработчик, хотя наверняка имеет опыт написания кода на них.

    И статья эта вовсе не про js/ts, а как раз про два разных подхода в целом. JS тут скорее в роли наиболее близкого большей доле читателей антагониста.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    За это спасибо и ограничениям самого ТС, и качеству типов сторонних библиотек.

    То есть вы пишете об ограничениях одного конкретного используемого вами языка и его экосистеме, но тем не менее обощаете свои выводы на всех.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0
    Если вы требуете тайпхинтинг во всей кодовой базе и всех библиотеках, то вы внезапно получаете статически типизированный язык.
    Разве для этого не нужны какие-то гарантии от компилятора, что тайп хинты корректные?
    Тайп хинтинг в том же php это просто добавление проверок в рантайме во все места, где указан тайпхинт, их корректность до выполнения никак не гарантируется, программа по прежнему падает только в рантайме, плюс всякие неразрешимые с т.з. системы типов преобразования/операции допускаются.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0
    Так описывать типы — это же очень круто и стильно, тут весь пост про это.
    Видимо мы о разных постах, особенно учитывая что автор предпочитает таки f# а не джаву.

    Впрочем, если игнорировать суть, цепляться за слова, личности, аппелировать к другим языкам, решениям, не разбираясь как и для чего они были приняты, и увиливать от ответов это вся ваша аргументация, диалог смысла не имеет.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +2
    Программы на современных хипстерских статических языках (Go, Swift, Rust, в какой-то мере C#) куда больше напоминают Питон, чем С++.
    Все языки что вы перечислили имеют статическую типизацию. Автовывод типов не делает язык динамическим, а плюсы образцом надежной/выразительной системы типов вовсе не являются.

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

    И о том, что происходит конвергенция динамических и статических языков — в новые динамические, например
    Не ясно как вы пришли к таким выводам, учитывая что все приведенные вами новые языки статически типизированные.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    Оставьте деда в покое, у него TDD головного мозга.
    И дед прав!

    Не считаю так.

    Там в самом конце статьи написано: «So says this old C++ programmer», в этом вся суть.
    То что он пишет про качественный код это выводы сделанные им ещё лет 30 назад(хорошие выводы, ничего против), и их совершенствование да преобразования, в том числе чтобы их продавать побольше.
    В текущем топике я на него полагаться бы не стал.

    Утверждать что 100% покрытие тестами гарантирует что-либо как это может делать типизация — глупо.
    Как пример хотя бы sqlite покрытый тестами 5 раз по 100%.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    Еще раз: в скриптовых языках дистрибуция происходит на более раннем этапе чем обработка в среде исполнения.

    Это никак не оправдывает неудобство от динамики и не делает её удобнее.

    И я до сих пор их не вижу. «будет костылём», «рядом не стоят» — это все ваши эмоции.

    Тогда попробуйте наконец прочитать мой предыдущий комментарий полностью.

    А то что вы ставите статическую типизацию в один ряд с необязательными линтерами для js'а говорит лишь о том что вы не понимаете о чём пишете.

    Поэтому проверка типов и должна производится отдельно, ДО компиляции. Если говорить о веб-платформе — то там еще и большая сегментация самих сред, что добавляет

    Тайпскрипт и другие компилирующиеся в js языки вполне себе показывают что веб-платформа и компиляция с тайп-чекером могут успешно сосуществовать.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    Как к этому относится какая-то ненавистная вам часть комьюнити — совершенно не важно
    Это важно как минимум потому, что это самое комьюнити пишет код, с которым придётся взаимодействовать, и типы в нем либо будут указаны, либо нет.

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

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

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

    скепсис к типам — это ваша личная выдумка, напротив, все больше разработчиков начинает использовать подобные инструменты в обязательном порядке.

    Нет, это вздор хотя бы потому что мы говорим о разработчиках которые уже выбрали динамические языки. Линтеры и подсказки IDE это не подобные инструменты.

    Ваши личные эмоции тут не аргумент.

    Аргументы вы почему то решили «не заметить».
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    0
    Ну вот как-то в PHP нормально относятся к phpdoc аннотациям типа.
    phpdoc-аннотации типов в типичном пхп проекте это аннотацими сгенерированные phpstorm'ом которые в лучшем случае не забывают иногда поправлять.

    Используют хотя бы статический анализ на уровне psalm/phpstan еденицы.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    И язык тут — дело второстепенное, с тем-же JS можно прекрасно юзать статический анализ и тайп-линтинг с аннотациями в JSDoc. Типы — это вопрос архитектурный и пылать праведным хейтом стоит, разве что, в адрес плохой архитектуры но никак не стека и самой возможности использовать динамическую типизацию.

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

    Я не думаю, что оно настанет в обозримом будущем.

    Это, ну, как программировать, не имея ни капельки алгоритмического мышления.

    К слову, нужен ли какой-то бэкграунд в математике/теории типов чтобы более-менее продуктивно писать на каком-нибудь Идрисе, или можно всё покрыть документацией(или книжкой по языку)?
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +8
    Вы путаете строгую/слабую типизацию со статической/динамической.

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

    Я ни один скрипт не стану писать без типов, если его будет кто-то читать(а его будет, кроме единственного случая, когда я хочу что-то сделать и удалить на локальной машине). В случае PHP хотя бы psalm(костыль, конечно, но что есть).

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

    1. Накладные расходы чтобы прописать тип который в голове и так должен быть — серьёзно?
    2. Типы нужно поддерживать и в динамическом языке. Поддерживать, проверяя что код рабочий и типы те что ожидаются, и в статически-типизированном языке эту работу за вас сделает компилятор.

    Spoiler header
    Ну и вообще, есть языки со статической типизацией, с весьма хорошим автовыводом типов, таким что большую часть их объявлений можно стереть. Спойлер — так никто не делает, ибо незачем.
  • Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
    +1
    Интересно, сможем ли мы зайти ещё дальше, и повсеместно взяться за формальную верификацию программного обеспечения?

    Сможем, когда придёт время:
    «Formal methods will never have a significant impact until they can be used by people that don’t understand them» (с) Types And Programming Languages
  • Пора на свалку
    0
    Композиция? А в шарпе для неё есть такой же сахар, как в го, когда компилятор сам ищет, к какому классу относится метод?

    Лучше. В C# есть делегаты и явные интерфейсы.

    Да и вообще голанг весьма бедный язык на «сахар».
  • Спор о первом языке программирования: окончательное решение
    0
    Что еще нужно сделать мелкософту чтобы C# не считали завязанным на платформу… эхх

    Если вот это: github.com/dotnet/wpf/issues/48 сделают — сразу начну считать его лучшим кроссплатформенным языком для десктоп-приложений :)
  • Spiral: высокопроизводительный PHP/Go фреймворк
    +1
    Судя по всему в следующем раунде мы так же увидим swoft (фреймворк на основе swoole). Его код уже присутствует в бенчмарке. Будем ждать пересчёта. Будет на кого ориентироваться.

    Стоит упомянуть, что Swoft/Swoole асинхронные, в отличие от, так что в реальных приложениях при должном использовании они всегда будут быстрее.
  • Spiral: высокопроизводительный PHP/Go фреймворк
    0
    В приложении на spiral — нет, мы изначально разработали архитектуру для работы в режиме демона. Насчет существующего приложения не скажу, зависит от фреймфорка и вашего кода.

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

    Но я бы сказал что писать приложения которые не готовы жить в формате демона и полагаются на перезапуск на каждый запрос — не очень хороший тон в принципе.
  • Spiral: высокопроизводительный PHP/Go фреймворк
    +3
    Не понятно, за счет чего возникает «хороший» прирост производительности. Особенно если добавить это в существующее приложение на, допустим, laravel.

    За счёт того что не нужно инициализировать всё приложение, зависимости, сервисы и т.п. на каждый запрос, работа идёт в скрипте-демоне.
    Конечно, неэффективный код приложения, если таковой есть, не особо ускорится, ну и нужно будет учитывать при разработке, что процесс после запроса не завершится и не почистит всё за собой.
  • Spiral: высокопроизводительный PHP/Go фреймворк
    +2
    почему там нужно использовать интеграцию с го и не хватит просто php или питона, например.

    Если вопрос в принципе про использование сервера приложений roadrunner, он убирает оверхед на создание инстанса приложения на каждый запрос, что даёт хороший буст производительности, и легко добавляется даже в уже существующие приложения, в т.ч. на Symfony/Laravel.
  • Spiral: высокопроизводительный PHP/Go фреймворк
    +4
    Мне непонятно, почему нет тестов чистых golang фреймворков? Я просто сильно сомневаюсь, что скрестив гепарда с улиткой вы выиграете в производительности у гепарда.

    Вряд ли у ребят есть цель обогнать golang по производительности
  • RBK.money выпустила первый в мире open-source платежный процессинг — творим будущее вместе
    +8
    Erlang...

    «Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang.» © Десятое правило Гринспена
  • Собеседование здорового человека
    +1
    Тут скорее о том, что приходишь на собес, тебе «продают» позицию рассказами «сейчас у нас легаси, но мы всё обновим, на микросервисы разобъём, тестами покроем», принимаешь офер, но ничего особо не меняется. Или меняется, но так что лучше бы не менялось.

    Если это те же люди что и написали всё существующее «легаси» — скорее всего, ничего хорошего по технической части ждать не стоит.
    Как могут люди, не сумевшие качественно написать монолит, построить распределённую систему?
  • Инструменты Domain Driven Design
    +2
    Единственная здравая мысль в статье — что DDD не про технические детали, а общение с бизнесом, а далее всё скатилось и пошла типичная подмена понятий.
    DDD != архитектура, DDD не учит писать поддерживаемый с технической точки зрения код.

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

    Под видом DDD делать агрегаты и сущности data-классами(то есть анемичную модель) — серьёзно?

    Здесь мы указываем задачу взять в пакете services класс, поместить в него три mappers, проинициализировать объект Stories и отдать нам.

    Я правильно понимаю, что по мнению автора, это понятная для менеджеров без технической экспертизы фраза(единый язык)?
  • PHP-Дайджест № 175 (25 февраля – 10 марта 2020)
    +15
    Интересно, те кто минусуют считают всякое такое:
    Spoiler header
    $hook['pre_controller'] = array(
            'class'    => 'MyClass',
            'function' => 'Myfunction',
            'filename' => 'Myclass.php',
            'filepath' => 'hooks',
            'params'   => array('beer', 'wine', 'snacks')
    );


    Spoiler header
    $this->load->helper('html');
    echo heading('Welcome!', 3, 'class="pink"');
    


    Spoiler header
    public function create()
    {
        helper('form');
        $model = new NewsModel();
    
        if (! $this->validate([
            'title' => 'required|min_length[3]|max_length[255]',
            'body'  => 'required'
        ]))
        {
            echo view('templates/header', ['title' => 'Create a news item']);
            echo view('news/create');
            echo view('templates/footer');
    
        }
        else
        {
            $model->save([
                'title' => $this->request->getVar('title'),
                'slug'  => url_title($this->request->getVar('title')),
                'body'  => $this->request->getVar('body'),
            ]);
            echo view('news/success');
        }
    }


    Spoiler header
    // Create a new class manually
    $userModel = new App\Models\UserModel();
    
    // Create a new class with the model function
    $userModel = model('App\Models\UserModel', false);
    
    // Create a shared instance of the model
    $userModel = model('App\Models\UserModel');
    
    // Create shared instance with a supplied database connection
    // When no namespace is given, it will search through all namespaces
    // the system knows about and attempt to located the UserModel class.
    $db = db_connect('custom');
    $userModel = model('UserModel', true, $db);


    Вот такое в «моделях»:
    Spoiler header
    public function insert_entry()
            {
                    $this->title    = $_POST['title']; // please read the below note
                    $this->content  = $_POST['content'];
                    $this->date     = time();
    
                    $this->db->insert('entries', $this);
            }


    Нормальным кодом в 2020?
    Это, если что, прям из документации codeigniter, и в таком стиле там всё, а не особо неудачные модули.

    Или что «ивенты» с «приоритетами» от симфони лучше явной цепочки миддлварь?
  • PHP-Дайджест № 175 (25 февраля – 10 марта 2020)
    +11
    CodeIgniter 4.0 — Спустя 5 лет разработки вышла новая версия фреймворка. Переписан с нуля, но всё так же в виде единого пакета. Работает на PHP 7.2+, реализованы PSR-1,3,4.

    Какой-то «привет из 2008», и больше похоже на пет-проект начинающего разработчика, чем что-то, что можно использовать в своих проектах.
    Всё на статических хелперах, наследовании, protected-полях, массивах, DI даже не пахнет.

    Из интересного сейчас есть Laminas, в частности, Mezzio(бывш. Expressive), с миддлварами из коробки и без http-kernel с его противными «ивентами».
    Но контейнер хочется от Symfony, потому, кажется, проще из неё выпилить http-kernel и впилить миддлвари, чем в laminas нужный контейнер.
  • Принцип подстановки Лисков
    0
    На геттеры/сеттеры давно пора начать крестовый(++) поход! OOP VULT!

    А в самой лишь войне против них не много смысла. Если воинственно отстаивать их «ненужность», вы будете либо вызывать презрение и недоверие, либо просто один карго культ замените другим.

    Нужно развивать понимание, а не сеять смуту.
  • Принцип подстановки Лисков
    0
    Проблема, думаю, в том, что у людей после нынешних статей «про ООП» в голове не объекты с поведением, а мутабельные структурки данных(поле+геттер+сеттер), которые меняют отдельные процедуры.
  • Принцип подстановки Лисков
    +1
    Для меня наследование — один способов моделирования отношений между сущностями предметной области и moderator extends user выглядит нормально на первый взгляд, если и то, и другое сущности предметной области.

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

    Во первых, если есть какой-то единый класс User в проекте — очень часто(из того что я видел/узнавал/писал) он с запахом, особенно когда кто-то пытается моделировать User'ом живого пользователя из реального мира, и кладёт туда всё, что с этим человеком связано, и логины с паролями, и профиль с форума, и банковские аккаунты, получая в итоге god-object на 100 полей(да и то чаще просто огромную анемичную модель с геттерами-сеттерами т.к. на этом месте люди разочаровываются в рич-моделях, а декомпозировать как-то не принято, не учат).
    Думаю понятно что при таком раскладе уже пора решать проблемы, а не множить наследованием.

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

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

    Я пока что считаю, что использование наследования это исключительно техническая деталь реализации, которая не должна выбираться только ради какой-то схожести с реальным миром. И с технической точки зрения штука эта — весьма опасная.
  • Принцип подстановки Лисков
    0
    Хм. Да, вы правы.

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

    А если пытаться спроецировать какие-то отношения из-реального мира на иерархии наследования(а-ля moderator extends user, или фигуры с геттерами, как выше пытаются) — то такого моделирования уж точно не нужно.