U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.
паттерн декоратор
почитайте GOF, у них есть отличный пример с текстовым редактором.
Здравствуйте, Undying, Вы писали:
U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.
Вынести лишние ответственности из textBox. Причем для всех клиентов textBox это может быть сделано прозрачно.
Здравствуйте, Enomay, Вы писали:
RA>>А на каком языке? А можно подробнее, что имеется ввиду?
Я просто хотел сказать, что не использую ООП и при этом у меня нет проблем. А языки я разные использую (так уж приходится). Основную работу пишу на С.
E>имеется в виду что человек начал копипастить и под каждую задачу писать новый велосипед. без реюза и всякого прочего
Я не понимаю как можно было такой вывод сделать. Моя вас не понимать
Здравствуйте, netch80, Вы писали:
N>Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB. N>Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C. N>Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов. N>Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)
Ну это просто синтаксический сахар. Возможность вносить процедуры внутрь структур вряд ли выводит нас очень далеко за обычное императивное программирование, речь идет просто о способе записи вызова функции и о способе именования оной.
Здравствуйте, Mystic, Вы писали:
N>>Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB. N>>Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C. N>>Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов. N>>Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)
M>Ну это просто синтаксический сахар. Возможность вносить процедуры внутрь структур вряд ли выводит нас очень далеко за обычное императивное программирование, речь идет просто о способе записи вызова функции и о способе именования оной.
Если для hash, btree и recno хранилища handle->get() различается, это уже классический ООПшный полиморфизм: ты через один указатель единообразно делаешь запросы независимо от того, какая внутренняя реализация базы.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, mrTwister, Вы писали:
T>>Тут есть два варианта: T>>1) либо ты нарушил SRP и сам себе злобный буратино, ООП тут не причем. В данном случае класс представляет собой сборную солянку разных ответственностей и ты не можешь в результате повторно использовать реализацию одной из ответственностей, не получив в довесок кучу лишних зависимостей от остальных ответственностей.
U>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого.
Если для чего-то нужна половина класса, то значит декомпозиция не так замечательна.
Здравствуйте, Skynin, Вы писали:
S>Здравствуйте, Artifact, Вы писали:
S>Сам посыл абсурден — куча ПО написано и работает как раз с использованием ООП, но вдруг с ним что-то не так.
S>А с чем извините все так? С ФП? И много на нем написано работающего годами ПО? S>А может с логическим программированием все замечательно?
Ну не знаю... Я вот посмотрел на тот софт, с которым работаю, исходники которого могу глянуть. Получилось nginx, gcc, bash, vim, TeX. Почти везде преобладает православный Ц. Иногда проскальзывают скриптовые языки (Tcl, Python, Perl). Качество софта не вызывает нареканий.
Здравствуйте, Enomay, Вы писали:
E>Здравствуйте, мыщъх, Вы писали:
E>[поскипано]
E>тут нужно определится, что важнее для конкретной задачи.
Есть директория, в которой 100 000 файлов. Их надо все обработать и напечатать, сколько файлов было обработано. Это все прекрасно можно сделать с использованием счетчика и FindFirst/FindNext. А теперь предположим, что у нас есть прекрасный класс Directory, скрывающий доступ к FindFirst/FindNext. Какие методы должны быть в нем и как они должны быть реализованы, чтобы избежать накладных расходов (повторное сканирование директории, хранение списка файлов, ...)
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Undying, Вы писали:
U>>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого. И никакой рефакторинг тут уже ничем помочь не может, т.к. при другая декомпозиция может решить эту проблему, но порождает проблемы с другой функциональностью.
T>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.
А я постоянно это наблюдаю
Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.
Здравствуйте, Enomay, Вы писали:
E>имеется в виду что человек начал копипастить и под каждую задачу писать новый велосипед. без реюза и всякого прочего
Ну, так ты покажешь, как реальные пацаны код пишут или, так и запишем что весь этот твой реюз исключительно языком?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Artifact, Вы писали:
A>Здравствуйте, supacrazypusher, Вы писали:
S>>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.
A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.
Вообще повторное использование большого куска кода, не спроектированного для этого изначально, невозможно. Лет 30 назад апологеты ООП пытались утверждать обратное, но практика показала что хорошо реюзаются только маленькие куски кода. Поэтому и были придуманы паттерны проектирования, SOLID и прочее.
T>>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.
V>А я постоянно это наблюдаю V>Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.
проблема в том, кто эту самую декомпозицию, с нарушением SRP, проводит
А почему ООП противопоставляется ФП?
По-моему ООП — следующий шаг развития языков программирования.
Если начать с простых определений, то:
набор инструкций можно объединить в подпрограммы/функции, для объединения множества переменных(данных) есть record.
Класс всего лишь объединяет функции и данные — и это основная задача ООП.
Это и добавляет сложность — для проектирования иерархии классов нужно оперировать бОльшим количеством понятий.
Здравствуйте, amg, Вы писали:
amg>Здравствуйте, Artifact, Вы писали: amg>...
amg>А почему ООП противопоставляется ФП? amg>По-моему ООП — следующий шаг развития языков программирования.
Кажется уже второй человек в теме считает что функциональное программирование = процедурное программирование. Это не так.
Здравствуйте, Artifact, Вы писали:
A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием.
). Прошу прощения за самоцитирование.
A>С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой. Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось! Хотя да, в известном смысле ООП приближено к образным структурам мышления обычного человека, вся проблема в том, что программированием занимаются необычные люди и это — статистически подтверждаемый факт. Отсюда регулярная грызня за самую правильную иерархию, за самый правильный "взгляд" и многая-многая другая фигня. Говоря другими словами — ОО-стиль вобрал в себя уйму сугубо интуиционистского мусора (взять те же паттерны, которые только, что не в одно место засовывают) и что характерно, "лучшие" ОО-структуры почему-то с точностью до деталей похожи на пребанальнейшую декомпозицию "данные vs. действия", но отнюдь не на "активные данные". Ну, так получилось, никто не виноват, что стиль мышления "обычного" человека вызывает уйму вопросов у "необычных" людей. Короче говоря — стиль мышления идиота обычного человека очень трудно рационализируется нормальным программистом. Но! ООП имплицитно апеллирует именно к идиотскому "обычному" стилю мышления и выражения своих мыслей. Это прекрасная игра, мастера которой которой достойны всяческого восхищения, но...
Здесь мы логически выходим на первопричину проблем ООП как культурного явления — изначальную апелляцию не столько к простоте, сколько к упрощенчеству. Отсюда — дебильный корневой Object, отсюда же — не к ночи будь повторно помянутые паттерны и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.
Собственно говоря, ООП — это в принципе вторичная штука. Родилось где-то в недрах исследований ИИ, было подхвачено Аланом Кеем (или наоборот — Кей первым сформулировал принципы ООП, а потом уже... Неважно.) и дальше понеслась.
Нет, я не спорю: ООП удачно и полезно когда оно базируется на строигх формальных выкладках. То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п. Проблема в другом. Телега по имени Осмысление в ООП почему-то часто ставится впереди лошади по кличке Формальная Декомпозиция. Отсюда всё то, что я выше назвал интуиционистским мусором: что кому в башку наглючило, тот такую иерархию и закодировал. Исключение тут составляет А.Степанов, которому в горячечном бреду привиделся вполне натуральный CLOS, воплощённый в C++ (кстати, настоятельно рекомендую проштудировать спецификацию CLOS, сильно прочищает мозги по части "новомодных штучек", которые на поверку многим в бабушки годятся).
Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой.
Вернее так: самая безобидная обезьяна становится обезьяной с гранатой, когда она "поняла ООП". И это, граждане-товарищи, крайне серьёзно, потому что нельзя понять то, что не имеет точного определения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, igna, Вы писали:
A>>Я сильно начинаю сомневаться в полезности ООП. I>Не ты один, вот к примеру цитата из интервью с автором STL.
[skip]
Степанов — умница. Это те нечастые люди, которые не стесняются называть г..но — г..ном.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Подумал некоторое время, переaормулировал lkz rhfnrjcnb. Понимаешь ли, в чем проблема: мы — играли в "парадигмы" и прочую балабонь, а вы — слишком серьёзны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Подумал некоторое время, переaормулировал lkz rhfnrjcnb.
Подумал некоторое время, переформулировал для краткости.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, supacrazypusher, Вы писали:
A>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. S>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.
Угу, поскольку если в это вникнуть, то можно попасть в психушку (если ты не силён духом и не исполнен цинизма). Плавали, знаем.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!