Stampede в одной из соседних тем писал 
А как же принцип "program to an interface"? 
Писать ли интерфейс для каждого класса или экономить время? Утрирую, конечно. Но как поступаете вы? 

Это сообщение отредактировал(а) niasilil - 16.7.2007, 06:36

Тут на самом деле нет противоречия.

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

Во-вторых, когда прототип некой функциональной сущности написан, проверен и работает, выделить эту функциональность и оформить ее в виде интерфейса, при нынешних-то средствах рефакторинго - дело ровно двух тыков мышкой.

В общем, не вижу, ради чего поднимать шум 

интерфейсы нужны тлоько на программных и логических стыках, когда надо соединить два функциональных или логических модуля через некий АПИ, чтобы, если что, АПИ остался, а реализация этого АПИ могла бы меняться. Т.е. если предполагается или есть большая вероятность изменения, мигрирования, логики или бизнеспроцесса с точки зрения алгоритмики или, если хотите, дальнейшей оптимизации кода, то надо делать интерфейс. ИМХО.
Не стоит подходить к этому процессу фанатично. Во сем должна быть мера.

То ж не шум, просто сидим вот, полуношничаем. 

Дело ж не в том как писать интерфейс (ясен пень что сначала класс, потом интерфейс по классу), а в том писать ли его во время написания классов? Вот положил все интерфейсы в одну папку, имплементейшнс в другую и строчи себе дальше. А можно написать программу, потом стукнуло по голове - надо новую функциональность - давай рефакторить, выделять интерфейсы. Чем дальше, тем сложнее рефакторить. 

это почему это? Я вот сначала интерфейсы катаю, потом только классы. Т.е. сначала предполагаю "что" должно быть, а потом "как" должно работать. Хотя может это только я так поступаю.   


всецело согласен.

Это сообщение отредактировал(а) powerOn - 16.7.2007, 13:09

Потому и сложнее, что структура программы не была продумана изначально. Если бы первым делом думали, какие есть логические блоки, что и как должно взаимодействовать друг с другом и выделили бы это в интерфейсы - рефакторить стало бы явно проще.

Присоединяюсь. 

Кстати, если "потом стукнуло" и нужна "новая функциональность" - это уже ен рефакторинг, а доработка. Рефакторинг подразумевает изменение внутреннего содержания кода без изменения функциональности.

Так это вроде и есть реализация принципа "program to an interface". Наверное, только так и можно, если над проектом работают больше одного человека. А некоторые рекомендует начинать с тестов. У совершенства нет пределов. 
 

Что первично яйцо или курица зависит от того имею ли я представление о том что получится в результате. Если все продумано, то пишу интерфейс, если нет, то класс. Но это не так уж принципиально. Вопрос ведь был немного в другом. Вот в теме JSP, откуда я выдрал цитату, писали классы. Я бы не думая в паре мест поставил интерфеймы, так на всякий случай -  если вдруг расширить придется, и тут уже на тебе, все готовенько. Поставил фабрику и заменяй что хошь. И фраза про Шустрого программиста меня сильно удивила. В ней есть железная логика, но она немного отличается от другой логики построить заранее гибкое приложение. Вобщем, как в том случае с exceptions - кто то пытается обходиться совсем без них, кто то пользует направо и налево, лучше всего середина. Только вот хз где эта серидина для каждого из нас. 
Спасибо всем за обсуждение. 

Интересная тема, с которой у меня большие проблемы.

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

Но когда я недавно стал делать достаточно стандартное web-приложение - веб-интерфейс к веб-приложению,
принимаюшее тучу параметров, я понимаю что ни хрена не шарю в проектировании...

У меня просто глаза разбегаются - что должно оставаться в Java коде, что передавать в Velocity, как генерить JavaScript?
Где располагать параметры и констаны, которые должны быть доступны и для отдельных классов, и для Velocity- шаблона.
Когда пишу java классы, то всегда надо держать в голове: а как из JavaScript-а придут параметры, что делать если опция не
указана, и вобще, то ли я пишу если потом поступит новое требование и надо будет менять парсер, обработку параметрв...

Это просто мука, я такого ранее делал, я уже ненавижу веб-программирование.  За такую многослойность и за то что нужно
держать весь проект и каждую деталь в голове про сами Java классы, про формат параметров, про JAva-скрипт, про Velocity и
его контекст...

Блин, я не могу даже успокоится.  В одном месте меняется что-то - и можно с уверенностью сказать что проект не запуститься,
так как оно всё связано!

P.S. + постоянные приколы с HTML и браузерами...

Такого рода проблемы обычно решаются четким разделением не только на слои - данные, бизнес-логика, представление.
Я еще стараюсь делить "вертикально" - не знаю как еще сформулировать.
Т.е. каждый Use Case должен быть по возможности независим от других в плане реализации - есть действие пользователя, есть логика обработки и в конце сохранение данных.

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

Стандартный формирователь XML на клиенте и такой же стандартный парсер на сервере. Вообщем внешний вид серверную часть не волнует вообще. Бизнес логика опирается на DAO - используем Hibernate.

Вообщем достаточно все спокойно и понятно. Дргуой вопрос, что нужна нормальная дока и юнит-тесты. Сперва это замедляет разработку, но зато поддержка облегчается в разы

Генерировать XML JavaScript-ом на странице?  И как его передавать?

Может я отстал от технологий??.. Но я знаю только про GET и POST, и как параметры формы передаються на сервер стандартным способом..



Это сообщение отредактировал(а) AndreQ - 19.7.2007, 17:48

Все правильно - POST и есть. Но перед этим в функцию передается массив пар имя-значение. Там формируется простая XML-строка



И уже готовая строка идет на сервер - в какой-нибудь сервлет. Вообщем-то и все. Дальше XML обрабатыватеся и получается обычный Map, который уже поступает в команду - все.