Comments 12
Охохох. За старание +1, но за исполнение — жёсткая критика.
Во-первых, в глаза сразу бросается C#-овское оформление кода. В Java не принято именовать интерфейсы с буквы I, а открывающую фигурную скобку после имени класса или метода переносить на следующую строку. Это конвенция, и очень желательно ей следовать.
Во-вторых, когда вы говорите «Самым разумным будет вынести структуру сообщений за пределы кода, чтобы динамически менять их структуру», вы, скажем так, не очень проницательны. В XML имеет смысл выносить те вещи, которые можно менять уже в деплойменте, без перекомпиляции кода. Изменение протокола так или иначе потянет за собой измненение кода, поэтому смысла в ещё одном стопицотом XML-файле смысла мало (не, ну какие-нибудь изотерические случаи, когда это действительно надо, придумать, конечно, можно, но заранее усложнять систему ни разу не comme il faut).
В-третьих, само понятие «клиент для сетевого соединения» очень и очень расплывчиво, и вы рассматриваете только очень-очень узкий пример такого клиента. Для примера: вы можете создавать просто клиент для какого-нибудь Foursquare API, вы можете использовать JSON вместо XML, вы можете работать через REST, когда нет коннектов, сессий и всего прочего — запросы одинарны, а ответы просто парсятся соответсвующими парсерами (JSON, XML, etc.)
Как-то так.
Во-первых, в глаза сразу бросается C#-овское оформление кода. В Java не принято именовать интерфейсы с буквы I, а открывающую фигурную скобку после имени класса или метода переносить на следующую строку. Это конвенция, и очень желательно ей следовать.
Во-вторых, когда вы говорите «Самым разумным будет вынести структуру сообщений за пределы кода, чтобы динамически менять их структуру», вы, скажем так, не очень проницательны. В XML имеет смысл выносить те вещи, которые можно менять уже в деплойменте, без перекомпиляции кода. Изменение протокола так или иначе потянет за собой измненение кода, поэтому смысла в ещё одном стопицотом XML-файле смысла мало (не, ну какие-нибудь изотерические случаи, когда это действительно надо, придумать, конечно, можно, но заранее усложнять систему ни разу не comme il faut).
В-третьих, само понятие «клиент для сетевого соединения» очень и очень расплывчиво, и вы рассматриваете только очень-очень узкий пример такого клиента. Для примера: вы можете создавать просто клиент для какого-нибудь Foursquare API, вы можете использовать JSON вместо XML, вы можете работать через REST, когда нет коннектов, сессий и всего прочего — запросы одинарны, а ответы просто парсятся соответсвующими парсерами (JSON, XML, etc.)
Как-то так.
в глаза сразу бросается C#-овское оформление кода
Каюсь, в свое время приходилось работать с Шарпом. Но был наставлен на путь истинный и начал писать на Java. Не будем разводить холивар на эту тему.
Вы рассматриваете только очень-очень узкий пример такого клиента
Опять же не спорю, данный клиент был создан под конкретную задачу, где никакая из вышеперечисленных технологий не подоходит.
Изменение протокола так или иначе потянет за собой измненение кода
Опять же в моей конкретной задаче структура протокола меняется очень редко, намного чаще меняется структура мессаджей, поэтому я их и вынес в XML.
P.S. Спасиба за критику
Re: «а открывающую фигурную скобку после имени класса или метода переносить на следующую строку. Это конвенция, и очень желательно ей следовать.»
"- Врешь! Нет такого города! (с)"
Нету такого стандарта! Не нужно выдавать желаемое за действительное.
Это тема холивара, а не конвенция.
"- Врешь! Нет такого города! (с)"
Нету такого стандарта! Не нужно выдавать желаемое за действительное.
Это тема холивара, а не конвенция.
www.oracle.com/technetwork/java/codeconventions-142311.html#431
«The opening brace should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement»
«The opening brace should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement»
А чем protobuf не угодил?
Фреймворки накладывают свои ограничения, поэтому я считаю, что нужно сперва очень хорошо подумать, прежде чем заковывать себя в «чужие оковы». Сетевой клиент слишком небольшая задача, чтобы прибегать к помощи фреймворков. Что если в один момент вам не хватит его гибкости? Переписывать все с нуля, или искать другой фреймворк? Мой ответ в данном случае следующий — я предпочту написать свой код, потому как, если меня попросят, я всегда смогу его расширить и улучшить.
Вы противоречите себе: с одной стороны у вас небольшая задача, которую вам не лень переделывать снова и снова, а с другой — боитесь упереться в ограничения фреймворка. Одновременно этого не бывает (ну разве что фреймворк был использован совсем неподходящий). На том этапе, когда вам не хватит protobuf для вашего протокола, самописный велосипед давным-давно выйдет за рамки небольшой задачи со всеми вытекающими затратами на поддержку и тестирование.
у вас небольшая задача
Сложность задачи зависит от сложности протокола. Несложный протокол реализовать легко, и затраты на его поддержку минимальны(так что никаких проблем). Сложный протокол (да я боюсь ограничений фреймворков), поэтому выберу собственный код.
P.S. Истина где-то по середине — в ваших словах, конечно, тоже есть доля правды.
Налицо ситуация:
Подходящего фреймворка на Java вы не знаете, потому как, по вашим словам, у вас небольшой опыт программирования на Java. Но вместо того, чтобы активно изучать фреймворки, вы делаете сразу три ошибки:
1) Изобретаете велосипед
2) Активно защищаете свое, очевидно ошибочное, мнение в ущерб себе же
3) С таким подходом вы никогда не изучите ничего нового
PS Если люди вас ругают — благодарите в ответ: вам указывают на ваши ошибки и вы можете их исправить. Объясню для программиста: это как тестирование продукта, но на халяву.
Подходящего фреймворка на Java вы не знаете, потому как, по вашим словам, у вас небольшой опыт программирования на Java. Но вместо того, чтобы активно изучать фреймворки, вы делаете сразу три ошибки:
1) Изобретаете велосипед
2) Активно защищаете свое, очевидно ошибочное, мнение в ущерб себе же
3) С таким подходом вы никогда не изучите ничего нового
PS Если люди вас ругают — благодарите в ответ: вам указывают на ваши ошибки и вы можете их исправить. Объясню для программиста: это как тестирование продукта, но на халяву.
«Филды», «имплементация», «кодер», «декодер», «таска» — не многовато ли новояза для одного артикла?
Вполне обычный сленг
Я вижу вебсервисы (?), в которых передаются IMessage. Можно было бы взять CXF и передавать вообще любые java bean, не только IMessage
Sign up to leave a comment.
Разработка сетевого клиента на Java