Посоветуйте литературу по правилам, нормам именования пакетов и классов

[Develar]

Посоветуйте литературу по правилам, нормам именования пакетов и классов

Кто-нибудь может порекомендовать литературу по правилам, нормам именования пакетов и классов? В контексте не PHP, где соображения производительности и недостатки эмуляции могут не позволить нам в полной мере раскидать все, а в общем. Половину кода сейчас пишу на AS, этот GUI заставляет иметь кучу хитрой логики и массу классов как результат. Сам flex в целом может служить примером, но, скажем, flash.display.Loader, а пакет mx.modules имеет ModuleLoader.

 

[Crazy]

Вопрос для инициации процесса мышления: является ли имя flash.display.Loader более удачным и защищенным, чем flash_display_Loader?

 

[Develar]

Когда мы работаем в неком контексте, мы импортируем нужное нам, нам не нужно знать лишнего, о каком-то flash_display, нам нужно просто Loader. В коде мы используем не полностью квалифицированное имя класса Loader. Это лучше, чем путаться с flash_display_Loader и при чтении кода сначала прочитывать путь пакета, который и так уже загружен в нашу голову. Не говоря уже о том, что когда мы будем перемещать класс по иерархии, само имя класса мы менять не будем.

С другой стороны, должны ли мы относительное имя класса иметь как Loader, или как DisplayLoader.

-~{}~ 25.05.07 17:04:

Если мы имеем mx.resources.ResourceBundle, то назвать просто Bundle глупо - непонятно что такое Bundle. Имеем mx.managers.PopUpManager, тоже все понятно - должны именно PopUpManager, потому что просто PopUp это явно не то. А если develar.neocms.contentObjects.managers.Remover? Работая в контексте contentObjects я понимаю, что Remover явно занимается уничтожением contentObject - или я должен назвать этот класс ContentObjectRemoverManager || ObjectRemoverManager || RemoverManager ?

 

[StUV]

Когда мы работаем в неком контексте

имхо, ключевая фраза.
если ты "в некоем контексте" не можешь нормально читать код без явных квалификаторов неймспейсов - то или не открывай контекст, или делай длинные имена.

 

[Develar]

Меня как раз раздражает, что свойство содержащее владельца контекстного меню в ContextMenuEvent называется contextMenuOwner, хотя по контексту и так ясно кого owner. Я сейчас пишу просто Remover, просто StatusManager. А не ObjectRemover. У Макконелла в "совершенном коде" про пакеты и наследовании некой приставки от пакета к имени класса не сказано.
StUV
Если я правильно понял вашу позицию, то вы одобряете название класса Remover, а не ObjectRemoverManager? Если кто-то вдруг начнет работать с двумя классами, имеющими одно имя, но из разных пакетов - это ошибка в архитектуре системы.

 

[StUV]

это ошибка в архитектуре системы

скорее - следствие кривизны рук программиста/кодера
в крупном проекте в разных неймспейсах может быть дох классов с одинаковыми именами - это нормально
точнее, от этого ни куда не денешься

-~{}~ 25.05.07 18:25:

ессно, если используются оба класса - нужно явно прописывать неймспейс, а objectRemoverManager - может быть именем локальной переменной/экземпляра.

 

[fisher]

ну вы сами и ответили - не нужны книги, есть единственной верный подход к сабжу. берёте ВашеСуперскиВыглядещееИмяОбъекта. бьёте на части. по каждой части задаем вопрос избыточности - а без этого куска может и так всё понятно.