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

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

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

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

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

А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

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

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

OK. Предложи какой-нибудь численный критерий оценки структурной сложности, который мы могли бы применить к существующим системам. Взять open source проект в процедурном стиле, например, и сравнить его с проектом в ОО стиле. Без общепринятного критерия мы вынужденны оперировать общими соображениями и косвенными данными. По поводу того, какой подход преобладает на рынке, можно посмотреть количество вакансий на разные языки.

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

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

Тоже самое. Предложи объективный критерий оценки, буду очень рад.

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

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

Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

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

Да. А что не так?

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

G>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

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

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

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

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

SON>OK. Предложи какой-нибудь численный критерий оценки структурной сложности, который мы могли бы применить к существующим системам. Взять open source проект в процедурном стиле, например, и сравнить его с проектом в ОО стиле. Без общепринятного критерия мы вынужденны оперировать общими соображениями и косвенными данными.
Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

SON>По поводу того, какой подход преобладает на рынке, можно посмотреть количество вакансий на разные языки.
Не думаю что кол-во вакансий будет как-то определять преобладание подхода. Ведь не запрещено писать ООП на C или процедурно (или функционально) на C#.

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

SON>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

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

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

SON>Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

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

SON>Да. А что не так?
Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

Википедия говорит что structural complexity это о классах вычислительной сложности. На рсдн

Автор(ы): Игорь Ткачёв
Дата: 06.12.2002

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

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

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

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

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

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

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

G>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

Кошерное ООП здесь

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

S>Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

Да ничего интересного на самом деле, обычная субъективщина. Последнее время приходится работать с огромным объемом легаси кода 15-20летней давности и меньшим объемом современного вплоть до 4го фреймворка. Эволюция парадигм как на ладони.

SON>>По поводу того, какой подход преобладает на рынке, можно посмотреть количество вакансий на разные языки.
S>Не думаю что кол-во вакансий будет как-то определять преобладание подхода. Ведь не запрещено писать ООП на C или процедурно (или функционально) на C#.

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

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

SON>>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
S>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще.
Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.

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

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

SON>>Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

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

SON>>Да. А что не так?
S>Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

Возможно, увидел у Макконелла. К сожалению, книги нет под рукой, чтобы проверить точное определение. Если упрощенно, то это количество сущностей в программе и их взаимосвязей. Но, например, глобальная переменная, которая меняется неявно в 10 местах, сильно увеличивает сложность. Так что тут имеет место быть еще и качественная составляющая.

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

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

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

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

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

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

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

G>>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

T>Кошерное ООП здесь

Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

Кроме того они не дают представления о процессе ОО-программирования.

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

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

S>>Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

SON>Да ничего интересного на самом деле, обычная субъективщина. Последнее время приходится работать с огромным объемом легаси кода 15-20летней давности и меньшим объемом современного вплоть до 4го фреймворка. Эволюция парадигм как на ладони.
А, тогда более-менее понятно. Т.е. выводы основаны на сравнении кода 15-20 летней давности (на чем, если не секрет?) и относительно свежего. ИМХО, в таком случае мог повлиять не только парадигм-шифт, сколько само по себе развитие библиотек/фреймворка. Уже одна только библиотека хороших контейнеров может значительно упростить код, написанный без нее. В дотнете библиотека контейнеров скорее объектно ориентирована, но не без признаков функциональого подхода. А могла бы иметь более функциональный уклон. Так вот, мысль в том, что само использование библиотеки не означает изменение парадигмы, и можно продолжать писать в процедурном подходе используя ОО или ФП библиотеки. Уже только от этого код может оказаться проще, чем оригинальный 20-летний.
Это не говоря уже о том, что даже в рамках одной парадигмы и одного набора библиотек код одного человека может существенно отличаться от кода другого (или того же, но спустя несколько лет) в аспекте сложности.

S>>Не думаю что кол-во вакансий будет как-то определять преобладание подхода. Ведь не запрещено писать ООП на C или процедурно (или функционально) на C#.

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

В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.

SON>>>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
S>>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

SON>Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще.
Согласен
SON>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.
Нужно выбрать метрики, которые имеют смысл для разных подходов. Так, если мы возьмем метрику, учитывающую взаимосвязь классов, то куда ее прикладывать в ПП? А если будем учитывать лишь связи функций и структур данных, то может оказаться что ОО не дает существенного упрощения согласно таким метрикам.

S>>Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

SON>Возможно, увидел у Макконелла. К сожалению, книги нет под рукой, чтобы проверить точное определение. Если упрощенно, то это количество сущностей в программе и их взаимосвязей. Но, например, глобальная переменная, которая меняется неявно в 10 местах, сильно увеличивает сложность. Так что тут имеет место быть еще и качественная составляющая.
Полистал Макконелла — навскидку не нашел.
Глобальная переменная — отличный пример сложности. Только сложно сказать, для какого из подходов она более характерна? Во времена ПП их не боялись и использовали достаточно широко. И только. Т.е. если в ПП не будем использовать глобальные переменные слишком широко, то все еще останемся в рамках ПП.
(я работал в институте, где 64-килобайтный файл объявлений глобальных переменных был вариантом нормы, т.е. никого особо не удивлял. Но это не проблема ПП вцелом, это проблема конкретных разработчиков)

Что нам предлагает ОО в отношении глобальных переменных? Положить ее в класс? Вобщем-то ничего особенно и не изменилось по сравнению с ПП. Скрыть доступ к глобальной переменной и инкапсулировать работу с ней? Мы могли это сделать и в ПП тоже.
Самое мудрое решение в отношении глобальной переменной предлагает ФП — избавиться от нее. Точно так же мы можем не использовать ее в ОО/ПП.
Т.е. как только в отношении глобальной переменной мы принимаем что она увеличивает сложность больше чем добавление параметров к методам и избавляемся от нее вне конкретного подхода, так сразу рассмотренные подходы становятся ближе друг к другу в этом отношении.
В конце концов, после того как мы примем несколько правильных решений, может оказаться что разница в подходах сведется к синтаксической. Вопрос лишь в том, на сколько далеко мы пойдем. Наверняка ведь захочется остаться в рамках теплого и привычного подхода.

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

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

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

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

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

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

Я почитал соседнюю дискуссию, чтобы не повторяться. В общем — крайне спорное утверждение.

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

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

Скорость разработки и лёгкость освоения, ИМХО, относятся к стилю программирования (а всё, что ты назвал — это именно стили) как... Короче, слабовато относятся. Ну а структурную сложность программ нужно измерять на эквивалентных программах, иначе это чистые домыслы.

Хотя тот же самый Буч утверждал, что хороший структурный проект (т.е. — оформленный в стиле структурного программирования) ничуть не хуже объектно-ориентированного, тем более — плохого объектно-ориентированного проекта. Проблема, собственно, сводилась к тому, что среди структурных программ чаще встречались ходячие ужасы, чем среди ОО-программ. Во всяком случае, так было во времена расцвета ОО-апологии. Ну, сейчас, как видим, положение выправляется.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ГВ>>Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось!
ANS>Откуда дровишки? У IBM её среда стоила бешеных бабок. Домохозяйка скорее б удавилась... Еще я понимаю такое про REXX написать, и то...

Из какой-то книжки второй половины 80-х.

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

Хе-хе. Я могу и ошибаться.

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

Причина чего?

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

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

.

ИМХО, твой пример — это пример на свободную функцию, а не на метод: Доить(Доярка, Корова). Ну или как вариант — это может быть мультиметод. Не в объектном стиле, зато просто и понятно.

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

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

Возможно.

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

T>>Кошерное ООП здесь

G>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

G>Кроме того они не дают представления о процессе ОО-программирования.

Если бы эти принципы можно было формализовать до такого уровня, то программисты были бы не нужны. Программы бы писали компьютеры.

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

ГВ>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.

Проверенные временем практики кроме возможности расширения, дают:

1) дешевую модификацию кода (достаточно внести изменение в одно место, а не в сотню)
2) качественную декомпозицию (упрощает разработку)
3) простота изучения кода (чтобы понять, как работает одна фича не надо изучать исходники всей системы)
4) простота локализации ошибок (место положение кода, в котором ошибка, становится понятно из описания ошибки)

и другие полезные вещи, о которых я забыл написать

Здравствуйте, Константин Б., Вы писали:

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

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

Членами каких классов перечисленная функциональность является в Qt?

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

ГВ>в известном смысле ООП приближено к образным структурам мышления обычного человека

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

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


SON>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.

Цикломатическая сложность

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

U>Здравствуйте, Константин Б., Вы писали:

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

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

U>Членами каких классов перечисленная функциональность является в Qt?

QStyle, QTextLayout

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

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

ГВ>Причина чего?

Ну то есть, не "сначала домохозяйки потом рекурсивные определения и пр. беды", а наоборот "сначала рекурсивные определения потом домохозяйки и пр. беды".

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


G>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

Просто, хочу прояснить для себя. Вот тут

Автор: gandjustas
Дата: 10.10.11

ты говорил:

Так вот anemic по формальным свойствам не менее ООП, а учитывая SOLID — даже более ООП, чем рич

Т.е. SOLID выступал критерием степени ООП-нусти а теперь SOLID стал мутным. Это проапгрейдилось твоё мнение или в том посте ты просто так сказал?

ЗЫ. Никогда не понимал, что в SOLID людям нравится, и зачем Д.Боба противопоставляют Фаулеру? С практической т.зрения смысл есть только в LSP, а всё остальное — явная белиберда.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

ANS>Просто, хочу прояснить для себя. Вот тут

Автор: gandjustas
Дата: 10.10.11

ты говорил:
ANS>

Так вот anemic по формальным свойствам не менее ООП, а учитывая SOLID — даже более ООП, чем рич

ANS>Т.е. SOLID выступал критерием степени ООП-нусти а теперь SOLID стал мутным. Это проапгрейдилось твоё мнение или в том посте ты просто так сказал?

А ты контекст того обсуждения прочитай. Там выше оппоненты описывали свое понимание solid.

ANS>ЗЫ. Никогда не понимал, что в SOLID людям нравится, и зачем Д.Боба противопоставляют Фаулеру? С практической т.зрения смысл есть только в LSP, а всё остальное — явная белиберда.
Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.

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

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

ГВ>>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.

T>Проверенные временем практики кроме возможности расширения, дают:

T>1) дешевую модификацию кода (достаточно внести изменение в одно место, а не в сотню)
T>2) качественную декомпозицию (упрощает разработку)
T>3) простота изучения кода (чтобы понять, как работает одна фича не надо изучать исходники всей системы)
T>4) простота локализации ошибок (место положение кода, в котором ошибка, становится понятно из описания ошибки)

T>и другие полезные вещи, о которых я забыл написать

В деталях можно оспорить, но по сути верно: проверенные временем практики как раз вобрали в себя эти самые требования.