Меня больше всего удивила возможность привязать свой код к операции присвоения значения переменным. Пишешь $a=1; а при этом будет выполняться свой обработчик.
Некоторые парадоксы саморазрешаются, если выйти на другой уровень логики — на мета-уровень или эмерджентный уровень.
Например, логика на уровне битов взаимоисключающая — бит может быть равен либо 0, либо 1. Не может быть бита одновременно в состоянии и 0 и 1. А вот на уровне выше, на уровне байтов байтов — 0 и 1 не исключют друг друга, парадокса как бы нет.
Специфика больших проектов в том, что есть зоопарк инструментов, используются старые технологии вперемешку с новыми, никто не видит полной картины и тд и тп. Зачастую непонятен стек вызова. Бывает такое: Нажимаешь на кнопку, она дает ошибку. Начинаешь разбираться, открываешь проект. В проекте кнопки нет. Через день понятно, что она рисуется через WinAPI. Далее она подгружает dll специальным загрузчиком с сервера. Там вызывается COM объект. COM открывает форму, в которой все компоненты получают данные через HTTPS от объектов на сервере. Объекты на сервере вызывают движок ActiveScript, который берет скрипты из базы данных, которые сами берут данные из хранимых процедур, которые возвращают refcursor. На третий день нашел где ошибка, поправил одну строчку.
>общий метод легко переопределяется в новых классах, если это требуется
Если вы знаете что переделывать. А если вам досталось от предыдущих разработчиков сотни пакетов, большинство которых порядка 10 тыс строк кода, процедуры со 120ю параметрами и многое другое, то разобраться сразу затруднительно куда вставлять обработку нового типа.
В моем же варианте кода (пусть не самом лучшем) все места сразу «зазвонят», когда попадется новый тип.
Извините, я не огорчусь, ибо огорчаться нечему. Наоборот, даже интересно пообшаться со знающими людьми. Чем критичнее человек настроен, тем лучше воспринимает сказанное. К сожалению, не могу раскрывать детали происходящего на проекте, а то бы можно было бы обменяться более плодотворными идеями. Удачи
На момент написания статьи я даже не знал, что её кто-то прочитает, поэтому не вкладывался. Если найдет вдохновение, то подкреплю фактами.
Поскольку в таком виде это скорее как антипаттерн для средних и больших проектов
В моем проекте объем примерно 20 лет * 100 чел. Мне доступно примерно 2 Гб кода, примерно 20 млн строк кода. Сколько кода всего в системе сказать не могу. Такие дела
Извините, но предложенный шаблон не решает проблему, которую я поднял без кода, который я привел.
Что касается опыта, можете считать что его нет, но это видимость из-за того, что написал слишком просто для уровня студентов. Сначала надо с простым до конца разобраться.
Не, мне не нужно писать материал, я делюсь своим опытом.
Дело в том, что я работаю на большом проекте и последнее время сталкиваюсь с данной проблемой в разных вариантах. Я даже в статье написал, что проблема возникает в большом проекте, когда один программист что-то делает, а потом другой подхватывают через длительное время.
Возможно истина где-то посередине. Программа как-то сама должна фиксировать списки типов на момент её написания и выдавать ошибки, не всегда, а только когда, к примеру, тестер захочет протестировать в строгом режиме.
Я вижу одно локализованное место для их использования: в коде инстанцирующем конкретные экземпляры объектов (репозиторий / фабрика), которые сопоставляют данные с подходящей реализацией.
Хорошая фабрика, пожалуй, решит задачу, только в неё придется вставить код, похожий приведенный в статье.
if type_id in (1,2,3) then
return new class instance;
else
throw error;
end if;
>Такой путь к хорошему не приведёт, т.к. придётся менять каждый раз менять исходный код при изменении данных.
Что-то вроде этого,… по моему мнению, код должен реагировать на незнакомые типы. Как именно он будет их определять — есть разные варианты. Хардкод, кончено, примитивный, но довольно наглядный.
Нет не предлагаю хардкодить.
Я описал принцип и максимально примитивно его продемострировал.
Собирался написать продолжение кому и как вести эти списки.
Я про другое — если Вы в базу вносите новый тип договора, то как будет реагировать старая программа? Будет тихо с ним работать или всё таки возмутится? Сможете ли вы сразу определить где вносить правки для обработки нового типа?
Например, логика на уровне битов взаимоисключающая — бит может быть равен либо 0, либо 1. Не может быть бита одновременно в состоянии и 0 и 1. А вот на уровне выше, на уровне байтов байтов — 0 и 1 не исключют друг друга, парадокса как бы нет.
Длинная тема на самом деле…
Как это можно загрузить в диаграмму — непонятно.
Если вы знаете что переделывать. А если вам досталось от предыдущих разработчиков сотни пакетов, большинство которых порядка 10 тыс строк кода, процедуры со 120ю параметрами и многое другое, то разобраться сразу затруднительно куда вставлять обработку нового типа.
В моем же варианте кода (пусть не самом лучшем) все места сразу «зазвонят», когда попадется новый тип.
Имеется 2 Гб кода, котрый находится в постоянном развитии. На некоторые модули по 10 человек очереди. Тут нужны навыки человека дождя. :):):)
Хорошо, когда вы знаете что дописывать. В моем проекте из-за большого объема заранее неизвестно что надо дописывать.
На момент написания статьи я даже не знал, что её кто-то прочитает, поэтому не вкладывался. Если найдет вдохновение, то подкреплю фактами.
Поскольку в таком виде это скорее как антипаттерн для средних и больших проектов
В моем проекте объем примерно 20 лет * 100 чел. Мне доступно примерно 2 Гб кода, примерно 20 млн строк кода. Сколько кода всего в системе сказать не могу. Такие дела
Извините, но предложенный шаблон не решает проблему, которую я поднял без кода, который я привел.
Что касается опыта, можете считать что его нет, но это видимость из-за того, что написал слишком просто для уровня студентов. Сначала надо с простым до конца разобраться.
Дело в том, что я работаю на большом проекте и последнее время сталкиваюсь с данной проблемой в разных вариантах. Я даже в статье написал, что проблема возникает в большом проекте, когда один программист что-то делает, а потом другой подхватывают через длительное время.
Возможно истина где-то посередине. Программа как-то сама должна фиксировать списки типов на момент её написания и выдавать ошибки, не всегда, а только когда, к примеру, тестер захочет протестировать в строгом режиме.
Не я против, Вы придираетесь. Чем сильнее придираетесь, тем лучше поймете мысль. Хардкод исключительно для демонстрации
Хорошая фабрика, пожалуй, решит задачу, только в неё придется вставить код, похожий приведенный в статье.
Что-то вроде этого,… по моему мнению, код должен реагировать на незнакомые типы. Как именно он будет их определять — есть разные варианты. Хардкод, кончено, примитивный, но довольно наглядный.
Нет не предлагаю хардкодить.
Я описал принцип и максимально примитивно его продемострировал.
Собирался написать продолжение кому и как вести эти списки.
Я как раз против абстракций.
Надо Вам пару гигабайт кода кинуть, что бы Вы там в чужих абстракциях пару месяцев погуляли.
Главное, что бы принцип был понятен, а использовать assert или еще что-то другое — не важно. От перемены названия мало что меняется.
>Только зачем, если проблема в сообществе DDD давно решена более легкими в поддержке и изящными способами?
приведите пример