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

EOH>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?
Ну, например, унитаз можно выдернуть из здания и поставить в другое здание. С другой архитектурой и системой канализации.

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

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

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

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

Винформсовский textBox — всего лишь обертка над винапишным. Соответственно все эти задачи решаются кодом написаным на С без всякого ООП.
С другой стороны в совершенно ООП-ном Qt даже выковыривать ничего не придется, всю эту функциональность можно использовать и так.

Ну и вывод из всего этого: притянутыми за уши примерами можно доказать все что угодно.

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

ГВ>Здравствуйте, Son of Northern Darkness, Вы писали:

A>>>И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

SON>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.

ГВ>Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

Красиво сказано! Но какая между ними разница?
Расширяемость = наращивание функционала с минимальными усилиями, и по возможности не трогая существующий код.

SON>>Вот за этим ООП и нужно.

ГВ>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

Здравствуйте, Son of Northern Darkness, Вы писали:

SON>Здравствуйте, Геннадий Васильев, Вы писали:

SON>>>Вот за этим ООП и нужно.

ГВ>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

А вот это утверждение нуждается как минимум в аргументах.

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

S>А вот это утверждение нуждается как минимум в аргументах.

По-моему, это очевидно. Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.
По поводу процедурного программирования... Ну можно, да, только зачем?

ЗOH>>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?
Т>Ну, например, унитаз можно выдернуть из здания и поставить в другое здание. С другой архитектурой и системой канализации.

Туалет и унитаз — штуки хорошие, но немного разные.

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

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

M>>Количество файлов придется подсчитывать самому.
S>И? А что, FindFirst/FindNext уже предлагают какой-то волшебный способ подсчитать его, не заканчивая итерирование?

Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории. Вот и получается, что или (а) класс работает неэффективно (б) класс перегружен логикой.

Здравствуйте, Son of Northern Darkness, Вы писали:

A>>>>И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
SON>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.

ГВ>>Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

SON>Красиво сказано! Но какая между ними разница?

Огромная — как между "кажется" и "есть на самом деле".

SON>Расширяемость = наращивание функционала с минимальными усилиями, и по возможности не трогая существующий код.

Если такая возможность реализовалась, то из этого прямо следует, что некоторые способы "расширения" были предусмотрены изначально. Не правда ли?

SON>>>Вот за этим ООП и нужно.
ГВ>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

Наиболее эффективный среди каких инструментов (назови хотя бы три)? По каким критериям оценивается эффективность?

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

ГВ>>Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

EOH>На мой предвзятый взгляд они ортогональны. Не помню, чтобы основным достоинством ООП считали возможность повторного использования кода.

Скажем так, в контексте этого обсуждения reusability — злостный онтопик. Считать ли это каким-то особенным достоинством ООП — не знаю, здесь много мнений имеется. Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков". Так что, равны между собой ООП и reusability, или нет — это зависит от того, какую идеологему принять за точку отсчёта.

EOH>ООП был создан и используется с единственной целью — борьбы с complexity problem, а точнее с композицией больших сущностей из фрагментов и взаимодействие с этими большими сущностями как с единым целом. То, что кто-то бегает и кричит про повторное использование кода... Люди вообще любят бегать и кричать .

Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

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

Иными словами — это такие программы, в которых повторное использование компонентов прямо предусмотрено заранее.

ГВ>>Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание

Автор: Artifact
Дата: 18.01.12

всё-таки довольно близко к истине:
ГВ>>

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

EOH>ООП вроде как != повторному использованию кода?

С этим, вроде бы, никто не спорит.

ГВ>Если такая возможность реализовалась, то из этого прямо следует, что некоторые способы "расширения" были предусмотрены изначально. Не правда ли?

Применение проверенных практик часто решает этот вопрос автоматически. Это могут быть паттерны GoF, личные изобретения или просто здравый смысл.

SON>>>>Вот за этим ООП и нужно.
ГВ>>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

ГВ>Наиболее эффективный среди каких инструментов (назови хотя бы три)?

Смотри мой ответ в соседнем сообщении: ПП, ФП, ООП.

ГВ>По каким критериям оценивается эффективность?я бы три)? По каким критериям оценивается эффективность?

Скорость разработки, структурная сложность программы, легкость освоения и применения. Сойдет?

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>А вот это утверждение нуждается как минимум в аргументах.

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

SON>Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.
Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

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

SON>По поводу процедурного программирования... Ну можно, да, только зачем?
Я хотел взглянуть на объективные причины делать такое утвреждение

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

SON>>По-моему, это очевидно.
S>Очевидно употребляется вместо "взгляните, доказательство этого утверждения тривиально и лежит на поверхности". И само по себе весу утверждению не добавляет и заменой доказательству не является.

Мне очевидно, что положение дел на рынке ПО таково а не другое по вполне объективной причине. Цене разработки.

SON>>Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.
S>Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

Судя по судьбе F#, пока что нет.

S>Я бы даже и согласился с тем что ООП эффективный инструмент, но, имхо, это субъективно, т.е. без оговорки "при определенных обстоятельствах, учитывая следующие факторы" такое утвреждение всерьез не воспринимается.

"При определенных обстоятельствах."

SON>>По поводу процедурного программирования... Ну можно, да, только зачем?
S>Я хотел взглянуть на объективные причины делать такое утвреждение

Инкапсуляция на уровне модулей, отсутствие динамического полиморфизма, данные и методы работы над ними никак не связаны.

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>Очевидно употребляется вместо "взгляните, доказательство этого утверждения тривиально и лежит на поверхности". И само по себе весу утверждению не добавляет и заменой доказательству не является.

SON>Мне очевидно, что положение дел на рынке ПО таково а не другое по вполне объективной причине. Цене разработки.
Позвольте, мы говорили об эффективности инструмента в отношении снижения структурной сложности программ, а не о положении дел на рынке и цене разработки. Что до рынка, то у меня есть уверенность в том что процедурный подход преобладает.

S>>Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

SON>Судя по судьбе F#, пока что нет.
Судьба F# не является объективным инструментом оценки эффективности в отношении снижения структурной сложности. Что касается субъективных ощущений — так по мне с F# куда проще бороться со сложностью, чем с C#.

S>>Я бы даже и согласился с тем что ООП эффективный инструмент, но, имхо, это субъективно, т.е. без оговорки "при определенных обстоятельствах, учитывая следующие факторы" такое утвреждение всерьез не воспринимается.

SON>"При определенных обстоятельствах."

SON>>>По поводу процедурного программирования... Ну можно, да, только зачем?
S>>Я хотел взглянуть на объективные причины делать такое утвреждение

SON>Инкапсуляция на уровне модулей
Присутствует, и что с ней?

SON>отсутствие динамического полиморфизма
Как так? Функции с одной сигнатурой заменяемы, в том числе динамически.

SON>данные и методы работы над ними никак не связаны.
Связаны тем что методы работают с данными. Какая еще связь нужна? Положить метод в данную? Вы это называете снижением структурной сложности?

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

M>Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории.
Я не понял, откуда взялась такая задача. Нижележащий API не предоставляет таких сервисов. Откуда взялись ожидания от ООП как-то улучшить ситуацию по сравнению с этим?
Чтоб два раза не вставать: также не стоит ожидать от "библиотечного класса" для расчёта FFT производительности лучше, чем O(NlogN).

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>А вот это утверждение нуждается как минимум в аргументах.

SON>По-моему, это очевидно. Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.

Это потому, что туда добавляют "элементы". Haskell такой не потому, что там лямбдочку добавили, а потому, что всё в совокупности.

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

ГВ>Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось!

Откуда дровишки? У IBM её среда стоила бешеных бабок. Домохозяйка скорее б удавилась... Еще я понимаю такое про REXX написать, и то...

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

нет

ГВ>отсюда же — не к ночи будь повторно помянутые паттерны

нет

ГВ>и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.

"рекурсивные определения" это, как бы, не следствие, а причина.

ГВ> То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п.

Это антипатерн

Автор: Andrei N.Sobchuck
Дата: 20.06.06

.

ГВ>Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?

Во времена, когда профессия программиста была элитной не было процедурного кода.

EOH>>ООП был создан и используется с единственной целью — борьбы с complexity problem, а точнее с композицией больших сущностей из фрагментов и взаимодействие с этими большими сущностями как с единым целом. То, что кто-то бегает и кричит про повторное использование кода... Люди вообще любят бегать и кричать .
ГВ>Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

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

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

Так что я только на него отвечал и высказывал свое мнение по поводу необходимости архитектуры. Про повторное использование и кубики — это не ко мне .

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

M>Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории. Вот и получается, что или (а) класс работает неэффективно (б) класс перегружен логикой.
На всякий случай напомню, что обсуждался фрагмент про

если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза

Выход — в том, что нет никаких таких "правил ООП", по которым мы вынуждены перечитывать директорию два раза.
Там далее по тексту идут всякие приседания, связанные с тем, что кто-то очень хочет иметь функцию "длина" там, где длины нету.
Если её нету — значит не надо её делать. Неспроста в интерфейсе IEnumerable нет свойства Count.

E>>паттерн декоратор

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

ты очень плохо знаешь как написаны вин форм контролы

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.

U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.

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

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

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

Получается, потому что есть модное слово ООП, и под веянием моды пихают классы куда ни попадя Вдалбливают сначала преподы в вузах, потом коллеги-невежды, наслушавшиеся тех же преподов или начитавшихся какого-нить Фаулера и прочую ересь.

Вдолбить истину не получится, до этого либо дойти мозгом либо помереть в неведении. Можно лишь помочь человеку дойти до истины, повести его, другого пути нет.