| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Шустрый Программист vs ОО Архитектор |
| Автор: niasilil 16.7.2007, 06:29 | ||
Stampede в одной из соседних тем писал
А как же принцип "program to an interface"? Писать ли интерфейс для каждого класса или экономить время? Утрирую, конечно. Но как поступаете вы? |
| Автор: Stampede 16.7.2007, 07:01 |
| Тут на самом деле нет противоречия. Во-первых, далеко не все подлежит "интерфейсению". Например, классы типа бинов, в которых больше данных, чем логики, вряд ли есть смысл дополнительно описывать интерфейсом. Во-вторых, когда прототип некой функциональной сущности написан, проверен и работает, выделить эту функциональность и оформить ее в виде интерфейса, при нынешних-то средствах рефакторинго - дело ровно двух тыков мышкой. В общем, не вижу, ради чего поднимать шум  |
| Автор: y3u 16.7.2007, 07:21 |
| интерфейсы нужны тлоько на программных и логических стыках, когда надо соединить два функциональных или логических модуля через некий АПИ, чтобы, если что, АПИ остался, а реализация этого АПИ могла бы меняться. Т.е. если предполагается или есть большая вероятность изменения, мигрирования, логики или бизнеспроцесса с точки зрения алгоритмики или, если хотите, дальнейшей оптимизации кода, то надо делать интерфейс. ИМХО. Не стоит подходить к этому процессу фанатично. Во сем должна быть мера. |
| Автор: niasilil 16.7.2007, 07:32 | ||
То ж не шум, просто сидим вот, полуношничаем. Дело ж не в том как писать интерфейс (ясен пень что сначала класс, потом интерфейс по классу), а в том писать ли его во время написания классов? Вот положил все интерфейсы в одну папку, имплементейшнс в другую и строчи себе дальше. А можно написать программу, потом стукнуло по голове - надо новую функциональность - давай рефакторить, выделять интерфейсы. Чем дальше, тем сложнее рефакторить. |
| Автор: powerOn 16.7.2007, 13:08 | ||||
это почему это? Я вот сначала интерфейсы катаю, потом только классы. Т.е. сначала предполагаю "что" должно быть, а потом "как" должно работать. Хотя может это только я так поступаю. 
всецело согласен. |
| Автор: nornad 16.7.2007, 15:46 | ||||
Потому и сложнее, что структура программы не была продумана изначально. Если бы первым делом думали, какие есть логические блоки, что и как должно взаимодействовать друг с другом и выделили бы это в интерфейсы - рефакторить стало бы явно проще.
Присоединяюсь. |
| Автор: nornad 16.7.2007, 18:24 | ||
Кстати, если "потом стукнуло" и нужна "новая функциональность" - это уже ен рефакторинг, а доработка. Рефакторинг подразумевает изменение внутреннего содержания кода без изменения функциональности. |
| Автор: COVD 16.7.2007, 22:25 | ||
Так это вроде и есть реализация принципа "program to an interface". Наверное, только так и можно, если над проектом работают больше одного человека. А некоторые рекомендует начинать с тестов. У совершенства нет пределов. |
| Автор: niasilil 17.7.2007, 00:31 |
| Что первично яйцо или курица зависит от того имею ли я представление о том что получится в результате. Если все продумано, то пишу интерфейс, если нет, то класс. Но это не так уж принципиально. Вопрос ведь был немного в другом. Вот в теме JSP, откуда я выдрал цитату, писали классы. Я бы не думая в паре мест поставил интерфеймы, так на всякий случай - если вдруг расширить придется, и тут уже на тебе, все готовенько. Поставил фабрику и заменяй что хошь. И фраза про Шустрого программиста меня сильно удивила. В ней есть железная логика, но она немного отличается от другой логики построить заранее гибкое приложение. Вобщем, как в том случае с exceptions - кто то пытается обходиться совсем без них, кто то пользует направо и налево, лучше всего середина. Только вот хз где эта серидина для каждого из нас. Спасибо всем за обсуждение. |
| Автор: AndreQ 19.7.2007, 15:20 |
| Интересная тема, с которой у меня большие проблемы. Точнее проблемы с необъятным проектированием. Поясню. Я вроде умею придумавать нормальную, в плане поддержки и удобства использования, арх-ру для небольших программ, или для некоторой новой функ-сти большой программы, т.е. для конкретной части, направленной на решение чего-то одного, законченного. Но когда я недавно стал делать достаточно стандартное web-приложение - веб-интерфейс к веб-приложению, принимаюшее тучу параметров, я понимаю что ни хрена не шарю в проектировании... У меня просто глаза разбегаются - что должно оставаться в Java коде, что передавать в Velocity, как генерить JavaScript? Где располагать параметры и констаны, которые должны быть доступны и для отдельных классов, и для Velocity- шаблона. Когда пишу java классы, то всегда надо держать в голове: а как из JavaScript-а придут параметры, что делать если опция не указана, и вобще, то ли я пишу если потом поступит новое требование и надо будет менять парсер, обработку параметрв... Это просто мука, я такого ранее делал, я уже ненавижу веб-программирование. За такую многослойность и за то что нужно держать весь проект и каждую деталь в голове про сами Java классы, про формат параметров, про JAva-скрипт, про Velocity и его контекст... Блин, я не могу даже успокоится. В одном месте меняется что-то - и можно с уверенностью сказать что проект не запуститься, так как оно всё связано! P.S. + постоянные приколы с HTML и браузерами... |
| Автор: AntonSaburov 19.7.2007, 15:35 |
| Такого рода проблемы обычно решаются четким разделением не только на слои - данные, бизнес-логика, представление. Я еще стараюсь делить "вертикально" - не знаю как еще сформулировать. Т.е. каждый Use Case должен быть по возможности независим от других в плане реализации - есть действие пользователя, есть логика обработки и в конце сохранение данных. Кроме этого можно разработать систему передачи параметров - мы решили,что нам удобнее XML достаточно простой структуры в котором прописаны пары имя_параметра - значение_параметра Стандартный формирователь XML на клиенте и такой же стандартный парсер на сервере. Вообщем внешний вид серверную часть не волнует вообще. Бизнес логика опирается на DAO - используем Hibernate. Вообщем достаточно все спокойно и понятно. Дргуой вопрос, что нужна нормальная дока и юнит-тесты. Сперва это замедляет разработку, но зато поддержка облегчается в разы |
| Автор: AndreQ 19.7.2007, 17:47 | ||
Генерировать XML JavaScript-ом на странице? И как его передавать? Может я отстал от технологий??.. Но я знаю только про GET и POST, и как параметры формы передаються на сервер стандартным способом.. |
| Автор: AntonSaburov 19.7.2007, 17:55 | ||
Все правильно - POST и есть. Но перед этим в функцию передается массив пар имя-значение. Там формируется простая XML-строка
И уже готовая строка идет на сервер - в какой-нибудь сервлет. Вообщем-то и все. Дальше XML обрабатыватеся и получается обычный Map, который уже поступает в команду - все. |
