Re[10]: Что-то нетак с ООП
От: Enomay  
Дата: 20.01.12 10:28
Оценка: +1
U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

паттерн декоратор
почитайте GOF, у них есть отличный пример с текстовым редактором.
Re[10]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 20.01.12 10:37
Оценка: +1
Здравствуйте, Undying, Вы писали:

U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.


Вынести лишние ответственности из textBox. Причем для всех клиентов textBox это может быть сделано прозрачно.
лэт ми спик фром май харт
Re[4]: Что-то не так с ООП
От: freestyle  
Дата: 20.01.12 10:40
Оценка: +1
Здравствуйте, Enomay, Вы писали:

RA>>А на каком языке? А можно подробнее, что имеется ввиду?


Я просто хотел сказать, что не использую ООП и при этом у меня нет проблем. А языки я разные использую (так уж приходится). Основную работу пишу на С.

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


Я не понимаю как можно было такой вывод сделать. Моя вас не понимать
Re[7]: Что-то нетак с ООП
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.01.12 10:50
Оценка:
Здравствуйте, netch80, Вы писали:

N>Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.

N>Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
N>Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
N>Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

Ну это просто синтаксический сахар. Возможность вносить процедуры внутрь структур вряд ли выводит нас очень далеко за обычное императивное программирование, речь идет просто о способе записи вызова функции и о способе именования оной.
Re[8]: Что-то нетак с ООП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.01.12 10:59
Оценка: +1
Здравствуйте, 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() различается, это уже классический ООПшный полиморфизм: ты через один указатель единообразно делаешь запросы независимо от того, какая внутренняя реализация базы.
The God is real, unless declared integer.
Re[12]: Что-то нетак с ООП
От: samius Япония http://sams-tricks.blogspot.com
Дата: 20.01.12 11:01
Оценка:
Здравствуйте, Undying, Вы писали:

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


T>>Тут есть два варианта:

T>>1) либо ты нарушил SRP и сам себе злобный буратино, ООП тут не причем. В данном случае класс представляет собой сборную солянку разных ответственностей и ты не можешь в результате повторно использовать реализацию одной из ответственностей, не получив в довесок кучу лишних зависимостей от остальных ответственностей.

U>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого.


Если для чего-то нужна половина класса, то значит декомпозиция не так замечательна.
Re[2]: Java vs. C#
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.01.12 11:14
Оценка: -1 :)
Здравствуйте, Skynin, Вы писали:

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


S>Сам посыл абсурден — куча ПО написано и работает как раз с использованием ООП, но вдруг с ним что-то не так.


S>А с чем извините все так? С ФП? И много на нем написано работающего годами ПО?

S>А может с логическим программированием все замечательно?

Ну не знаю... Я вот посмотрел на тот софт, с которым работаю, исходники которого могу глянуть. Получилось nginx, gcc, bash, vim, TeX. Почти везде преобладает православный Ц. Иногда проскальзывают скриптовые языки (Tcl, Python, Perl). Качество софта не вызывает нареканий.
Re[7]: Что-то нетак с ООП
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 20.01.12 11:27
Оценка:
Здравствуйте, Enomay, Вы писали:

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


E>[поскипано]


E>тут нужно определится, что важнее для конкретной задачи.


Есть директория, в которой 100 000 файлов. Их надо все обработать и напечатать, сколько файлов было обработано. Это все прекрасно можно сделать с использованием счетчика и FindFirst/FindNext. А теперь предположим, что у нас есть прекрасный класс Directory, скрывающий доступ к FindFirst/FindNext. Какие методы должны быть в нем и как они должны быть реализованы, чтобы избежать накладных расходов (повторное сканирование директории, хранение списка файлов, ...)
Re[13]: Что-то нетак с ООП
От: Vaako Украина  
Дата: 20.01.12 11:31
Оценка: +1
Здравствуйте, mrTwister, Вы писали:

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


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


T>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.


А я постоянно это наблюдаю
Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.
Re[4]: Что-то не так с ООП
От: WolfHound  
Дата: 20.01.12 11:50
Оценка:
Здравствуйте, Enomay, Вы писали:

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

Ну, так ты покажешь, как реальные пацаны код пишут или, так и запишем что весь этот твой реюз исключительно языком?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Что-то нетак с ООП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.01.12 12:26
Оценка: +2
Здравствуйте, Artifact, Вы писали:

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


S>>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.


A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.


Вообще повторное использование большого куска кода, не спроектированного для этого изначально, невозможно. Лет 30 назад апологеты ООП пытались утверждать обратное, но практика показала что хорошо реюзаются только маленькие куски кода. Поэтому и были придуманы паттерны проектирования, SOLID и прочее.
Re[14]: Что-то нетак с ООП
От: Enomay  
Дата: 20.01.12 13:10
Оценка:
T>>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.

V>А я постоянно это наблюдаю

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

проблема в том, кто эту самую декомпозицию, с нарушением SRP, проводит
Re: Что-то нетак с ООП
От: amg  
Дата: 20.01.12 13:12
Оценка:
Здравствуйте, Artifact, Вы писали:
...

А почему ООП противопоставляется ФП?
По-моему ООП — следующий шаг развития языков программирования.
Если начать с простых определений, то:
набор инструкций можно объединить в подпрограммы/функции, для объединения множества переменных(данных) есть record.
Класс всего лишь объединяет функции и данные — и это основная задача ООП.
Это и добавляет сложность — для проектирования иерархии классов нужно оперировать бОльшим количеством понятий.
Re[2]: Что-то нетак с ООП
От: RedApe Беларусь  
Дата: 20.01.12 13:51
Оценка:
Здравствуйте, amg, Вы писали:

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

amg>...

amg>А почему ООП противопоставляется ФП?

amg>По-моему ООП — следующий шаг развития языков программирования.

Кажется уже второй человек в теме считает что функциональное программирование = процедурное программирование. Это не так.
--
RedApe
Re: Встреча на Эльбе, гы-гы
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 00:05
Оценка: 38 (4) :)
Здравствуйте, Artifact, Вы писали:

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием.


Ответ на твой вопрос был сформулирован аж в далёком 1993 году
Автор: Геннадий Васильев
Дата: 29.11.05
(словарь-справка
Автор: Геннадий Васильев
Дата: 29.11.05
). Прошу прощения за самоцитирование.

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


Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой. Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось! Хотя да, в известном смысле ООП приближено к образным структурам мышления обычного человека, вся проблема в том, что программированием занимаются необычные люди и это — статистически подтверждаемый факт. Отсюда регулярная грызня за самую правильную иерархию, за самый правильный "взгляд" и многая-многая другая фигня. Говоря другими словами — ОО-стиль вобрал в себя уйму сугубо интуиционистского мусора (взять те же паттерны, которые только, что не в одно место засовывают) и что характерно, "лучшие" ОО-структуры почему-то с точностью до деталей похожи на пребанальнейшую декомпозицию "данные vs. действия", но отнюдь не на "активные данные". Ну, так получилось, никто не виноват, что стиль мышления "обычного" человека вызывает уйму вопросов у "необычных" людей. Короче говоря — стиль мышления идиота обычного человека очень трудно рационализируется нормальным программистом. Но! ООП имплицитно апеллирует именно к идиотскому "обычному" стилю мышления и выражения своих мыслей. Это прекрасная игра, мастера которой которой достойны всяческого восхищения, но...

Здесь мы логически выходим на первопричину проблем ООП как культурного явления — изначальную апелляцию не столько к простоте, сколько к упрощенчеству. Отсюда — дебильный корневой Object, отсюда же — не к ночи будь повторно помянутые паттерны и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.

Собственно говоря, ООП — это в принципе вторичная штука. Родилось где-то в недрах исследований ИИ, было подхвачено Аланом Кеем (или наоборот — Кей первым сформулировал принципы ООП, а потом уже... Неважно.) и дальше понеслась.

Нет, я не спорю: ООП удачно и полезно когда оно базируется на строигх формальных выкладках. То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п. Проблема в другом. Телега по имени Осмысление в ООП почему-то часто ставится впереди лошади по кличке Формальная Декомпозиция. Отсюда всё то, что я выше назвал интуиционистским мусором: что кому в башку наглючило, тот такую иерархию и закодировал. Исключение тут составляет А.Степанов, которому в горячечном бреду привиделся вполне натуральный CLOS, воплощённый в C++ (кстати, настоятельно рекомендую проштудировать спецификацию CLOS, сильно прочищает мозги по части "новомодных штучек", которые на поверку многим в бабушки годятся).

Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Встреча на Эльбе, гы-гы
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 00:12
Оценка: +1
ГВ>Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой.

Вернее так: самая безобидная обезьяна становится обезьяной с гранатой, когда она "поняла ООП". И это, граждане-товарищи, крайне серьёзно, потому что нельзя понять то, что не имеет точного определения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: OOP is technically unsound
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 00:21
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

A>>Я сильно начинаю сомневаться в полезности ООП.

I>Не ты один, вот к примеру цитата из интервью с автором STL.

[skip]

Степанов — умница. Это те нечастые люди, которые не стесняются называть г..но — г..ном.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Встреча на Эльбе, гы-гы
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 00:55
Оценка:
ГВ>Ответ на твой вопрос был сформулирован аж в далёком 1993 году
Автор: Геннадий Васильев
Дата: 29.11.05
(словарь-справка
Автор: Геннадий Васильев
Дата: 29.11.05
). Прошу прощения за самоцитирование.


Подумал некоторое время, переaормулировал lkz rhfnrjcnb. Понимаешь ли, в чем проблема: мы — играли в "парадигмы" и прочую балабонь, а вы — слишком серьёзны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 00:57
Оценка:
ГВ>Подумал некоторое время, переaормулировал lkz rhfnrjcnb.

Подумал некоторое время, переформулировал для краткости.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Что-то нетак с ООП
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 01:43
Оценка:
Здравствуйте, supacrazypusher, Вы писали:

A>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.

S>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.

Угу, поскольку если в это вникнуть, то можно попасть в психушку (если ты не силён духом и не исполнен цинизма). Плавали, знаем.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.