Можно подробнее? Полностью тему в таком формате все равно раскрыть нереально, но что бы вы сказали про реинициализирующие вызовы молодым разработчикам?
Я до разбора полетов предпочитаю не доводить в принципе.
Именно для этого сделано двойное рецензирование: неформальное — решения задачи перед кодированием (отвергается только явно косячное по дизайну) и формальное — ревью кода после (отвергается опять-таки только явно косячное и неправильно оформленное).
На молодых работает отлично.
Для нашего молодняка требовалось максимально сжатое изложение с конкретными рекомендациями именно по Delphi. В сети подходящего не нашел, пришлось писать самому.
> И чего это вам не понравилось хранение данных в классе и запись в БД ну и некоторые другие функции?
Тем, что мешают читать, использовать, тестировать и модифицировать класс без физической реализации «этих других функций».
> Соответственно и все поведение мы и должны в один класс записать.
Это будет известный антипаттерн «божественный класс» — сложный для чтения, отладки, модификации и повторного использования.
> Допустим у нас есть класс tDoc мы должны описать его сохранение в БД, загрузку из базы, проверку на валидность, объект этого класса — единственное достоверное хранилище данных.
Не должны — для сохранения есть сериализаторы, для проверки — валидаторы и т.п. На собственно документ ложится хранение данных. Остальное вполне реально выделить в отдельные классы.
>Опять же не совсем понятно требование на приватность полей — да в подавляющем большинстве случаев это действительно важное требование, но бывают и исключения…
В Delphi таких исключений не бывает. Хочешь показать снаружи — опиши свойство. С тривиальными геттером и сеттером оно даже по скорости исполнения полю не проиграет.
Принять можно все (зарабатываешь на яве — куда ж ты денешься), такие генерики лучше чем их отсутствие, простоты в автобоксинге нет никакой. Но от всего этого этого ява как рабочий инструмент отнюдь не выигрывает.
Чего еще надо? Нормальных лямбд, замыканий, лаконичности, вывода типов, генериков для типов-значений без побочных эффектов оберток, нормального switch, банального using. Да, можно работать без всего этого, но brainfuck тоже Тьюриг-полон.
Полагаю, что организационные задачи очень даже могут решаться техническими методами, но это должно быть именно решение, а не имитация. Т.е. если в определенную папку можно класть только css, а в другие папки css класть нельзя, то техническое решение должно это обеспечивать при любых действиях пользователя, включая человекопонятные сообщения об ошибках.
«Неинтуитивно» означает «для понимания и правильной формулировки необходимо точное знание неочевидных особенностей инструмента». Это недостаток, вполне преодолимый, но, простите, «возрадоваться» тут нечему.
Упор на строгость языка при наличие неявного боксинга несколько непоследователен, не так ли?
Конечно, плюсы в этом плане хуже многократно (там практически ВСЕ требует точных знаний особенностей реализации), но и ява не без греха.
Ключевое различие именно в этом — каждая рабочая копия в распределенной системе контроля версий является полноценным репозиторием.
Отсюда и все плюшки — высокая скорость операций, меньшие требования к каналам связи, высокая отказоустойчивость, любая топология сети репозиториев, локальные commit/update/checkout.
Минусы тоже есть (они напрямую вытекают из плюсов) — более сложная двухступенчатая система заливки, для поддержки централизации требуются дополнительные технические или организационные меры.
Но если минусы легко преодолеваются обучением и практикой, то плюсы остаются навсегда.
Я полагаю, в будущем принудительно централизованные системы отомрут — они уже сейчас выдерживают конкуренцию с децентрализованными только за счет легаси.
В централизованной системе очень велика зависимость от центрального сервера и низка скорость обмена информацией плюс дорогостоящи прыжки по истории (checkout). В распределенной системе достаточно выживания хотя бы одной рабочей копии — и по ней можно восстановить центральный репозиторий с точностью до последнего pull c него.
Именно для этого сделано двойное рецензирование: неформальное — решения задачи перед кодированием (отвергается только явно косячное по дизайну) и формальное — ревью кода после (отвергается опять-таки только явно косячное и неправильно оформленное).
На молодых работает отлично.
Тем, что мешают читать, использовать, тестировать и модифицировать класс без физической реализации «этих других функций».
> Соответственно и все поведение мы и должны в один класс записать.
Это будет известный антипаттерн «божественный класс» — сложный для чтения, отладки, модификации и повторного использования.
> Допустим у нас есть класс tDoc мы должны описать его сохранение в БД, загрузку из базы, проверку на валидность, объект этого класса — единственное достоверное хранилище данных.
Не должны — для сохранения есть сериализаторы, для проверки — валидаторы и т.п. На собственно документ ложится хранение данных. Остальное вполне реально выделить в отдельные классы.
>Опять же не совсем понятно требование на приватность полей — да в подавляющем большинстве случаев это действительно важное требование, но бывают и исключения…
В Delphi таких исключений не бывает. Хочешь показать снаружи — опиши свойство. С тривиальными геттером и сеттером оно даже по скорости исполнения полю не проиграет.
Чего еще надо? Нормальных лямбд, замыканий, лаконичности, вывода типов, генериков для типов-значений без побочных эффектов оберток, нормального switch, банального using. Да, можно работать без всего этого, но brainfuck тоже Тьюриг-полон.
Упор на строгость языка при наличие неявного боксинга несколько непоследователен, не так ли?
Конечно, плюсы в этом плане хуже многократно (там практически ВСЕ требует точных знаний особенностей реализации), но и ява не без греха.
Отсюда и все плюшки — высокая скорость операций, меньшие требования к каналам связи, высокая отказоустойчивость, любая топология сети репозиториев, локальные commit/update/checkout.
Минусы тоже есть (они напрямую вытекают из плюсов) — более сложная двухступенчатая система заливки, для поддержки централизации требуются дополнительные технические или организационные меры.
Но если минусы легко преодолеваются обучением и практикой, то плюсы остаются навсегда.
Я полагаю, в будущем принудительно централизованные системы отомрут — они уже сейчас выдерживают конкуренцию с децентрализованными только за счет легаси.