Здравствуйте, Lloyd, Вы писали:
I>>Здесь Account наделили методами и стало ООП ? Всего то изменились классы и обязанности и теперь класс придется модифицировать по любому поводу.
L>Да, именно. Стало более в ОО-духе.
Разница всего лишь в количестве сущностей которыми моделируется решение задачи. Т.е. разница в детализации.
Здравствуйте, Ikemefula, Вы писали:
L>>Да, именно. Стало более в ОО-духе.
I>Разница всего лишь в количестве сущностей которыми моделируется решение задачи. Т.е. разница в детализации.
Нет. Просто прочитайте определение и примерьте к своему примеру, все встанет на свои места.
Здравствуйте, Lloyd, Вы писали:
I>>Разница всего лишь в количестве сущностей которыми моделируется решение задачи. Т.е. разница в детализации.
L>Нет. Просто прочитайте определение и примерьте к своему примеру, все встанет на свои места.
Здравствуйте, Ikemefula, Вы писали:
L>>Нет. Просто прочитайте определение и примерьте к своему примеру, все встанет на свои места.
I>А не мог бы ты показать, что не так ?
Нет, не мог бы. Определение я привел, теперь все в ваших силах. Дерзайте.
Здравствуйте, Lloyd, Вы писали:
L>>>Нет. Просто прочитайте определение и примерьте к своему примеру, все встанет на свои места.
I>>А не мог бы ты показать, что не так ?
L>Нет, не мог бы. Определение я привел, теперь все в ваших силах. Дерзайте.
Оба примера полностью подходят под определение ООП
Здравствуйте, Ikemefula, Вы писали:
L>>Нет, не мог бы. Определение я привел, теперь все в ваших силах. Дерзайте.
I>Оба примера полностью подходят под определение ООП
Здравствуйте, licedey, Вы писали:
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
Пошли нафиг всех теоретиков и сделай проще-понятнее-удобнее для расширения. По-моему это и есть "внутренняя красивость".
Может там действительно процедурное программирование будет самым простым решением.
Главное, что бы тебе было удобно. Все зависит от задачи, но в большинстве случаев ООП оправдано, говорю как 1С ник, часто хочется применить ООП а неззя.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sorc17, Вы писали:
VD>>Чтобы такого не случалось нужно кроме ООП познать и другие парадигмы. Как минимум имеет смысл освоить ФП, МП/DSL.
S>Посоветуйте, что почитать, чтобы асилить этот МП/DSL? Желательно "для чайников", ибо раньше никогда не пробовал
Из теоретических писаний, пожалуй, Мартин Фаулер.
А так тема очень широкая, так как методы метапрограммирования и DSL-естроения очень разнообразны. От строковой конкатинации и T4, до Nemerle и Lisp.
Ну, и как и все темы в нашей области, эту нужно осваивать не в теории, а на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vaako, Вы писали:
S>>Посоветуйте, что почитать, чтобы асилить этот МП/DSL? Желательно "для чайников", ибо раньше никогда не пробовал
V>Внутренние языки, специфичные для предметной области: V>здесь
Поглядел... Эта статья описывает одну из разновидностей подходов, так называемый fluent-интерфейс. По сути это DSL-ем не является. Это эмуляция средствами языков не имеющих более приличных средств для реализации DSL-е.
Меж тем ДСЛ-и бывают внешними, внутренними и вообще разными. А fluent-интерфейс — это самый простой и беззубый подход.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, -VaS-, Вы писали:
VS>Критерий простой — если программа будет в дальнейшем модифицироваться (изменение и уточнение требований в будущем, либо банальная инкрементальная разработка), то без нормальной архитектуры и хороших тестов это сделать будет невозможно.
Позволь полюбопытствовать, а "нормальная архитектура" и ООП — это одно и то же?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, abibok, Вы писали:
L>>>>Задачу на неделю для фриланса?! Конечно быстрее.
A>>>Что именно — первое или второе? По поводу второго еще можно поспорить, а с первым-то как? Вы давно писали что-нибудь в не-ООП стиле? Мне пришлось бы заставлять писать себя так, и это было бы явно медленнее, не говоря уже об отладке и сопровождении.
L>>А вы уверены, что вы вообще хоть когда нибудь писали в ООП-стиле?
М>полностью поддерживаю. многие языки (не плюсы) имеют ооп чисто для галочки. и ведь живут. к тому же, если мы в плюсах создадим класс "сортировка" (с кучей разных алгосов сортировки), то это будет не ооп, а модульное программирование, потому что "сортировка" это не сущность. это действие, выполняемое над некоторыми сущностями (массивами, списками...). загнать разные методы сортировки в один класс можно, но что мы получим в результате? обыкновенный модуль, но не объект.
М>и потом, если взять два достаточно крупных проекта -- например, Spider Monkey (си) и Google V8 (плюсы), то в первом легко разобраться и с ходу начать дотачивать код под свои нужды. нужно прикрутить логгер -- берем и прикручиваем. а теперь смотрим на приплюснутый код. вообще-то он не совсем приплюснутый. он даже хуже. половина движка java script написана на спец-реализации самого java-script и взаимодействует с приплюснутым кодом очень нетривиальными путями. просто воткнуть fopen/fprintf не получается. и приходится в одном месте создавать новый интерфейс, а в другом месте его юзать. причем данные имеют жутко сложную структуру. итераторы всякие везде... да еще и с разными типами... хосподи. записать аргументы функции в файл -- это кошмар на улице вязов.
L>> Более того, очень многими неглупыми людьми ставится под сомнение его полезность. М>про все ооп не скажу, но вот никак не могу понять -- действительно ли язык программирования должен быть таким сложным, как плюсы? действительно ли у программиста должна болеть голова за виртуальные деструкторы? говорят, что плюсы обеспечивают высокую производительность. и где же она? куча программ на жабе не сильно уступает аналогичным программам на плюсах. хваленный сверхбыстрый движок гугла написан не только на плюсах, но и на жаба скрипте, причем там такие критические фрагменты кода, как, например, операции с массивами. вероятно, на этот шаг пошли по соображениям безопасности. чтобы память не текла и буфера нежиданно не переполнялись.
М>вот я и думаю -- а что мне дадут плюсы, если их выучить? питон мне дал высокую продуктивность и учить его не пришлось (так, полистал книжку на выходных), java script дала высокую портабельность (работает _везде_, включая мобилки и опять без затрат на обучение), чистый си дает производительность, но нам нем пишутся только самые низкоуровневые компоненты, а обвязка -- жаба, питон, руби или скала.
М>у плюсов же -- производительность только в теории, на практике оно тормозит и отжирает память (если, конечно, пользоваться приплюснутыми фичами на полную). программы сложно писать и еще сложнее понимать. с компиляторами и платформами сплошная чехарда. даже плагин для популярных программ обычно нужно писать на том компиляторе, которым собиралась сама программа.
Вы все правильно написало. Однако хотелось бы несколько пометок сделать. Язык не должен быть таким сложным как плюсы. Не при каком раскладе. Это что называется попал в нужное время в нужное место. ГУИ нужен, Сишного кода море, а вот тебе и абстрактность во всей ее красе. struct window {}; make_window_visible хуже ведь Class Window { void Show(); void Hide(); }; Для человека.
Тут как говорится, смешались люди кони. От меня требуют (ну впрочем я и сам привык), писать движок антивируса в ООП-стиле. Т.е. сканирование файла — класс. Загрузка сигнатур — класс. Настройки класс. Разновидности сканирование (память, реестр, мбр) — наследование абстрактного класса ScanTask. Вопрос Зачем? И почему наряду со знание базовых знаний (структуры данных, алгоритмы), знай шаблоны проектирования.
Есть же задачи (большинство их), где ООП замедляет процесс разработки. Иногда ломаешь голову, чтобы подогнать компоненты системы под иерархию наследования. Или вся эта виртуальность. Ну библиотечное это все течение. Я уже отписывал на хабре, что С++ для реализации задач и С++ для библиотек — это разные языки. Можно сказать, что первое — это повседневный язык студента, а второй преподавателя.
Я негодую....А еще этот ворох старья тянущейся с 70-ых годов...
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, licedey, Вы писали:
L>>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость М>смотря, что за задача. кстати, а чем класс от объекта отличается? и чем они вместе отличаются от модулей?
У меня любая задача так. Уж чему научился по книжкам ООП ин депс, тем и владею. От того и получается. Задача: напиши снифер 80-го протокола, чтобы уловить откуда видео идет. Я написал 3 класса: NetworkAdapterDetector, FlashSniffer, и TrackingURL. Ну думаю вы понимаете, что каждый из них делает. В тоже время, мой аппонент, Модифицировал существующий код. Ну я потратил на это все 30 часов. Он около 15-ти. Мой эстетичней, документированней и "разделяй и влавствуй". Его вроде бы как работает. Вот собственно предпосылка этого поста. Программировать на время, или на качество, с заделом на будущее. Под вопросом, нужно ли это заказчику.
>> не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. М>смотрю, какие сущности и какой функционал мне потребуется для решения. и начинаю реализовывать это отдельными модулями, максимально абстрагированными друг от друга, а потом свожу их воедино. но это _сильно_ зависит от задачи. создание "с нуля" подразумевет, что этого еще никто не делал (или делал, но недоделал) и потому сначала нужно провести ресерч. потом заточить прототип. вы сочинения в школе тоже начисто сразу писали? или нет? наверное черкали, резали, а потом выбрасывали, меняли местами и склеивали. так и в программировании. начисто с нуля ничего не делается.
Ну все равно, нажимаем же File->Add new item. потом уже дальше думаем. Мне больше с нуля нравится, когда за каждую строчку сам отвечаешь. И в случае чего, быстрей костыль подставлю.
>> Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри. М>зависит от того кому это поддерживать
Как правило, фриланс на том строится — вошел в доверие к заказчику — сам и сопровождай. А иначе, деньгу бери и бай бай.
Здравствуйте, 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. если же нужно извлечь ссылки на видео еще до того как их начнут смотреть -- пишем парсер.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, licedey, Вы писали:
L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд. L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.
Да, ты угадал. ООП совсем не подходит для проектирования программ.
Здравствуйте, Lloyd, Вы писали:
L>Потому что имеем разнесение данных и способов работы с ними.
Не всех данных, а только модели данных приложения. И причина не в плохом ООП, а в том простом факте, что модель данных меняется намного реже модели обработки этих данных.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
L>>Потому что имеем разнесение данных и способов работы с ними.
AVK>Не всех данных, а только модели данных приложения. И причина не в плохом ООП, а в том простом факте, что модель данных меняется намного реже модели обработки этих данных.
Я никогда не понимал, что означает эта фраза.
От того, что мы замесим в один класс и хранимые поля, и методы работы с ними, что от этого модель данных начнет меняться чаще?
Или если мы делаем проект, про который мы гарантированно знаем, что модель данных не будет меняться, то что ООП начнет "блистать во всей красе"?
Я могу еще понять аппеляцию к SRP, но не эту же мутную фразу приводить в кач-ве аргумента.
По моему мнению, с "процедурным" подходом получается все как-то проще, чем в тру-риче. Уже за это стоит его любить.
Здравствуйте, Lloyd, Вы писали:
L>От того, что мы замесим в один класс и хранимые поля, и методы работы с ними, что от этого модель данных начнет меняться чаще?
Да. Ведь теперь она — одно целое с методами обработки.
L>Или если мы делаем проект, про который мы гарантированно знаем, что модель данных не будет меняться, то что ООП начнет "блистать во всей красе"?
Не понял вопроса.
L>Я могу еще понять аппеляцию к SRP, но не эту же мутную фразу приводить в кач-ве аргумента.
Фраза кристалльно прозрачная. Просто понимать ее нужно буквально и не искать скрытый смысл.
L>По моему мнению, с "процедурным" подходом получается все как-то проще, чем в тру-риче. Уже за это стоит его любить.
Еще раз — дело не в процедурный vs ООП. Дело в правильном построении объектной модели. Грамотному выбору соотношения coupling и cohesion. Т.е. все как обычно в ООП.
Точно та же ситуация, для примера, в SOA — контракты сервисов нужно менять реже просто в силу исходных требований. Отсюда — переход от OORPC к SOA. При этом за границами контрактов сервисов нам резать связи так сильно уже не нужно — ответные части менять намного проще.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Lloyd, Вы писали:
L> Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
Пример из насквозь оопшного DDD ты назвал неоопшным
Здравствуйте, Ikemefula, Вы писали:
L>> Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
I>Пример из насквозь оопшного DDD ты назвал неоопшным
