Показать сообщение отдельно
Старый 05.09.2012, 00:50   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Все, что можно отделить и назвать — должно быть отделено и названо.
Я считаю, что здесь нужна мудрость. Ни практика принудительной экстракции всех алгоритмов, ни упаковка кода в один метод не дадут читаемый код сами по себе. Здесь нужно выработать вкус и тонкое чувство наития, подсказывающее, где стоит выделять код, а где нет.
Таким рефакторингом можно заниматься...
Я бы сказал, статье недостает элемента новизны Вместо того, чтобы сперва бросаться в крайности, а потом призывать к мудрости и выработке вкуса "по бразильской системе", можно было бы для начала почитать того же Макконнела - у него в "Совершенном коде" созданию высококачественных методов посвящена целая глава почти на 30 страниц. Затем можно почитать "Рефакторинг..." Фаулера, где тонкому чувству наития противопоставляется расписанная до мелочей "поваренная книга" методов рефакторинга с четким указанием, какой, где, когда и как применять. "Все уже придумано до нас".
Цитата:
Сообщение от mazzy Посмотреть сообщение
стоит отметить, что в аксапте методично применялся такой подход. по крайней мере в базовых классах (например, InventMovement и потомки. например, ledgerjournalengine). и я бы не сказал, что методичное применение такого подхода сильно облегчило жизнь при чтении кода.
Дык, помимо методичности нужна же мудрость! По-моему, InventMovement "слишком много на себя взял": это и механизм параметризации (методы-флажки canBeXX, mustBeXX), и поставщик разнообразных настроек разноски (accountXX, postingXX), и поставщик параметров проводки (transXX), и разного рода бизнес-логика (checkXX, updateXX). Класс должен выполнять четко очерченную роль, а не пытаться делать все и сразу. А LedgerJournalEngine мало того, что пытался заниматься всем подряд (как минимум, смешивал презентационную и бизнес-логику и в 3.0 зачастую не мог работать без ссылки на DS; в 2009-й хоть полегче стало), так еще и является "оберткой" для таблицы строк журналов с кучей полей и потому заведомо обречен на то, что численность его методов будет пропорциональна числу полей в LedgerJournalTrans. Тут уж не до облегчения жизни...