Re[7]: Что-то нетак с ООП
От: Undying Россия  
Дата: 19.01.12 10:05
Оценка:
Здравствуйте, netch80, Вы писали:

N>И давно это с ним? Как быть, например, с функцией подключения к DB, в реализации которой жёстко задано имя базы, хост, логин для подключения? Или функцией, которая по завершении сложной работы отправляет отчёт по e-mail? Или привязкой к тому, что данные могут быть только в cp1251?


Это второстепенная проблема, которая решается достаточно легко грамотной декомпозицией. Основная проблема повторного использования функциональности в ООП заключается в следующем.

Есть объект на десяток сущностей, при использовании ООП мы прибиваем к этому объекту гвоздями функциональность требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли, с дальнейшим дублированием кода и прочими прелестями. При использовании чистых функций такой проблемы нет, т.к. если для какой-то функциональности нужны только 3 сущности, то эта чистая функция только 3 этих сущности и будет принимать. А дальше эта чистая функция может использоваться и внутри ООП объекта, и где угодно.

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


ООП как обертка над чистыми функциями это прекрасный инструмент. ООП как функциональность прибитая к объектам это тот еще ужас.
Re[8]: Что-то нетак с ООП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.01.12 10:23
Оценка:
Здравствуйте, Undying, Вы писали:

N>>И давно это с ним? Как быть, например, с функцией подключения к DB, в реализации которой жёстко задано имя базы, хост, логин для подключения? Или функцией, которая по завершении сложной работы отправляет отчёт по e-mail? Или привязкой к тому, что данные могут быть только в cp1251?

U>Это второстепенная проблема, которая решается достаточно легко грамотной декомпозицией.

Простите, при чём тут декомпозиция? От того, что мы разобъём задачу на десяток более мелких, она не станет от этого более гибко реализованной.

U> Основная проблема повторного использования функциональности в ООП заключается в следующем.

U>Есть объект на десяток сущностей,

Уже непонятно, что имеется в виду. При идеальном проектировании одной сущности предметной области или специфики её реализации должен соответствовать один объект. Ладно, пусть у нас тут сплошные криворукие, других не смогли нанять — в одном объекте смешиваются 2-3 сущности или их важные аспекты. Но 10?
Или Вы словом "сущность" обозначили что-то своё особое?

U> при использовании ООП мы прибиваем к этому объекту гвоздями функциональность


Это тоже непонятно — что такое "прибить к объекту функциональность (гвоздями)".

U> требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли,


Я попытаюсь конструктивно понять описанную Вами картину. Итак, имеется в виду, что код рассчитан на некоторую предметную область с её особенностями реализации. Например, если сотрудник пропущен в здание, то об этом должна пойти запись в лог, в центральную базу, в базу отдела и т.д., запущен какой-то пересчёт данных (от базы зарплаты до требований по вентиляции) и так далее. Так?
В таком случае вопросы,
1) зачем это всё прибито было изначально гвоздями в коде?
2) чем это отличается от случая, когда то же самое было бы написано явно в функции?
На первое — рекомендованным для ООП случаем является, когда общий класс какой-то функциональности не имеет никакого подобного фиксированного поведения, а оно создаётся или в производном классе, или уже при генерации объекта за счёт набивания его списков реакций нужными элементами. Второе же — случай значительно менее гибкого построения, которое вообще не регулируется. Ну и чем тут ООП хуже?

Да, я сейчас натеоретизировал на ровном месте, но Вы же ничего внятно не объясняете. Объясните, если я пошёл в неверном направлении.

U>ООП как обертка над чистыми функциями это прекрасный инструмент. ООП как функциональность прибитая к объектам это тот еще ужас.


Вот у меня пока что создаётся обратное впечатление.
Может, приведёте реальный пример?
The God is real, unless declared integer.
Re[8]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 19.01.12 10:28
Оценка: +1
Здравствуйте, Undying, Вы писали:


U>Есть объект на десяток сущностей, при использовании ООП мы прибиваем к этому объекту гвоздями функциональность требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли, с дальнейшим дублированием кода и прочими прелестями.


И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP
лэт ми спик фром май харт
Re[9]: Что-то нетак с ООП
От: Undying Россия  
Дата: 19.01.12 11:04
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP


В этом виновато именно ООП, т.к. декомпозиция тут ничем помочь не может. Т.к. первая функция требует, к примеру, 1 и 2 сущности, вторая функция 4, 5 и 7 сущности, третья функция — 1, 5, 6 и 7 сущности. И чем тут ООП может помочь? Как эти сущности в классы не объединяй все равно проблемы с повторным использованием функциональности этих классов в будущем вылезут.
Re[7]: Что-то нетак с ООП
От: Vaako Украина  
Дата: 19.01.12 11:11
Оценка:
Здравствуйте, Enomay, Вы писали:

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


V>>Дак если бы было понятно. Хотелось бы.


E>давайте вы приведете какие-то примеры кода, с проблемами. так будет понятнее.

E>а пока это просто размышления.

Проблема не в коде (имхо) а в куче предварительных рассуждений. И это касается не только ООП.
Re[6]: Что-то нетак с ООП
От: batu Украина  
Дата: 19.01.12 11:14
Оценка: -4
Здравствуйте, mrTwister, Вы писали:

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


B>>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.


T>Ну то есть конкретных примеров нет, правильно я понимаю?

Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?
Re[3]: Что-то нетак с ООП
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 19.01.12 12:51
Оценка:
A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

Такое бывает при неправильном использовании классов и отсутствии архитектуры. Обычно используется высокоуровневая архитектура приложения, которая однозначно определяет как связываются между собой части программы. Для примера посмотрите как построен Qt Creator — он ольшой, в нем сотни классов, но при этом связи между ними прозрачны. Потому что архитектура, сигналы и слоты.
Re[7]: Что-то нетак с ООП
От: Privalov  
Дата: 19.01.12 13:00
Оценка:
Здравствуйте, batu, Вы писали:

B>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?


Я программирую не с 82 года. Тем не менее, мне доводилось работать с исходниками на Коболе, датированными 1974 годом. В них процедуры уже использовались. Несколько раньше я работал с фортрановским кодом, который начали писать примерно тогда же. Подпрограммы и функции тоже использовались.
Другое дело, что кто-то мне советовал не злоупотреблять вызовами подпрограмм, дескать, он занимает много времени, которое дорого. И да, я видел программы, где 5000 строк и больше находились в одной процедуре.
Re: Что-то нетак с ООП
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 19.01.12 13:03
Оценка:
A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке.

Просто вы смотрели код, в котором отсутствует архитектура. Архитектура как раз и определяет в каком порядке и как взаимодействуют фрагменты программы. Посмотрите на досуге исходники Qt Creator.

A>И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше.


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

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


Обычно это делается чтобы подстраховаться на будующее. Никогда не знаешь, какой из проектов и когда "неожиданно начнет бурно развиваться". И чтобы потом не переписывать все с нуля обычно закладывают минимально разумный каркас на расширение.
Re[7]: Что-то нетак с ООП
От: alexlz  
Дата: 19.01.12 13:42
Оценка:
Здравствуйте, batu, Вы писали:

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


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


B>>>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.


T>>Ну то есть конкретных примеров нет, правильно я понимаю?

B>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?
Это что за суперновые процедуры появились в 80е годы. Те, которые были в Алголе-60?
Re: Что-то нетак с ООП
От: freestyle  
Дата: 19.01.12 14:42
Оценка: +1
Здравствуйте, Artifact, Вы писали:

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


Я давно уже отказался от ООП. Пишу программы в функциональном стиле, даже если язык является объектно-ориентированным. И в какой-то момент я понял, что перестал переписывать код и делать архитектурные ошибки. Единственные ошибки которые я иногда допускаю — это опечатки в коде.

A>С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше.


С данным выражением я не могу согласиться. Никогда нельзя писать код "в лоб" (хотя я может не правильно понимаю контекст в котором было употреблено выражение "в лоб").
Re[10]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 19.01.12 20:18
Оценка: +1
Здравствуйте, Undying, Вы писали:

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


T>>И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP


U>В этом виновато именно ООП, т.к. декомпозиция тут ничем помочь не может. Т.к. первая функция требует, к примеру, 1 и 2 сущности, вторая функция 4, 5 и 7 сущности, третья функция — 1, 5, 6 и 7 сущности. И чем тут ООП может помочь? Как эти сущности в классы не объединяй все равно проблемы с повторным использованием функциональности этих классов в будущем вылезут.


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

2) либо ты не нарушил SRP и класс обладает ровно одной ответственностью, в таком случае каждая часть класса просто бессмысленна без всего остального и непонятно, что и зачем ты собрался повторно использовать. Например, у некоторой реализации интерфейса IEnumerable ты собрался повторно использовать метод MoveNext, а свойство Current тебе уже не нужно
лэт ми спик фром май харт
Re[8]: Что-то нетак с ООП
От: batu Украина  
Дата: 19.01.12 21:04
Оценка: 1 (1)
Здравствуйте, Privalov, Вы писали:

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


B>>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?


P>Я программирую не с 82 года. Тем не менее, мне доводилось работать с исходниками на Коболе, датированными 1974 годом. В них процедуры уже использовались. Несколько раньше я работал с фортрановским кодом, который начали писать примерно тогда же. Подпрограммы и функции тоже использовались.

P>Другое дело, что кто-то мне советовал не злоупотреблять вызовами подпрограмм, дескать, он занимает много времени, которое дорого. И да, я видел программы, где 5000 строк и больше находились в одной процедуре.
В первых языках высокого уровня вызов процедур был действительно нагружен. В ассемблерах этих проблем не было. Но была другая проблема с распределением памяти. Могу сказать что в первых машинах вообще не было команд вызова процедур. Потом появились, но адрес возврата сохраняли не в стеке, а, например, в следующей ячейке после команды вызова, и там же оставляли параметры, что приходилось учитывать при возврате из процедуры. Но здесь речь не об этих экзерциссах, а в том что ООП как-то значительно позже появилось. Вот, даже вспомнил.. Была еще промежуточная фишка "Структурное программирование"
Re[8]: Что-то нетак с ООП
От: batu Украина  
Дата: 19.01.12 21:12
Оценка:
Здравствуйте, alexlz, Вы писали:

B>>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?

A>Это что за суперновые процедуры появились в 80е годы. Те, которые были в Алголе-60?
Алгол да.. Но я тут скорее о проблемах реализации этих процедур на ассемблерах и в архитектурах машин. Не во всех были стеки. Это сейчас кажется естественно. Хотя я так задумался. Мне не очень нравится разделение регистров по использованию. Хорошая машина была.. 16 регистров общего пользования. Не помню какая. Спецпроцессор был. Кстати, тогда еще миллион операций струячил.
Re[9]: Что-то нетак с ООП
От: Wolverrum Ниоткуда  
Дата: 19.01.12 23:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>Чтобы каждая функция использовалась хотя бы 5 раз.

Я бы мог показать, но там Powershell и вообще адская императивщина =)
Re[2]: Что-то не так с ООП
От: RedApe Беларусь  
Дата: 20.01.12 09:22
Оценка: +1
Здравствуйте, freestyle, Вы писали:

F> Я давно уже отказался от ООП. Пишу программы в функциональном стиле, даже если язык является объектно-ориентированным. И в какой-то момент я понял, что перестал переписывать код и делать архитектурные ошибки. Единственные ошибки которые я иногда допускаю — это опечатки в коде.


А на каком языке? А можно подробнее, что имеется ввиду?
--
RedApe
Re[3]: Что-то не так с ООП
От: Enomay  
Дата: 20.01.12 09:59
Оценка: 1 (1) -2
F>> Я давно уже отказался от ООП. Пишу программы в функциональном стиле, даже если язык является объектно-ориентированным. И в какой-то момент я понял, что перестал переписывать код и делать архитектурные ошибки. Единственные ошибки которые я иногда допускаю — это опечатки в коде.

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


имеется в виду что человек начал копипастить и под каждую задачу писать новый велосипед. без реюза и всякого прочего
Re[11]: Что-то нетак с ООП
От: Undying Россия  
Дата: 20.01.12 10:13
Оценка:
Здравствуйте, mrTwister, Вы писали:

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

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

В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого. И никакой рефакторинг тут уже ничем помочь не может, т.к. при другая декомпозиция может решить эту проблему, но порождает проблемы с другой функциональностью.
Re[12]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 20.01.12 10:22
Оценка: 7 (2)
Здравствуйте, Undying, Вы писали:

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


Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.
лэт ми спик фром май харт
Re[9]: Что-то нетак с ООП
От: Undying Россия  
Дата: 20.01.12 10:23
Оценка: +1 -1
Здравствуйте, netch80, Вы писали:

N>На первое — рекомендованным для ООП случаем является, когда общий класс какой-то функциональности не имеет никакого подобного фиксированного поведения, а оно создаётся или в производном классе, или уже при генерации объекта за счёт набивания его списков реакций нужными элементами. Второе же — случай значительно менее гибкого построения, которое вообще не регулируется. Ну и чем тут ООП хуже?


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