Комментарии 84
Недоработка одна — называется WCF. Она полностью заменяет ту тонну кода, которую вы написали.
Я писал эту тонну кода для развития и получения опыта. Если уже есть куча вещей, что теперь изобретать все время что то новое чтобы попрактиковаться?
Ну, если для себя — тогда мне непонятен смысл публикации. Покритиковать? Я бы обратился за этим на профильные ресурсы.
Здесь есть статьи где пишут чат, Remote — Desktop, а что там нового?
НЛО прилетело и опубликовало эту надпись здесь
Я не думаю, что подобные статьи имеют смысл.
Во-первых — это велосипед, есть WCF.
Во-вторых — это довольно плохо написанный код.
В-третьих — он еще и ужасно представлен.
Во-первых — это велосипед, есть WCF.
Во-вторых — это довольно плохо написанный код.
В-третьих — он еще и ужасно представлен.
НЛО прилетело и опубликовало эту надпись здесь
Я бы не стал рекомендовать его начинающим — в нем применяются довольно плохие приемы программирования, а форматирование не оставляет шансов разобраться в нем.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется избыточным применение интерфейса IPacket — пакетами при таком подходе могут быть совершенно любые объекты, помеченные как сериализуемые. Сам по себе он не привносит ни удобства реализации, ни четкости семантики.
Семантически неверное использование порождающего паттерна через интерфейс ICloneable. Я прекрасно понимаю задумку, но семантика этого интерфейса требует совершенно другой реализации.
Довольно странная синхронизация на ManualResetEvent. Первый раз такую вижу, честно говоря.
Семантически неверное использование порождающего паттерна через интерфейс ICloneable. Я прекрасно понимаю задумку, но семантика этого интерфейса требует совершенно другой реализации.
Довольно странная синхронизация на ManualResetEvent. Первый раз такую вижу, честно говоря.
НЛО прилетело и опубликовало эту надпись здесь
Представьте себе, что я бы использовал интерфейс IEnumerable для того, чтобы передвигать каретку печатной машинки.
НЛО прилетело и опубликовало эту надпись здесь
Возможно, вы сказали очень умную вещь, но я, к сожалению, не способен ее понять.
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, я слишком глуп для понимания таких глубоких аналогий. Не могли бы вы мне объяснить в понятных терминах?
НЛО прилетело и опубликовало эту надпись здесь
Увы, мне совершенно непонятно, каким образом вы делаете глубокие выводы по функциональному программированию, оперируя исключительно статьей из Википедии.
НЛО прилетело и опубликовало эту надпись здесь
Ну, вы даете на нее ссылку и цитируете ее как авторитетный источник. Логично было бы предположить именно то, что предполагаю я.
Мои познания в функциональном программировании не позволяют представить императивное действие в виде вычисления списка, не пользуясь хитрыми техниками вроде монад.
Впрочем, вы можете быть опытнее меня в этом вопросе — вы прочитали хотя бы один абзац хотя бы одной стати о функциональном программировании в Википедии.
Мои познания в функциональном программировании не позволяют представить императивное действие в виде вычисления списка, не пользуясь хитрыми техниками вроде монад.
Впрочем, вы можете быть опытнее меня в этом вопросе — вы прочитали хотя бы один абзац хотя бы одной стати о функциональном программировании в Википедии.
НЛО прилетело и опубликовало эту надпись здесь
А почему вы сразу не написали так? Зачем было дискуссию по поводу ненужности статьи устраивать? Как мне еще учиться писать правильный хороший код самому?
Мне на секунду показалось, что вы написали велосипед.
Моя ошибка.
Моя ошибка.
В защиту скажу что такая болезнь как велосипедостроение не имеет возрастных и этнических границ.
Я бы с удовольствием почитал про велосипед «как мы на перле писали убийцу nginx» или «тетрис на брайнфаке», если бы в статье было только пару диаграмм и много впечатлений/опыта полученного в процессе разработки.
А листинги кода… даже не знаю кому могут быть интересны.
Я бы с удовольствием почитал про велосипед «как мы на перле писали убийцу nginx» или «тетрис на брайнфаке», если бы в статье было только пару диаграмм и много впечатлений/опыта полученного в процессе разработки.
А листинги кода… даже не знаю кому могут быть интересны.
Да что вы за свой велосипед?! Как будто кроме меня все пишут статьи о своих гениальных разработках. И я в начале статьи дал понял что еще даже школу не закончил не то что универ.
Множество людей пишут примерно о том же, о чем и вы. Это совершенно не значит, что так нужно делать.
Вы правильно делаете, что развиваетесь. Построение систем на низком уровне позволяет понять, как они устроены и лучше представить, как с ними работать на высоком уровне.
Однако, данная статья, к сожалению, бесполезна. Единственное, что можно сделать — это сообщить, где у данного кода проблемы.
Вы правильно делаете, что развиваетесь. Построение систем на низком уровне позволяет понять, как они устроены и лучше представить, как с ними работать на высоком уровне.
Однако, данная статья, к сожалению, бесполезна. Единственное, что можно сделать — это сообщить, где у данного кода проблемы.
Согласен, умение программировать это в первую очередь умение выстроить архитектуру, и применить к ней уже готовые проверенные решения, и здесь WCF + net.MSMQ (net.pipe, net.tcp) вполне подошли бы.
От нехватки статей Хабр как раз не страдает, так что пока нелепо руководствоваться соображениями «А то на хабр перестанут писать».
> Не пугайте авторов.
> А то на хабр перестанут писать.
Пусть авторы не пугают читателей.
А то Хабр перестанут читать.
Статья должна быть хоть чем-то полезной для читателей, а не только для автора.
> А то на хабр перестанут писать.
Это ведь замечательно. Так здорово, когда человек приходит домой со школы, садится за компьютер и НЕ ПИШЕТ СТАТЬЮ НА ХАБРАХАБР. Это прекрасно, и к этому нужно стремиться.
Можно завести отдельный блог, в котором отмечаться: «Сегодня я был готов наваять нетленку про мои первые шаги в языке X, но совесть склонила меня не злоупотреблять вашим вниманием.» Я буду периодически заходить в этот блог и от души благодарить неписателей.
> Не пугайте авторов.
> А то на хабр перестанут писать.
Пусть авторы не пугают читателей.
А то Хабр перестанут читать.
Статья должна быть хоть чем-то полезной для читателей, а не только для автора.
> А то на хабр перестанут писать.
Это ведь замечательно. Так здорово, когда человек приходит домой со школы, садится за компьютер и НЕ ПИШЕТ СТАТЬЮ НА ХАБРАХАБР. Это прекрасно, и к этому нужно стремиться.
Можно завести отдельный блог, в котором отмечаться: «Сегодня я был готов наваять нетленку про мои первые шаги в языке X, но совесть склонила меня не злоупотреблять вашим вниманием.» Я буду периодически заходить в этот блог и от души благодарить неписателей.
WCF не всегда работает так, как того требуют условия. Приходится городить свои заточенные под задачу реализации работающие поверх инфраструктуры TransparentProxy.
«Общая часть»
и сразу фейл:
«interface IPacket»
пакет это расходный материал, он не должен иметь поведения, а цена его создания должна быть ничтожна. В C# для этого есть структуры.
и сразу фейл:
«interface IPacket»
пакет это расходный материал, он не должен иметь поведения, а цена его создания должна быть ничтожна. В C# для этого есть структуры.
НЛО прилетело и опубликовало эту надпись здесь
Я его посмотрел. Даже переименовывание в «сообщение» не избавляет от надобности рационально использовать память и думать над дизайном.
НЛО прилетело и опубликовало эту надпись здесь
Пожалуй, присоединюсь.
API Насчет IPacket — согласен
API Насчет IPacket — согласен
Не дописал.
API можно обсуждать до бесконечности, но все же.
IPacket — реально, в данном контексте, пакет/message — это просто обертка, транспорт, DTO, если хотите. С одной стороны у нас — опасность over-engineering-а, а с другой — нарушение SRP. Возможно, имеет смысл сделать некий IPacketWriter, если уж на то пошло.
Лично, на мой взгляд, IPacket — пример вырожденного role-interface, то есть интерфейс, который умеет делать всего одну вещь, и врядли нуждается в интерфейсе.
API можно обсуждать до бесконечности, но все же.
IPacket — реально, в данном контексте, пакет/message — это просто обертка, транспорт, DTO, если хотите. С одной стороны у нас — опасность over-engineering-а, а с другой — нарушение SRP. Возможно, имеет смысл сделать некий IPacketWriter, если уж на то пошло.
Лично, на мой взгляд, IPacket — пример вырожденного role-interface, то есть интерфейс, который умеет делать всего одну вещь, и врядли нуждается в интерфейсе.
НЛО прилетело и опубликовало эту надпись здесь
Может если сказать возраст меня не будут сильно критиковать? :D
НЛО прилетело и опубликовало эту надпись здесь
не надо говорить про возраст, это ни к чему. Он у вас в профиле написан.
Посыл хороший, согласен, код, конечно не так хорош, и архитектура тоже. Но хабр немного не то место где нужно такие посылы реализовывать.
А то что вы пишете такой код в таком возрасте, это похвально. Вы же это хотели услышать, не так ли?
Посыл хороший, согласен, код, конечно не так хорош, и архитектура тоже. Но хабр немного не то место где нужно такие посылы реализовывать.
А то что вы пишете такой код в таком возрасте, это похвально. Вы же это хотели услышать, не так ли?
Парень, отличная наработка и отличный код для твоего возраста — так вообще. Уже знаешь про хранилища, фабрики и используешь интерфейсы. Некоторые все ещё процедурами говнокодят и холиварят по этому поводу, а ты ещё до универа начал развиваться в правильном направлении. Почитай Эванса, если не читал и ещё книжку хорошую «Art of Testing.» Чтобы писать код, который подлежит тестированию. Что касается универа в твоем случае, то закончи его обязательно, не бросай (может сперва показаться не интересно. Столько писать кода ты там уже не будешь), но делай упор теорию, ищи где её сможешь потом применить.
А полное имя этого Эванса? И на запрос Art of Testing мне полно лабуды вылезает )
НЛО прилетело и опубликовало эту надпись здесь
Видимо, имелось в виду The Art of Unit Testing. Если так, то присоединяюсь к рекомендациям.
Несмотря на то, что подобную задачу действительно лучше решать с применением WCF (с напильничком), реализация неплохая, тем более для целей освоения темы. Вполне норм. Но простор для развития большой, главное избегайте over-engineering-а.
Автор молодец, но на будущее — нужно стараться как-то минимизировать объем текста, чтобы была понятна идея. Мне, например, совсем неохота разбираться в том, какие классы с какими взаимодействует. Имхо, хорошо собранная диаграммка со стрелочками-пояснениями к самым важным классам наподобие «этот класс ответственен за то-то и это» выглядела бы намного презентабельнее стены кода.
Почитайте Рихтера, если еще не читали CLR via C#. Попробуйте использовать асинхронные методы (APM) вместо создания Thread.
Лично я для сервера игры писал на сокетах используя библиотеку SuperSocket (пришлось много допилить, но все равно рекоммендую!). WCF в лично моем случае не канал — т.к. на WP7 он сильно кастрированный.
Молодца.
1) Используйте XML-комментарии.
2) Используйте более-менее принятый стиль наименования (пока положил Coding Standarts for .NET), хотя бы для того, чтобы избежать избыточных this.
3) Для IP-адресов в .NET есть IPAddress.
4) Есть ManualResetEventSlim. К тому же, для ManualResetEvent(Slim) нужно вызывать Dispose(), так что ваш класс должен правильно реализовать интерфейс IDisposable (что уже отдельная тема);
5) Используйте Task вместо Thread;
6) Активнее используйте ключевые слова const, readonly, sealed…
7) Используйте форматные строки (вроде как Console.WriteLine(DateTime.Now.ToString(«h:m:s»)); вместо DateTime now = new DateTime(); now = DateTime.Now; System.Console.WriteLine(«Server started at » + now.Hour + ":" + now.Minute + ":" + now.Second);
8) Ваш кодможет иметь имеет проблемы в синхронизации потоков. Разберитесь в этой проблеме, это достаточно не простая тема.
Ну и ещё достаточно придирок, код точно не самый лучший. Самостоятельное изучение в любом случае похвально.
2) Используйте более-менее принятый стиль наименования (пока положил Coding Standarts for .NET), хотя бы для того, чтобы избежать избыточных this.
3) Для IP-адресов в .NET есть IPAddress.
4) Есть ManualResetEventSlim. К тому же, для ManualResetEvent(Slim) нужно вызывать Dispose(), так что ваш класс должен правильно реализовать интерфейс IDisposable (что уже отдельная тема);
5) Используйте Task вместо Thread;
6) Активнее используйте ключевые слова const, readonly, sealed…
7) Используйте форматные строки (вроде как Console.WriteLine(DateTime.Now.ToString(«h:m:s»)); вместо DateTime now = new DateTime(); now = DateTime.Now; System.Console.WriteLine(«Server started at » + now.Hour + ":" + now.Minute + ":" + now.Second);
8) Ваш код
Ну и ещё достаточно придирок, код точно не самый лучший. Самостоятельное изучение в любом случае похвально.
Немного ударюсь в полемику:
Чем Task лучше ThreadPool? Вроде Рихтер рекомендует активно использовать именно пул потоков.
Чем Task лучше ThreadPool? Вроде Рихтер рекомендует активно использовать именно пул потоков.
Task тоже использует пул потоков, но помимо этого имеет еще много хорошего. Возможно это был Рихтер до выхода TPL?
Task или ThreadPool — дело вкуса и потребностей. Основное отличие Task в том, что есть возможность узнать когда она завершается и вернуть результат без лишних извращений в коде =)
Насколько мне известно, Task внутрях использует ThreadPool. Task поддерживает предпочтительный механизм завершения синхронных/асинхронных операций — CancellationToken. Вот тут ещё кое-что написано.
ну и в копилку конкретных примеров «не очень» кода, в рамках наименования переменных
class InputProcessor — и в его конструкторе Reader = new BinaryReader(this._stream);
1) все private переменные однотипно названы с префиксом "_", Reader без префикса, и с большой буквы
2) обращение к private переменным начинется c this. ( спорно, но некоторыми рекомендуется ), а тот же Reader без this. что при прочтении навевает мысль что доступ должен быть public, а оказывается что нет.
ну а в целом, да, мне бы в таком возрасте такую увлечённость.
class InputProcessor — и в его конструкторе Reader = new BinaryReader(this._stream);
1) все private переменные однотипно названы с префиксом "_", Reader без префикса, и с большой буквы
2) обращение к private переменным начинется c this. ( спорно, но некоторыми рекомендуется ), а тот же Reader без this. что при прочтении навевает мысль что доступ должен быть public, а оказывается что нет.
ну а в целом, да, мне бы в таком возрасте такую увлечённость.
Для изучения и пробы пера вполне хорошо.
1) Преодолеть себя и начать писать код, учитывая что чисто для себя — это плюс.
2) Учитывая какие программисты порой любители искать огрехи в чужом коде и не побоятся показать свой код на публику надо иметь смелость.
Замечания (постараюсь не повторятся):
1) Интересно было посмотреть что да как, но когда увидел, что все в разных солюшенах это сделать стало не совсем удобно.
2) Про IpAdress, XML комментарии, диаграммы — все по делу сказано.
3) Увы, правда жизни, но когда надо делать что-то реальное коммерческое, то не до баловства, и упор на уже написанные «велосипеды» надо делать, так как в жизни больше они понадобятся, чем вот такие вот изучения.
1) Преодолеть себя и начать писать код, учитывая что чисто для себя — это плюс.
2) Учитывая какие программисты порой любители искать огрехи в чужом коде и не побоятся показать свой код на публику надо иметь смелость.
Замечания (постараюсь не повторятся):
1) Интересно было посмотреть что да как, но когда увидел, что все в разных солюшенах это сделать стало не совсем удобно.
2) Про IpAdress, XML комментарии, диаграммы — все по делу сказано.
3) Увы, правда жизни, но когда надо делать что-то реальное коммерческое, то не до баловства, и упор на уже написанные «велосипеды» надо делать, так как в жизни больше они понадобятся, чем вот такие вот изучения.
Для возраста автора — очень даже круто. Сразу видно, что человек активно учится, виден прочтенный и более-менее понятый как минимум GoF, понятые потоки итд, и при этом без свойственных подросткам самомнения и попыток самоутвердиться.
Критика:
1. Оверинжиниринг. Все можно сделать проще.
2. Есть некоторые проблемы с именованием. Хотя все равно лучше, чем у многих хабровских «веб-разработчиков».
3. Из-за оверинжиниринга опять же толком не отделены ввод/вывод, обработка сообщений и собственно код отвечающий за передачу данных.
4. Местами не thread-safe код (список ников, например).
zheleznyak_oleg, удачи вам в профессии, у вас все получается ;)
Критика:
1. Оверинжиниринг. Все можно сделать проще.
2. Есть некоторые проблемы с именованием. Хотя все равно лучше, чем у многих хабровских «веб-разработчиков».
3. Из-за оверинжиниринга опять же толком не отделены ввод/вывод, обработка сообщений и собственно код отвечающий за передачу данных.
4. Местами не thread-safe код (список ников, например).
zheleznyak_oleg, удачи вам в профессии, у вас все получается ;)
Набросились-то, набросились. Паренек молодец, если не завяжет, то имеет все шансы вырасти в хорошего специалиста. Более, чем естественно, что ему хочется и погордиться написанным кодом, и влиться в профессиональную среду, в 14 лет-то. Только, Олег, тут такие же люди как и везде: многим лучше жевать, чем говорить. Ну а вам лично совет простой: хотите сделать лучше — целенаправленно ищите минусы.
Файлы перезалить надо. Не обнаружены.
:-(
:-(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многоклиентский сетевой протокол на C#