Здравствуйте, AndrewVK, Вы писали:
ГВ>>Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков" AVK>Ты спутал ООП и КОП.
Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.
Это просто некоторое время многие КОП и ООП, путали, потому что подавляющее большинство реализаций КОП было поверх ООП. Для КОП нужен модуль, а не объект. Поэтому КОП прекрасно реализауетя на необъектной Модуле, но весьма скверно на объектных плюсах.
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, мыщъх, Вы писали:
G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки? G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка". М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен
Покажи что за книга. Это полнейший бред. Максимум что я видел — когда есть общий предок "Figure".
Здравствуйте, gandjustas, Вы писали:
G>Сложно сказать. Все новое хорошо забытое старое. Если не верить всему что читаешь, а пытаться сопоставить с современными реалиями. Полезное можно найти и у фаулера, и у мартина, и у банды четрырех. Но надо думать головой.
видимо думать надо исключительно *вашей* головой, потому что все остальные думают неправильно, включая упомянутых Фаулера, Мартина и GoF.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Б., Вы писали:
КБ>>Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли. КБ>>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.
FR>http://msdn.microsoft.com/en-us/library/dd162480(v=vs.85).aspx
в каком месте она чистая и не-ООПшная ?
большая часть WinAPI это чистое OOP, просто this передается в виде непрозрачного хендла, в данном случае HDC
Ни в каком ни чистая, но и не ООП'ная. ОО'шных функций в WInAPI (та же обработка сообщений, хендлы, не говоря уже
о COM) функций полно, но эту конкретно к таким только с натяжкой можно отнести.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Сложно сказать. Все новое хорошо забытое старое. Если не верить всему что читаешь, а пытаться сопоставить с современными реалиями. Полезное можно найти и у фаулера, и у мартина, и у банды четрырех. Но надо думать головой.
A>видимо думать надо исключительно *вашей* головой, потому что все остальные думают неправильно, включая упомянутых Фаулера, Мартина и GoF.
Нет, думать надо своей, а некоторые предпочитают чьей-то другой. Фаулер, Мартин и GoF — они пишут красиво, но не всегда правильно, и не всегда актуально.
Здравствуйте, Undying, Вы писали:
U>Проблема излишней инкапсуляции может возникнуть и в чистых функциях, и в ООП. Ее разрешение также возможно и там, и там при соизмеримых усилиях.
Принципиальная разница именно в проблеме лишнего состояния, которая не разрешима в рамках чистого ООП.
Ты не мог бы подробнее рассказать про "проблему лишнего состояния". А то я не могу понять, что ты имеешь ввиду.
U>Если же пользоваться практически полезным определением — "чистой функцией является такая функция, которая использует только аргументы и имеет право их изменять только следующим из своего названия образом", то все это чистые функции.
То есть если, например, в коболе запретить глобальные переменные, то мы получим чистый функциональный язык программирования?
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.
AVK>Это просто некоторое время многие КОП и ООП, путали, потому что подавляющее большинство реализаций КОП было поверх ООП. Для КОП нужен модуль, а не объект. Поэтому КОП прекрасно реализауетя на необъектной Модуле,
Прежде всего, для КОП нужна инфраструктура, без неё компонентов просто не может существовать. Исполняющая машина Модулы, по-видимому, таковой и является.
AVK>но весьма скверно на объектных плюсах.
Если инфраструктура подразумевает runtime-компиляцию — да, с её реализацией на C++ будут проблемы (нюансы замнём для ясности). Если требования runtime-компиляции нет, то вполне можно и на C++, придерживаясь соответствующих API.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, мыщъх, Вы писали:
G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки? G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка". М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен
В книгах по ООП часто приводятся иллюстративные примеры, которые ни в коем случае нельзя считать рецептами. В Архитектуре уже были обсуждения по этому поводу с участием, если не ошибаюсь, Кирилла Лебедева.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, supacrazypusher, Вы писали:
A>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. S>Профит в том, что повышается переиспользование кода
По-моему, это миф, причем вредный. Типа, он еще и геморрой лечит. Человек попробует, геморрой останется неизлеченным, получит предубеждение.
1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH). При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.
3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС. Во втором случае вы изначально понимаете, что есть некоторая оконная сущность, которая что-то "умеет делать" и обладает какими-то свойствами. А ведь это еще полуобъектное API, в котором для HWND отдельный тип завели. Чаще всего дадут int id, и вперед — разбирайся сам.
4. Наконец, ООП требует от программиста определенных навыков. Так называемого понятийного мышления. Умения отделить первичные половые признаки от вторичных, роли от исполнителей и так далее. Про девяносто с лишним процентов слышали? Это ведь и есть первичный признак, который их отделяет от меньшинства. Когда такой большевик берет в руки классы и пытается сделать реюз на несколько проектов, уж лучше бы он простые функции использовал.
5. Погнавшись за реюзом в ООПшном стиле (или просто за "чистотой ООП", без мыслей о реюзе) очень легко простейшие вещи запутать так, что появляется стойкое отвращение от ООП. У меня такие чувства вызывает Java на фоне C#.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, supacrazypusher, Вы писали:
A>>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. S>>Профит в том, что повышается переиспользование кода
SV.>По-моему, это миф, причем вредный. Типа, он еще и геморрой лечит. Человек попробует, геморрой останется неизлеченным, получит предубеждение.
SV.>1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
Не совсем так. Да, принципиально важно в первую очередь, чтобы код был рассчитан на использование не только в исходном окружении разработки — минимум допущений о среде выполнения, разумное расширение возможностей, и так далее. Но есть принципиальные моменты, которые крайне тяжело реализуются в процедурном варианте и легко — в объектном, и в первую очередь это готовность к будущим расширениям. Я уже приводил пример, когда в следующей версии добавляется какой-то новый настроечный параметр: если у нас объект, просто добавится метод для установки этого параметра, а как там оно внутри лежит — неважно. Если функция, придётся делать новую функцию с ещё одним параметром, и так каждый раз. Объектный стиль (даже без ООП, даже в виде WinAPI) решает эту проблему.
SV.>2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH).
Если Вы опять про своё деление на профессионалов и остальных, то да, такой "профессионал" будет стараться использовать всё полностью своё. Но такие цеховики (я намеренно употребляю этот термин) — развивают свою узкую нишу, но тормозят отрасль в целом. Важнее то, что если стоит задача сделать в срок и в заданные ресурсы, а не создать свою нишу на годы вперёд, то им будет проще и легче взять чужое готовое и применить, а уже в случае несоответствия думать, как бы написать своё (или купить с правами на развитие и доработать).
SV.> При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.
Моя практика это опровергает. Ну-ка перепишите мне для каждого проекта libc, openssl и прочие. Что, времени нет? Лучше потерпеть отдельные недостатки, чем пытаться сдвинуть гору в одиночку.
SV.>3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС.
Это уже объектный подход. Даже если не ООП в полной мере.
SV.> Во втором случае вы изначально понимаете, что есть некоторая оконная сущность, которая что-то "умеет делать" и обладает какими-то свойствами. А ведь это еще полуобъектное API, в котором для HWND отдельный тип завели. Чаще всего дадут int id, и вперед — разбирайся сам.
Да, именно способ организации кода. Но от него "профит" во множестве вопросов.
SV.>4. Наконец, ООП требует от программиста определенных навыков. Так называемого понятийного мышления. Умения отделить первичные половые признаки от вторичных, роли от исполнителей и так далее. Про девяносто с лишним процентов слышали? Это ведь и есть первичный признак, который их отделяет от меньшинства. Когда такой большевик берет в руки классы и пытается сделать реюз на несколько проектов, уж лучше бы он простые функции использовал.
Да, это очень существенный аргумент. С другой стороны, есть же и рефакторинг. В некоторых задачах мне лучше получить работающий код, пусть и с ужасным пониманием задачи, а потом его приводить в порядок, чем вообще ничего не получить. Да, у меня есть сотрудники, которым крайне тяжело осмысленно разделить сущности на классы. Но они делают своё дело, и достаточно неплохо. С другой стороны, я сам с собой натыкаюсь на это постоянно: вот тут что-то сделано в расчёте, что будет только такое отношение и только такая связь => надо срочно переделывать. Это нормально, это проблемы осознания и развития.
А к идеям таких сотрудников, о которых Вы говорите, можно и design review применить, указав на явные недостатки.
SV.>5. Погнавшись за реюзом в ООПшном стиле (или просто за "чистотой ООП", без мыслей о реюзе) очень легко простейшие вещи запутать так, что появляется стойкое отвращение от ООП. У меня такие чувства вызывает Java на фоне C#.
Ну а у меня код некоторых коллег на C++. Когда такой в первую очередь думает о том, как объекту завести iterator traits и как его сделать универсальным шаблоном, ещё не зная задач, но при этом у него в кастомном протоколе половина полей BE, а половина LE — хочется пересадить человека на бейсик, чтобы меньше вредил
Здравствуйте, Undying, Вы писали:
U>При использовании чистых функций можно (хотя и требует определенной квалификации) писать так, чтобы отдельные части отпиливались для отдельного использования.
И в сложной среде это делать значительно сложнее, чем при объектном подходе.
Причём достаточно удобно это оказывается делать только на динамических языках — там, где всё устроено для передачи чего угодно любого типа через словарь параметров или property list.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Прежде всего, для КОП нужна инфраструктура
И эта инфраструктура называется модуль.
AVK>>но весьма скверно на объектных плюсах.
ГВ>Если инфраструктура подразумевает runtime-компиляцию — да, с её реализацией на C++ будут проблемы
В Модуле не было runtime-компиляции.
ГВ>Если требования runtime-компиляции нет, то вполне можно и на C++, придерживаясь соответствующих API.
Возможно, но на выходе монстрики типа СОМ или CORBA получаются.
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
Здравствуйте, netch80, Вы писали:
SV.>>1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
N>Не совсем так. ... Я уже приводил пример, когда в следующей версии добавляется какой-то новый настроечный параметр
К своему удивлению, узнал, что это тоже считается реюзом:
The general practice of using a prior version of an extant program as a starting point for the next version, is also a form of code reuse.
Я же полагал, что another program это именно another.
Code reuse is the idea that a partial computer program written at one time can be, should be, or is being used in another program written at a later time.
Что ж, тут вы правы. Если мы рассматриваем новые версии продукта как реюз, мой тезис перестает работать.
SV.>>2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH).
N>Если Вы опять про своё деление на профессионалов и остальных, то да, такой "профессионал" будет стараться использовать всё полностью своё. Но такие цеховики (я намеренно употребляю этот термин) — развивают свою узкую нишу, но тормозят отрасль в целом. Важнее то, что если стоит задача сделать в срок и в заданные ресурсы, а не создать свою нишу на годы вперёд, то им будет проще и легче взять чужое готовое и применить, а уже в случае несоответствия думать, как бы написать своё (или купить с правами на развитие и доработать).
Нет, я просто по жизни. Делю я уже обобщая наблюдения. Вот вы пишете "проще и легче" — когда же программисты ходили простыми и легкими путями?
Кроме того, я не согласен с оценками типа "тормозят отрасль в целом". Это же экономика. Область с неевклидовым пространством. Цели подчас достигаются через самую запутанную "жопу с закоулками", а потом оказывается, что это был кратчайший путь. Функциональное программирование как пошло в народ? В сишарпе лямбды ввели. Цеховики протолкнули, короче.
SV.>> При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.
N>Моя практика это опровергает. Ну-ка перепишите мне для каждого проекта libc, openssl и прочие. Что, времени нет? Лучше потерпеть отдельные недостатки, чем пытаться сдвинуть гору в одиночку.
Как раз, libc, openssl — хорошо известные библиотеки/API. Что ваша практика говорит о модуле Васи из соседнего отдела?
SV.>>3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС.
N>Это уже объектный подход. Даже если не ООП в полной мере.
Вынужден констатировать, что мой пример остался непонятым. Да, это объектный подход. Но что мешает нам считать WinAPI "ООП в полной мере"? Есть ли какой-то признак, который позволит отделять мух от котлет? Да вот же он: "вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС".
Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей. Следовательно, какая-то метаинформация теряется. А раз так, ООП объективно отличается от "просто объектного" подхода.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, netch80, Вы писали:
SV.>Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей. Следовательно, какая-то метаинформация теряется. А раз так, ООП объективно отличается от "просто объектного" подхода.
SV.>Вот что показывал мой пример.
Т.е. по вашему объектность подхода заключается в ... IDE
Хорошо, поставим мысленный эксперимент: предположим что появился плагин к IDE, который при набирании точки за HWND типом покажет все методы, принимающие HWND первым аргументом. С такой штукой WinAPI станет окончательно объектным?
Здравствуйте, Artifact, Вы писали: A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.
Дело не в ООП. Такую же ситуацию можно получить и в других парадигмах. Без разницы.
Дело вот в этом:
A> И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
Ситуация стала такой давно, когда у ведущих менеджеров отрасли возникла идея: заменить нескольких классных (и капризных) разработчиков толпой послушных и управляемых "кодеров".
А под эту цель подтянулось и все остальное (и комплект "серебряных пуль" в частности). Масштабирование команд, "повторное использование кода" (идея мутировавшая в "использование чужого кода"), языки не запрещающие прострелить себе ногу (кодеры же...) и многое еще подобное. Я несколько сомневаюсь, что выстроенный таким образом колосс индустрии может быть изменен. Подождем пока рухнет...
Здравствуйте, Undying, Вы писали:
U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор?
Они и так в курсе. Достаточно поглядеть на аналог в WPF.
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
Лучше потерпеть отдельные недостатки, чем пытаться сдвинуть гору в одиночку.
