Здравствуйте, уважаемые.

MVC - штука, конечно, клевая. Но уж больно репу надо чесать перед очередной писаниной. Вот и теперь у меня есть объект 



Как-то w1nd заявил, что люди перегибают палку при проектировке. Что ж согласен, но надо набить шишки.

Добавлено через 8 минут и 48 секунд
PS. "другой механизм" имеется ввиду объект отвечающий за загрузку данных с сервера. В этой теме я бы хотел обсудить частный случай и заморочки проектировки в целом. Помню хорошую пословицу "We'll cross that bridge, when we come to it". так вот  после того как я услышал эту мудрость, меня всё время грызут сомнения, стоит ли сделать монолит, или стремиться к гибкости. Внутреннее противоборство: 
- Сделаем побыстрому и не будем париться.
- Ага, а потом когда придет время расширять, будем всё разхе..чивать и писать всё за ново.
- We'll cross that bridge, when we come to it
... (дальше или находятся аргументы или останавливаемся на мостах)

Platon
Прямо-таки философский вопрос... Недавно прочел, и в целом согласен: что самая большая ошибка которую совершает человек, когда, начиная делать что-нибудь, тут же начинает раздумывать: как это сделать лучше? А ведь главный закон: нельзя улучшить то, что не делаешь.
Любая архитектура с целью повысить гибкость, которая задерживает в движении к цели, опасна. Ты начинаешь улучшать то, чего у тебя еще нет. То есть ничего. И отдаляешся от момента получения результата, первой версии конечного продукта. Архитектурные решения, должны позволить быстро и без потерь прийти к цели, а большая гибкость, должна добавляться только тогда, когда и если эта гибкость вправду стала необходима (читай, без неё стало невозможно что-то сделать). То, что сейчас стало модно все делать гибким, всякие JPA и т.д. и т.п. -- ничего не значит. Не каждый проект превращается в JBoss. Все эти гибкие промежуточные слои и интеграционные заморочики зачастую сочиняют люди, которые ни одного проекта не делали от начала и до конца целиком. Пишут себе свой слой, очень отдаленно представляя насколько он реально удобен и полезен в использовании. Им и не надо об этом думать. Продвижением занимается другой отдел 
Не останавливайся на том как именно ты сейчас получишь этих childeren'ов -- иди дальше. Что-то переделывать все равно прийдется, не надо пытаться писать код на века. Мой совет опасен, конечно, для начинающих разработчиков, его могут неправильно понять и начать колбасить по-индусски. Но ты и многие другие завсегдатаи форума, я уверен, легко поймут какую именно мысль я попытался выразить.

Maksym, аргументированный и жизнеутверждающий совет. Видимо поэтому я не могу принять ни Spring, ни Struts, когда средний проект, от JPA избавляюсь.

Не согласен с Maksym кое в чём. С одной стороны - да, следует делать только то, что понадобится, не извращаясь. С другой стороны - если я при проектировании точно знаю, что у компонента, работающего с сервером, будет множество потребителей - я ещё на стадии проектирования буду предусматривать соответствующую возможность. НО. Если дело касается системного ПО (а к этой категории как раз относятся сервера) следует предусмотреть все возможные сценарии работы с данным компонентом.

Что касается примера - если доступ к тем же данным напрямую (без GTModel) нужен - стоит обособить этот код, если нет - не стоит (если понадобится в дальнейшем - модификация никому не повредит). Правда, в этом случае стоит подумать о том, что GModel - ни разу не говорящее о сути выполняемых действий название.

w1nd, примерно в этом ключе и думаю ^_^
На памяти есть проект PlayCQ, так там я на стадии проектировки заложил возможность разных сетевых протоколов (в частности реализовывал на голых сокетах и с помощью библиотеки Apache MINA) и возможность создавать разнообразный графический интерфейс. Согласен, т.е. я поставил целью гибкость 2-х элементов системы и на этапе проектировки держал это в голове.



Очень мутно представляю. Как это "доступ напряммую (без GTModel)"? Я данные специально и обособил в GTModel. 


Я видимо по-русски плохо понимаю, о чем говорит это предложение? Что GTModel - не "говорящая фамилия"?

В данном случае это (поддержка различных сценариев) и есть необходимый результат. Я в общем то имел ввиду всего лишь то, что желательно помнить о тонкой грани между гибкостью архитектуры, как средством решения насущных проблем, и гибкостью ради гибкости.

Именно так.

Вернемся к нашим баранам. Перечитывая тему "JSP - c чего начать" я наткнулся на похожую ситуацию:
    batigual: Я обычно решаю эту проблему так: создаю класс Config, а в нем - внутренний класс ConfigReader. В случае изменения формата хранения - будет правиться ConfigReader, который никем, кроме самого Config не используется --> хорошо локализован.
    Stampede: Вот, обрати внимание, diablero - batigoal приводит очень хороший пример разбиения компонентов по границе функциональной ответственности, причем имено в технике ООП, специфической для Java - с использованием внутрених классов. Это и есть то, что называется "слабо связанными" (loosely coupled) компонентами.

Так получается, мне всё-таки в Java стиле надо загрузку данных писать в отдельный класс (разделение по функциональности). И ввиду этого получается следующая патовая ситуация. Можно дойти до такой крайности, что писать класс с 1-м публичным методом, все остальные, служебные для этого класса, закрытыми.

Это сообщение отредактировал(а) Platon - 20.5.2008, 14:40

Они сделали два конфигридера:


Ты же не будешь делать в конфиге два метода - для properties & for xml? А тут сразу для двух форматов.

Эээх, не успел. Осознал свою ошибку. 
Самое прикольное, я вспомнил от куда у меня в мудростях появилась поговорка "We'll cross that bridge...", и интересно, что тут тоже проблема не перегнуть палку раньше времени.

Это сообщение отредактировал(а) Platon - 20.5.2008, 14:43