Конвенции кодирования архитектуры Java

]Для меня:[

] [
• ][

  ]Помощник - это фасад, или он кодирует/декодирует определенный формат данных и не имеет состояния между вызовами.[

  ][
] [
• ][

  ]Утилита предназначена для кодирования/декодирования формата или выполнения IO, и если он создает соединения, то часто не поддерживает соединения или держит файлы открытыми между вызовами.[

  ][
] [
• ][

  ]Менеджер похож на Помощника, но имеет состояние между вызовами. [

  ][
] [
• ][

  ]Factory - это класс, который получает или создает, а затем возвращает объект (либо пользовательский, либо API).[

  ][
] [
• ][

  ]Простой и Default часто означает просто базовый класс.[

  ][
] [
• ][

  ]A My "class" (Мой "класс") обычно используется для предполетных идей и примеров кода, хотя иногда он используется в производственном коде, например, для MyApplication и MyView (по сути, для именования синглонов).[

  ][
] [

]Эти имена классов являются де-факто именами. Это значения, которые я создаю и вижу чаще всего, но часто встречаются противоречивые схемы именования и несоответствия. Они не являются формальными именами шаблонов дизайна, и на практике выбор любого из этих имен кажется почти произвольным. Некоторые люди клеймят все свои классы, которые являются потокобезопасными, одним из этих имен и теми, которые не являются таковыми.[

]Часто я также вижу, что имя "Менеджер" присваивается классу, который выполняет функцию, подобную ORM, с объектами или ключами, или объекту, который управляет соединениями в арбитражном порядке. [

][]EDIT[][

]Я вижу приложение, которое построено на фреймворке, как обычно имеющее эти основные объекты: [

] [
• ]Официальный вход/выход из процесса/события, обрабатывающие объект stub[
] [
• ]A (однотонный) приложение (ссылается на иерархическую модель данных и, возможно, на объекты задачи)[
] [
• ]Менеджер баз данных[
] [
• ]Сетевой менеджер[
] [
• ]UI (который ссылается или не ссылается на модель представления в зависимости от по вашему религиозному убеждению)[
] [
• ]Helper/Utility/Factory classes[
] [
• ]Miscript glue code[
] [
• ]Ancillary files[
] [

]Я вижу, что сфокусированность на максимизации контролепригодности и минимизации площади поверхности этих интерфейсов более важна, чем именование пакетов и файлов; Я думаю, что вы должны следовать своему собственному носу для подробного описания поломки и именования вашего проекта. Разбиение кода на разные файлы для целей SCM особенно важно для разделяемых файлов, зависящих от более чем одной пули выше.[

][]EDIT[][

]Я использую в повседневной работе одиночку, flyweight, composite, iterator, memento, наблюдателя, state, strategy. Я использую фасад, прокси, цепочку ответственности между модулями и в коде пользовательского интерфейса. Иногда я использую фабрику, прототип и конструктора в сложных информационных системах, а также шаблон и посетителя, когда система особенно сложна концептуально. Иногда я использую адаптер, мост, фабрику, абстрактную фабрику, декоратора, когда поведение является сложным. Я редко использую интерпретатор и использую медиатор, чтобы помочь мне написать более общий код в определенных случаях. Лично я не люблю называть свои классы в честь GoF, но многие очень рады, это может быть хорошей идеей и я не против практики. Это может быть очень полезно, и если это делает людей счастливыми, и это помогает всем понять, что происходит в конкретном случае, то это здорово.[

]Я просто чувствую, что называть мой объект приложения Singleton, Composite или ChainOfResponsibilityLink (?) не очень хорошо, и что называть мою сеть и код базы данных адаптерами не очень хорошо, поэтому я называю их Менеджерами. И я называю много вещей, которые, возможно, следует называть фасадами в рамках GoF, Helpers или Utilities, потому что я думаю, что это более понятно.[