Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, gandjustas, Вы писали:

G>>>>Где именно?

L>>>В 5-й главе.

G>>А до 5 главы что?

L>До 5-й главы — главы с 1-й по 4-ю.

То есть о важном только к середине книги, а до этого бредятина всякая

Здравствуйте, gandjustas, Вы писали:

L>>До 5-й главы — главы с 1-й по 4-ю.

G>То есть о важном только к середине книги, а до этого бредятина всякая

Ты знаешь, на это можно и с другой стороны посмотреть.

Здравствуйте, Lloyd, Вы писали:

L>Для того, чтобы показать, что какое-то явление возможно, достаточно привести 1 пример. "какое-то явление" тут — это наличие бизнес-логики в сущностях.

Это означает ровно одно. Что Эванс демонстрирует DDD на примерах c rich model.

Доказательства того, что DDD и anemic несовместимы здесь нет. Есть доказательство совместимости с rich model, при этом, возможна совместимость и с anemic. Основной постулат DDD — максимальное приближение модели данных к естественным сущностям в бизнесе. Я совершенно не понимаю хайпа вокруг этой аббревиатуры.

Кстати, ровно то же самое говорит википедия:

Relationship to other ideas

...
POJOs and POCOs
POJOs and POCOs are technical implementation concepts, specific to the Java and .NET framework respectively. However, the emergence of the terms POJO and POCO, reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.

B>>Между единицей и любым числом больше единицы действительно ничего нет.
S>Снова подмена. Речь шла о нескольких сущностях без оговорок, потом о единственном объекте с состоянием, эквивалентным программе с глобальными переменными.
Какая нафиг подмена? Сами запутались в предмете спора и меня ещё в чём-то смеете обвинять.
Перечитайте диалог заново.

L>То вы просите цитаты, а как вам их дают, то сразу они оказываются не нужны.
Вы врёте. Цитат не было. Была отсылка к какой-то картинке.

L>Вы не ответили на вопрос, как у вас так получилось, что слово "сущность" когда об этом говорите вы и ваш собеседник обозначает для вас не одно и то же.
Вы врёте. Этот вопрос мне задан не был.

L>И таки-да, еще вы не ответили на вопрос по поводу преимуществ рекомендуемого вами подхода.
Вы врёте. Я не рекомендовал никаких подходов, соответственно вы не задавали такого вопроса. Нигде в нашем диалоге ни в одном сообщении нет моих слов "рекомендую" и "подход".

L>А где я писал, что сервим не может иметь состояния? Опять "подмена тезиса"?
Подмены пока что присутствуют исключительно в ваших репликах. Сервис может быть объектом в терминах ООП со всеми признаками — инкапсуляция, полиморфизм, наследование и проч.

L>Мои опасения про "список" только подтверждаются — вы умело продемонстриовали прием "Переход на личности".
Переход на личности обоснован. Я имею дело со лжецом и демагогом, не способным нормально аргументировать свою позицию. Ок, разговор окончен.

Здравствуйте, Baudolino, Вы писали:

L>>То вы просите цитаты, а как вам их дают, то сразу они оказываются не нужны.
B>Вы врёте. Цитат не было. Была отсылка к какой-то картинке.

Эта картинка является цитатой из книги прородителья ddd.
У вас нет даже этой книжки? Если нет, то она легко гуглица. Хотя тогда не понятно чего же вы меня посылаете читать литерутуру, если сами с оной не ознакомились?

L>>Вы не ответили на вопрос, как у вас так получилось, что слово "сущность" когда об этом говорите вы и ваш собеседник обозначает для вас не одно и то же.
B>Вы врёте. Этот вопрос мне задан не был.

Т.е. когда вы писали про "несколько сущностей", вы поняли все правильно. А когда я спросил про вариант с одной сущностью, то вы почему-то решили, что речь идет об экземпляре?
Как-то не вяжется.

Вот цитата из поста. Ваш ответ на него не содержал ответа.

Я-то может и вру, но содержимое форума говорит об обратном.

L>>И таки-да, еще вы не ответили на вопрос по поводу преимуществ рекомендуемого вами подхода.
B>Вы врёте. Я не рекомендовал никаких подходов, соответственно вы не задавали такого вопроса. Нигде в нашем диалоге ни в одном сообщении нет моих слов "рекомендую" и "подход".

Очередное доказательство демагогии. То, что вы не употребляли слов "рекомендую" и "подход" не означает, что вы не рекомендовали подхода.
А тот факт, что вы отрицаете это, и вовсе не играет в вашу пользу — вы написали полтора десятка постов и так и не прояснили, что именно вы отстаиваете. Демагог и есть.

L>>А где я писал, что сервим не может иметь состояния? Опять "подмена тезиса"?
B>Подмены пока что присутствуют исключительно в ваших репликах.

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

А где я писал, что сервим не может иметь состояния?

B>Сервис может быть объектом в терминах ООП со всеми признаками — инкапсуляция, полиморфизм, наследование и проч.

Это было к чему сказано? Разве я оспариваю то, что вы прочитали школьный учебник по программированию?
И кстати, приведенным признами отсутствуют во многих вполне себе ОО-языках (питон, джаваскрипт, даже на С при желании можно писать в ОО-стиле).

L>>Мои опасения про "список" только подтверждаются — вы умело продемонстриовали прием "Переход на личности".
B>Переход на личности обоснован. Я имею дело со лжецом и демагогом, не способным нормально аргументировать свою позицию.

Вот вы и добрались до самого главного пункта "обвинение собеседника в демагогоии". Браво, маэстро. Несите зачетку.

B>Ок, разговор окончен.

Ты главное, не расплакайся там. Не стоит оно того. Лучше учебник еще раз перечитай.

Здравствуйте, Ziaw, Вы писали:

L>>Для того, чтобы показать, что какое-то явление возможно, достаточно привести 1 пример. "какое-то явление" тут — это наличие бизнес-логики в сущностях.

Z>Это означает ровно одно. Что Эванс демонстрирует DDD на примерах c rich model.

Z>Доказательства того, что DDD и anemic несовместимы здесь нет. Есть доказательство совместимости с rich model, при этом, возможна совместимость и с anemic. Основной постулат DDD — максимальное приближение модели данных к естественным сущностям в бизнесе.

Не согласен я.

В понимании Эванса (точнее в моем понимании Эванса ), ddd — это не только принцип, но и архитектура с определенным разбиением на энтити, агрегаты, вэлью-объекты, фабрики, репозитории, сервисы и так дале и тому подобное.

И примеры, которые он приводит, демонстрируют его мнение о ddd как архитектуре, а там — именно рич-модель.
Более того, раздел про сервисы начинается, что мол если у вас есть непонятки по поводу того, куда поместить операцию (In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object), то кладите ее в отдельный сервис. Это как-бы отводит сервисам вторичную роль, мол если не удалось найти куда приткнуть, то делайте сервис, что как бы опять приводит к выводу, что в остальных случаях у нас операции будут в энтитях.

Если в качестве первоисточника обращаться к эвансу, то ddd — это все-таки рич.

Здравствуйте, Baudolino, Вы писали:

B>>>Между единицей и любым числом больше единицы действительно ничего нет.
S>>Снова подмена. Речь шла о нескольких сущностях без оговорок, потом о единственном объекте с состоянием, эквивалентным программе с глобальными переменными.
B>Какая нафиг подмена? Сами запутались в предмете спора и меня ещё в чём-то смеете обвинять.
Я в предмета спора не касался и тем самым не давал повода обвинять меня в запутанности. Мои посты здесь касались только ваших попыток трансформации темы. И я вас не обвиняю, я указываю на недоразумения в ваших аргументах.

B>Перечитайте диалог заново.
Перечитывал. И свое видение ваших постов описывал. Возражений не нашел, наверное вы согласны с этим видением.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Lloyd, Вы писали:

L>>Для того, чтобы показать, что какое-то явление возможно, достаточно привести 1 пример. "какое-то явление" тут — это наличие бизнес-логики в сущностях.

Z>Это означает ровно одно. Что Эванс демонстрирует DDD на примерах c rich model.

Z>Доказательства того, что DDD и anemic несовместимы здесь нет. Есть доказательство совместимости с rich model, при этом, возможна совместимость и с anemic. Основной постулат DDD — максимальное приближение модели данных к естественным сущностям в бизнесе. Я совершенно не понимаю хайпа вокруг этой аббревиатуры.

Z>Кстати, ровно то же самое говорит википедия:
Z>

Relationship to other ideas

Z>...
Z>POJOs and POCOs
Z>POJOs and POCOs are technical implementation concepts, specific to the Java and .NET framework respectively. However, the emergence of the terms POJO and POCO, reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.

Изначально в ветке противопоставлялись анемик и ООП. Не совсем противопоставлялись, речь шла о том что анемик это шаг от ООП. Раз пошли в ход ссылки на википедию, тоже всталю. В википедии отсылают к процедурному программированию.

http://martinfowler.com/bliki/AnemicDomainModel.html

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk.

Я не согласен что это ужасно, хочу лишь обратить внимание на то что Фаулер (and Eric) тоже отсылает к процедурному стилю.
Там же у Фаулера есть цитата из Еванса о том что он против концентрирования логики в сервисных слоях (что имеет место при активном использовании анемика). Это не значит что DDD и anemic несовместимы, но косвенно выдает отношение Еванса к жирным сервисным слоям.

И кроме этого, я считаю что POJO и anemic — совершенно разные вещи.

Здравствуйте, Lloyd, Вы писали:

L>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").
Это не определение. Это чушь, которой забивают мозг неопытным разработчикам. Потом их очень трудно лечить от заблуждений.
Для начала, нужно твёрдо усвоить, что ООП — оно целиком про поведение. А не про структуру полей и методов.

VD>Позволь полюбопытствовать, а "нормальная архитектура" и ООП — это одно и то же?

Вопрос с подвохом Нормальный OOD — как минимум, соблюдение SOLID. Получаем поддерживаемую систему, могущую изменяться под новые требования без переписывания половины кода с последующим трехмесячным дебагом. Что такое говнокод на ОО-языке? Номер раз — процедурщина. Этого добра так много, что номер два (нездоровое увлечение фп) на ее фоне почти незаметен. Немного фп внутри класса — ок, упрощает рутинные операции, но когда пытаются строить на этом архитектуру — это даже не смешно.

Здравствуйте, -VaS-, Вы писали:

VD>>Позволь полюбопытствовать, а "нормальная архитектура" и ООП — это одно и то же?

VS>Вопрос с подвохом Нормальный OOD — как минимум, соблюдение SOLID.
1) SOLID не про ООП в основном, там только принцип OCP непосредственно связан с ООП, и то это совершенно бесполезный принцип в оргинале
2) Сами принципы крайне туманны и не дают критерия соответствия принципам. То есть ты по коду не можешь объективно утверждать выполняется ли тот или иной принцип (за редким исключением).
http://gandjustas.blogspot.com/2011/08/solid.html
тут подробно свой взгляд описал. Предупреждаю, он сильно не соответствует тому что можно в интернетах прочитать.

VS>Получаем поддерживаемую систему, могущую изменяться под новые требования без переписывания половины кода с последующим трехмесячным дебагом.
У меня после такой фразы возникает вопрос: каким образом тогда новый функционал достигается?

VS>Что такое говнокод на ОО-языке? Номер раз — процедурщина. Этого добра так много, что номер два (нездоровое увлечение фп) на ее фоне почти незаметен. Немного фп внутри класса — ок, упрощает рутинные операции, но когда пытаются строить на этом архитектуру — это даже не смешно.
Поменьше эмоциональных оценок, побольше конкретики. Что такое "процедурщина" ? Почему плохо строить на ФП всю архитектуру?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Lloyd, Вы писали:

L>>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").
S>Это не определение. Это чушь, которой забивают мозг неопытным разработчикам. Потом их очень трудно лечить от заблуждений.

Ваш пост был очень глубок и убедтелен, он в корне перевернул представления всей индустрии о то, что такое ооп. Аргумент "чушь" мне показался особенно блистательным.
Пишите исчо.

S>Для начала, нужно твёрдо усвоить, что ООП — оно целиком про поведение. А не про структуру полей и методов.

Несомненно, Антон из Новосиборска туфты не напишет.

Здравствуйте, Lloyd, Вы писали:
L>Ваш пост был очень глубок и убедтелен, он в корне перевернул представления всей индустрии о то, что такое ооп. Аргумент "чушь" мне показался особенно блистательным.
Простите, но этот пост ничего не переворачивает. Это всего лишь констатация достаточно широко известного факта.
L>Пишите исчо.
Я постараюсь.
S>>Для начала, нужно твёрдо усвоить, что ООП — оно целиком про поведение. А не про структуру полей и методов.
L>Несомненно, Антон из Новосиборска туфты не напишет.
Спасибо за доверие, но я тут ни при чём. Читайте изобретателя ООП — Алана Кея.
Кроме того, имеет смысл применять критическое мышление. К примеру, если вы видите, что предлагаемые кем-то правила неизменно приводят к плохому результату, то эти правила сами плохи. Особенно если есть альтернативные правила, которые приводят к более понятным и предсказуемым результатам.
Например, трактовка ООП как механизма по конструированию объектов из данных и методов приводит к бесплодным спорам вроде того, наследовать ли эллипс от круга или наоборот. При этом моделирование от поведения моментально приводит к правильному ответу.
Поскольку мы занимаемся инженерной дисциплиной, практика является основным критерием истины. Неудобные теории бесполезны, даже если они являются формально непротиворечивыми.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, licedey, Вы писали:

L>>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд.
L>>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.

G>Да, ты угадал. ООП совсем не подходит для проектирования программ.

Это ирония? А что тогда подходит или дополняет ООП?
Я говорю не о масштабных программах, а скорее о конкретной задаче. Например такого типа: сниффер, плагин к браузеру, архиватор...Вопрос спорный, нужно ли изголяться и выявлять сущности, которых по сути нет. Для них создавать класс, при том, что объект может быть один..

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, licedey, Вы писали:

L>>Здравствуйте, мыщъх, Вы писали:

М>>>Здравствуйте, licedey, Вы писали:

L>>У меня любая задача так. Уж чему научился по книжкам ООП ин депс, тем и владею. От того и получается.
L>>Задача: напиши снифер 80-го протокола, чтобы уловить откуда видео идет.
L>>Я написал 3 класса: NetworkAdapterDetector, FlashSniffer, и TrackingURL.
L>>Ну думаю вы понимаете, что каждый из них делает.
М>совершенно не представляю. нет такого протокола. нормальный сниффер (типа wireshark) сниффет все подряд. догадываюсь, что вам нужно сниффать TCP. догадываюсь, что это http. догадываюсь, что нужно парсить HTML. итого, мы имеем две _никак_ не связанные друг с другом задачи. первая -- просто сниффер. он уже есть. tcpdump в линухе. переводит карту в неразборчивый режим и ловит все, что адресовано ему и не ему. записывает резултать в pcap.

М>вторая задача -- распарсить pcap. сначала парсим, чтобы вытащить ethernet, из него ip, из него tcp, из него http. парсиг html в принципе это третья задача, т.к. парсеру html все равно подаем ли мы на вход html-файл, скаченный из сети или награбленный сниффером.

М>кстати, из ваших классов ни фига не понятно будет ли программа работать с уже готовыми pcap файлами или нет. так же непонятно почему flash выделена в отдельную сущность. там декопилтяор swf что ли?!

>> В тоже время, мой аппонент, Модифицировал существующий код.
>> Ну я потратил на это все 30 часов. Он около 15-ти.
М>фигасе. с готовыми библеотеками (а их просто море) я написал экстрактор ссылк на полчаса (в которые вошел и поиск этих самых библиотек) и написание кода. у меня три отдельных модуля. сниффер (на входе трафик, на выходе pcap), экстрактор http трафика (на входе pcap, на выходе html) и декодер html, кстати, поддерживающий java script'ы и обсусцированные ссылки. на входе html на выходе -- список ссылок. причем, модули совершенно независимы и легко расширяемы.

>> Мой эстетичней, документированней и "разделяй и влавствуй".
М>так у вас все в кучу. давайте еще раз разделять.
М>1) снифаем трафик;
М>2.1) парсим протоколы: Ethernet, IP, TCP
М>2.2) парсим HTTP (по хорошему это намного сложнее чем IP и TCP);
М>3.1) парсим HTML по тупому (считаем, что там нет скриптов)
М>3.2.1) выполняем java scrpt'ы и vbscipt на JS/VBS дивжках и грабим вывод;
М>3.3.2) эмулируем DOM (или берем готовый из браузера)

М>как-то так... если нужна детекция swf, то это отдельная задача. причем, я решил эту задачу в рамках процедурного подхода. приплюснотого кода там нет вообще. и это ни разу не ооп. но декомпозиция задачи выполнена вполне. собственно, говоря, парсер HTTP это отдельная задача, т.к. нужно поддержать кучу методов кодировая данных, кучу ответов сервера. понимать что такое POST и GET... но считаем, что парсер HTTP берется библиотечный, т.к. писать его самим это работы на 30 дней, а не часов

>> Вот собственно предпосылка этого поста. Программировать на время, или на качество,
>> с заделом на будущее. Под вопросом, нужно ли это заказчику.
М>по вашей модели не ясно -- будет ли оно работать под никсами, например. сколько кода придется переписать. а что если это будет другой порт? а что если у нас прокси? а как на счет https траффика? а если нужно ловить не только HTML ссылки, но и составить "черынй" список доменных имен и IP адресов, относящийся ко всем протоколам? в приведенной мной модели все это делается без напряга. т.к. уровни четко разграничены и каждый уровень делает свою работу. а у вас?


L>>Ну все равно, нажимаем же File->Add new item.
М>а если это vim?

>> потом уже дальше думаем. Мне больше с нуля нравится, когда за каждую строчку
>> сам отвечаешь. И в случае чего, быстрей костыль подставлю.
М>мне тоже нравится отвечать за себя и больше ни за кого. но вот надо решить задачу и разбросать ее между несколькими сотрудниками, котрые в разных странах живут, часовые пояса совсем не перекрываются, да и пишут они на разных языках. правильная декомпозиция приводит к тому, что сотрудники вообще не будут знать друг о друге. в частности, парсер HTTP не зависет от парсера HTML, не говоря уже за сам сниффер.

М>на чем пишут люди -- мне все равно. хоть на си, хоть на плюсах, хоть на иврите. так что заканчивайте думать о строчках и думайте о задаче в целом, поскольку задача имеет множество решений:

М>1) сниффер, втыкаемый в ethernet и снифающий траффик;
М>2) сниффер на внешнем гейте;
М>3) http-proxy на гейте;

М>https можно сниффать только если или добавить на все компы свой сертификат или через https прокси. но в первом случае нужнен доступ ко всем компам и ноутам сотрудников, а во втором браузер будет ругаться на левый сертификат.

М>кстати, если уже пошел разговор за конкретные иженерные задачи -- на фига вам изобреть свой велосипед? есть же опен-соурсный Snort. на его базе можно замутить практически что угодно. и ничего парсить не надо. достаточно написать правило для ловли всех GET'ов (т.к. видео будет в них).

М>тут так же следует уточнить про какое видео мы говорим. если про то, которое льется по интернету -- то тут HTML вообще парсить не надо, а можно ограничится HTTP. если же нужно извлечь ссылки на видео еще до того как их начнут смотреть -- пишем парсер.

Отвечу коротко, уж извините Есть такого рода MediaSniffer. Но он парсит только видео по расширению от 'GET' ответа. Использует WinPcap либу. Для ютюба например, такой подход не годится. У него в гэт запросе неясно, что за поток идет.
Поэтому было предложено парсить также ответ сервера на Content-Type. По полученному майм-типу, собственно и выявлялось что имеем. Также заданием было определять нужный адаптер автоматически, этим занимался NetworkAdapter (делая пинг и какой адаптер словит — тот и активный). FlashSniffer занимался тем самым парсингом ответов сервера на предмет типа потока. Ну а TrackingUrl привязывался к хосту, от которого идет видео-поток.

К слову сказать, с тем же ютюбом, ответы иногда идут не HTTP 200, а HTTP 304 например. Не перехватывает моя реализация также и rutube.ru. Нет от него ответа 200, с типом контента. Используеться WinPCap.

В вашем комментарии одно задело, "за 30 минут с учетом поиска". На чтение спецификации только и копания сырцов медисниффера, только день ушел. И то в режиме "дым из попы". Потом на детект адаптера день, попутно изучив тонкости WinPcap. И день уже на реализацию снифера согласно спецификации.
При всем уважении к вашему профессионализму — это невозможно! Даже знаю winpcap и не следуя строго требованиями. Минимум день.

Здравствуйте, Sinclair, Вы писали:

S>>>Для начала, нужно твёрдо усвоить, что ООП — оно целиком про поведение. А не про структуру полей и методов.
L>>Несомненно, Антон из Новосиборска туфты не напишет.
S>Спасибо за доверие, но я тут ни при чём. Читайте изобретателя ООП — Алана Кея.

С удовольствием почитаю. Но раз уж вы его рекомендуете, то вам несомненно не составит труда привести цитату автора, опровергающую формулировку из википедии.

S>Кроме того, имеет смысл применять критическое мышление. К примеру, если вы видите, что предлагаемые кем-то правила неизменно приводят к плохому результату, то эти правила сами плохи. Особенно если есть альтернативные правила, которые приводят к более понятным и предсказуемым результатам.
S>Например, трактовка ООП как механизма по конструированию объектов из данных и методов приводит к бесплодным спорам вроде того, наследовать ли эллипс от круга или наоборот. При этом моделирование от поведения моментально приводит к правильному ответу.

Факт 1: применение ООП (по википедии) приводит к " бесплодным спорам".
Факт 2: моделирование от поведения приводит к правильному ответу.
Вывод: ООП — целиком про поведение.

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

Здравствуйте, licedey, Вы писали:


L>Отвечу коротко, уж извините Есть такого рода MediaSniffer.
L>Но он парсит только видео по расширению от 'GET' ответа. Использует WinPcap либу.
что хорошо укладывается в предложенную мной модель. если достаточно парсинга GET, ограничиваемся модулем HTTP и в HTML не лезем. в принципе, с некоторым риском можно парсить "сырой" поток минуя IP и TCP по регуляркам, т.к. скорее всего GET будет целиком в одном пакете. как сырое и быстрое решение для набора статистики "какой гад смотрит видео" оно вполне прокатит (ведь никто же не будет устанавливать TCP-тоннель, кладующий в пакет по одному байту).

но тут все зависит от задачи. если мы парсим HTML, то можно вытянуть не только линк на видео, но и название клипа. одно дело если человек смотрит лекцию от гугла по распределенной файловой системе и совсем другое если это "видеоприколы" или порно. а многие порносайты используют обфускацию для обхода фаеров. там вообще очень интересная схема, где задействуется reverse dns как средство передачи актуального линка. и GET'а не будет. не, ну то есть он будет конечно, но там будет GET на случайное доменное имя и случайный ID. такие доменные имена живут не больше недели, что сильно затрудняет их блокировку и чтобы их все-таки заблокировать нужно распарсить еще и dns.

> Также заданием было определять нужный адаптер автоматически, этим занимался NetworkAdapter
> (делая пинг и какой адаптер словит — тот и активный).
что значит "активный"? у меня, например, три адаптера. два физических и один виртуальный. и все активные. но смотрят в разные сети. и при заходе на ms.com траффик идет через один, а при заходе на юутб -- через другой. а при заходе на произвольный сайт -- хз. нужно смотреть как марштутизация прописана.

L> К слову сказать, с тем же ютюбом, ответы иногда идут не HTTP 200, а HTTP 304 например.
и еще 307 быть может. так что нужно парсить все возможные ответы.

L> В вашем комментарии одно задело, "за 30 минут с учетом поиска".
именно столько нужно, чтобы взять готовые либы и собрать их. на выходе мы будет иметь разобранный HTTP трафик с поддержкой всех кодов ответа и остальных полей.

> На чтение спецификации только и копания сырцов медисниффера, только день ушел.
это потому что вы взяли неправильный открытый проект. я использовал вот это: http://code.google.com/p/pypcap/
не самая лучшая библиотека, но на первой странице гугла. глубже искать было лениво.

> И то в режиме "дым из попы". Потом на детект адаптера день, попутно изучив тонкости WinPcap.
а обязательно именно winpcap? линух заюзать не проще было бы? там этих тонкостей меньше. хотя если вы никогда ранее не сталкивались с такой задачей -- тогда, конечно, совсем другое дело.

L>При всем уважении к вашему профессионализму — это невозможно!
L>Даже знаю winpcap и не следуя строго требованиями. Минимум день.
с использованием dpkt либы парсер HTTP уровня у меня уложился в 93 строки (включая пустые), причем 68 из них -- это копи-паст примера использования этой либы с незначительным допилом под свои нужды. главное -- не писать уже написанное другими.

но мы вообще отклонились от темы. и ваша, и моя концепции укладываются в модульное программирование. кстати, closures -- они ж вроде вполне себе процедурные и совсем не объективно ореентированные, хотя используют ООП-концепцию, где данные упрятаны внутрь объекта. т.е. мы пишем read = OpenAdapter(аргументы) и дальше buf = read(ethernet.ETH_TYPE_IP); красиво и элегантно и данные об адаптере уже внутри OpenAdapter, который вернул функцию read, имеющую к ним доступ. и на closures можно писать то, что пишется на классах и это будет совсем не похоже на ООП.

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

какой смысл писать все на си++ ? и задача декомпозиции ну никак не сводится к трем упомянутыми вами компонентам. поскольку, мало распарсить трафик, нужно проанализировать результат и где-то его сохранить. если трафика немного, то можно ограничится хэш-массивами. а вот если трафика сильно до фига, то правильный выбор базы данных -- это отельная задача, не говоря уже за проектирование самой структуры этой базы.

и, кстати, вы не ответили на мой коренной вопрос -- чем отличается класс от модуля? в смысле чем он отличается в вашей схеме. модуль это черный ящик с публичным интерфейсом. класс -- это черный ящик с публичным интерфейсом и обозначенной иерархией. в частности, TCP и UDP в ООП могут быть производными от IP. а у модуля они все одного ранга. и в этом сила модулей. что вы скажите за TCP over TCP ? если ваши классы не предусматривают возможности такой "производности", то мы приплыли и нужно все перепроетировать заново. а если вспомнить о IPv6 over IPv4, то неудачно выбранная модель классов не позволит его поддержать без переделки всего и вся. и возникает вопрос -- а зачем нам вообще нужны классы?! зачем нам явно указывать иерархию? вот и не будет ее указывать! но "плоская" модель одноранговых классов по сути своей является набором модулей.

в общем, не вижу я здесь ООП.

Здравствуйте, licedey, Вы писали:

L>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, licedey, Вы писали:

L>>>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд.
L>>>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.

G>>Да, ты угадал. ООП совсем не подходит для проектирования программ.

L>Это ирония? А что тогда подходит или дополняет ООП?
L>Я говорю не о масштабных программах, а скорее о конкретной задаче. Например такого типа: сниффер, плагин к браузеру, архиватор...Вопрос спорный, нужно ли изголяться и выявлять сущности, которых по сути нет. Для них создавать класс, при том, что объект может быть один..

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

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

Берем например сниффер:
1)На входе у нас поток пакетов с сетевой платы
2)На выходе пусть будет некоторый GUI

Значит наша схема выглядит как [пакеты с сетевой платы -> черный ящик -> экран].
Пойдем слева направо.
Для перехвата пакетов нам нужен драйвер и некоторый user mode api для работы.
[драйвер -> api -> черный ящик -> экран]

далее все пакеты выводить не надо, надо их по правилам фильтровать
[драйвер -> api -> фильтр пакетов -> черный ящик -> экран]

далее становится ясно что фильтры надо как-то задавать и хранить, у нас получается два dataflow
[драйвер -> api -> фильтр пакетов -> черный ящик -> экран]
[хранилище фильтров -> другой черный ящик -> фильтры] (и наоборот кстати)

Далее пусть GUI ну нас будет просто консолькой, а фильтры будут в конфиге

[драйвер -> api -> фильтр пакетов -> форматер пактов -> экран]
[конфиг -> парсер конфига -> фильтры] (один раз при загрузке)

Далее выбираем технические средства.
Например я пишу на .NET, там уже есть инструментарий для конфигов, для разбирания возьму WinPCAP, он же осуществляет фильтрацию

Получается так:
[.NET обертка для WinPCAP -> форматер пактов -> экран]
[кастомная секция конфига -> фильтр для WinPCAP]
.NET обертка уже есть http://pcapdotnet.codeplex.com/
В итоге остается сделать только секцию конфига, преобразование её в фильтр, и написать форматтер.

Но такое можно за час сделать, попробуем ченить поинтереснее придумать.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, licedey, Вы писали:


L>>Отвечу коротко, уж извините Есть такого рода MediaSniffer.
L>>Но он парсит только видео по расширению от 'GET' ответа. Использует WinPcap либу.
М>что хорошо укладывается в предложенную мной модель. если достаточно парсинга GET, ограничиваемся модулем HTTP и в HTML не лезем. в принципе, с некоторым риском можно парсить "сырой" поток минуя IP и TCP по регуляркам, т.к. скорее всего GET будет целиком в одном пакете. как сырое и быстрое решение для набора статистики "какой гад смотрит видео" оно вполне прокатит (ведь никто же не будет устанавливать TCP-тоннель, кладующий в пакет по одному байту).

Задача — выявлять прямые ссылки на видео, для скачивания.

М>но тут все зависит от задачи. если мы парсим HTML, то можно вытянуть не только линк на видео, но и название клипа. одно дело если человек смотрит лекцию от гугла по распределенной файловой системе и совсем другое если это "видеоприколы" или порно. а многие порносайты используют обфускацию для обхода фаеров. там вообще очень интересная схема, где задействуется reverse dns как средство передачи актуального линка. и GET'а не будет. не, ну то есть он будет конечно, но там будет GET на случайное доменное имя и случайный ID. такие доменные имена живут не больше недели, что сильно затрудняет их блокировку и чтобы их все-таки заблокировать нужно распарсить еще и dns.

В requirements такого не было. Можно еще оффтопика? Вы четко следуете требованиям к заданию? Если требуется по пунктно, но общее решение вы знаете лучше — сделаете по своему? (Я бы тему создал, но вашего ответа будет достаточно. Я часто замыкаюсь на задании в мельчайших подробностях, при этом общаяя картина часто уплывает, и получается 30 часов "как видит заказчик", вместо 10 — как вижу решение я).

>> Также заданием было определять нужный адаптер автоматически, этим занимался NetworkAdapter
>> (делая пинг и какой адаптер словит — тот и активный).
М>что значит "активный"? у меня, например, три адаптера. два физических и один виртуальный. и все активные. но смотрят в разные сети. и при заходе на ms.com траффик идет через один, а при заходе на юутб -- через другой. а при заходе на произвольный сайт -- хз. нужно смотреть как марштутизация прописана.

Интернет-активный. Я в курсе что у вас 6 компов и 10 сетевух. Но для общего случая пинг и отзыв для определения адаптера, который ловит инет — думаю достаточно. Ну и задание большего не требовало.

L>> В вашем комментарии одно задело, "за 30 минут с учетом поиска".
М>именно столько нужно, чтобы взять готовые либы и собрать их. на выходе мы будет иметь разобранный HTTP трафик с поддержкой всех кодов ответа и остальных полей.

Скилсы, скилсы...мне как написали — так и делал.

>> На чтение спецификации только и копания сырцов медисниффера, только день ушел.
М>это потому что вы взяли неправильный открытый проект. я использовал вот это: http://code.google.com/p/pypcap/
М>не самая лучшая библиотека, но на первой странице гугла. глубже искать было лениво.

>> И то в режиме "дым из попы". Потом на детект адаптера день, попутно изучив тонкости WinPcap.
М>а обязательно именно winpcap? линух заюзать не проще было бы? там этих тонкостей меньше. хотя если вы никогда ранее не сталкивались с такой задачей -
— тогда, конечно, совсем другое дело.

Да, все упирается в требования. Заказчик на 5 страницах описал, как он видит задачу и решение. Я максимально старался им следовать. Решение оптимально с точки зрения как просили. Это блин, вроде говорить хирургу, где резать, что-ле...Ну я сам себе начальник, поэтому личные отношения ставлю выше...


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

Это зоопарк какой-то? Ну сделаете вы на питоне, tcpdump — это обертка над Си-шной pcap либой, база данных в моем случае не нужна, только ловить ссылки на видео. Даже если вы это реализуете, круто так, то сопровождать вам же. Станете рабом проекта.

М>какой смысл писать все на си++ ? и задача декомпозиции ну никак не сводится к трем упомянутыми вами компонентам. поскольку, мало распарсить трафик, нужно проанализировать результат и где-то его сохранить. если трафика немного, то можно ограничится хэш-массивами. а вот если трафика сильно до фига, то правильный выбор базы данных -- это отельная задача, не говоря уже за проектирование самой структуры этой базы.

Распарсил, вывел ссылку в окошко. И вся задача

М>и, кстати, вы не ответили на мой коренной вопрос -- чем отличается класс от модуля? в смысле чем он отличается в вашей схеме.

Модуль у меня в первую очередь ассоциируется с файлом. Файл кода = модуль, который другие файлы могут использовать. В модуле могут быть несколько классов, любых абстракций. Например модуль Sniffer, может содержать классы Parser, Listner, функции Init, Finish...Т.е. модуль — это более осязаемое,
чем класс. Класс — задает правила, модуль — их расширяет. Если в глубоком смысле.

М>в общем, не вижу я здесь ООП.

В моей практике, большая часть задач не требует ООП. Просто бери и пиши (фриланс). Однако я следуя советам и опыту старших коллег, в свое время довольно увлекся ООП дизайном, анализом, UML, паттернами. Что-то декомпозировать — пожалуйста! Найду закономерность в 2-х несвязных сущностях. Решить задачу — на втором месте. А мне еще рано до архитектора...