Согласен с gl00mie, что в плане работы с наследованием и прозрачности данного кода в Аксапте плохо, да и вообще в данном подходе. Так что вкупе с соображениями относительной "видимости" кода, видимо, этим и вызваны подобные монстры типа LedgerJournalEngine. Честно говоря, сам зачастую колеблюсь в вариантах реализации - написать некий единый класс с методами if тип одно - вызываем метод один, если тип - другое, вызываем метод 2 и т.д, либо же создать дерево классов-наследников. Кстати, прослеживающаяся тенденция к последовательному приближению к классическим принципам ООП с ростом версий Аскапты есть. И SettleNow - один из самых примечательных примеров (скажу, как знаток оного метода еще с 2.5
). В 4ке и тем более, в 2009, довольно много классов было перестроено в подобном стиле. Но, увы - средства работы с подобными иерархиями классов остались на том же уровне.
Чего стоило бы хотя бы в функции контекстного меню "Просмотр определения" при наличии построенных перекрестных ссылок, вываливать список классов-предков и/или классов-наследников текущего (если они есть), в которых перекрыт данный метод с возможностью выбора, куда переходить. В общем, каменный век.
Я сейчас столкнулся с таким набором классов порядка 15 штук, глубиной наследования ~4, так что наболело. Написано в лучшем стиле ООП, но более-менее целостное впечатление удалось получить далеко не сразу (кстати, в процессе выполнения/отладки самое оно смотреть как работает). Вообще, скажу я вам, проблемы с ООП в Аксапте две.
1. Неразвитость инструментальных средств разработки.
2. Сложность соблюдения концепций в контексте существующего кода.
По второму пункту я имею в виду, что если уж в стандарте, к примеру, напрогано таким образом, что требование изолированности и статичности интерфейсов и реализаций объектов не соблюдается (т.е. если одна переменная инициализируется в одном месте, другая - в другом,в третьем и иногда в четвертом), хотя можно было бы упорядочить и как-то собрать, то соблюдать формальные требования так сказать Best Practices ООП становится слишком затратно по потерям времени и усилий, и, по сути, никому не нужно, кроме самих разработчиков.
Что же касается комментариев - я сторонник некоего баланса между самодокументирующимся кодом и, в сложных методах/классах - заголовка с описанным общим алгоритмом работы метода и по ходу кода, ссылками на пункты из этого описания. Ну, и опять же, в "тонких" местах, где надо обратить внимание на некую особенность реализации - комментарий тоже считаю обязательным. И в "авторских" комментариях считаю нужным коротко описывать суть проекта-модификации.