Я не оправдываю стиль написания кода ББ-шных разработчиков. Они, видимо, попали в частый соблазн - когда хорошо спроектируешь интерфейсы, то думаешь, что "а похрен, что там и как внутри у этого кирпича будет". Не говоря про то, что идеи, бродившие в начале 90-х, были полностью "зациклены" на двоичной компонентности, при сокрытии исходного кода.
Что есть в корне не верно. Открытый компонент можно сделать на порядок проще, просто за счет того, что гибкость его обеспечивается не наворачиванием фич на все случаи жизни, а самой открытостью исходника. Кроме того, я пока не видел компонента, интерфейсы/абстракции которого не протекали бы. Ибо создатель никогда не знает в каких именно условиях это дело будут применять.
Понять что именно и как именно работает в компоненте, отладить его, намного проще когда есть исходники. Помню как сильно, в свое время, мне помогло то, что VCL поставлялся в исходниках. Компонентина поставляемая в бинарниках с любой документацией всегда проигрывает компоненте с открытыми исходниками (при прочих равных).
Я сам стремлюсь писать ясный и хорошо декомпонированный код, но обычно этого достигаю "расслаиванием" функционала по многим объектам-кубикам. Т.е. то, что тут уложено в один модуль TextModels, я бы расслоил слоя на три минимум.
Что ухудшило бы, возможно, его читабельность :-)
Как только расслаиваем, сразу появляется пачка проблем:
1) у нас появляется туча связей которые нужно выявить (тот кто смотрит в код первый раз предполагает что каждый может быть связан с каждым, ему нужно провести большую работу чтобы вычленить группы модулей которые сильнее связаны друг с другом нежели со всеми остальными).
2) возникает проблема правильного именования этих слоев (чтобы каждый понял что к чему).
3) Там где у нас раньше было 3 модуля, теперь у нас 15ть. Часто так банально не удобно работать.
НО: я таки однозначно придерживаюсь принципа - "найди способ выразить мысль ясно напрямую кодом без комментариев".
А не выйдет. То есть выйдет конечно, но только с теми читателями кода, которые на той же волне что и ты. Как только у человека читающего восприятие чуть начинает отличаться от человека пишущего, так все, мысль кодом без комментов не выражается, качество восприятия становится сильно хуже. Причем таковым человеком читающий может оказаться тот, кто был лет 5 назад человеком пишущим этот код.
Собственно комменты нужны для того, чтобы настроить читающего на нужную волну. Одна строчка комментария может помочь посмотреть на код под правильным углом и сэкономит часы и дни времени.
