Десять вещей, которые я терпеть не могу в ООП

http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/
  • Перевод
Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:
«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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


1. Парадигма


Что же есть парадигма объектно-ориентированного программирования? Есть ли на это прямой ответ? Я слышал столько разных версий, что и сам теперь не знаю.

Если мы посмотрим на идеи Smalltalk’а, мы столкнемся с мантрой: “Все есть объект”. Кроме переменных. И пакетов. И примитивов. Числа и классы тоже не совсем объекты, и так далее. Очевидно, “все есть объект” не может быть основой парадигмы.

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

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

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

Давайте взглянем на другие парадигмы, позволяющие решать программистские задачи определенным образом. Процедурное программирование часто описывается как программы = данные + алгоритмы. Логическое программирование гласит: программы = факты + правила. Функциональное программирование, по всей видимости, программы = функции + функции. Что наводит на мысль, что ООП означает программы = объекты + сообщения. Так ли это? Я думаю, что тут теряется главное. А главное в том, что ООП – это не парадигма, как например процедурное, логическое или функциональное программирование. Вместо этого ООП говорит: “для каждой отдельной задачи вы должны разработать свою собственную парадигму”. Другими словами, парадигма объектно-ориентированного проектирования такова: “Программирование — это моделирование”.

2. Объектно-ориентированные языки программирования


Еще я не люблю то, как всем нравится не любить чужие языки. Мы любим разделять мир на лагери: фигурные скобочки против квадратных против круглых.

Вот некоторые вещи, которые говорились о наших любимых ООЯП:

“Си позволяет легко выстрелить себе в ногу; с C++ это сделать сложнее, но, когда вы это делаете, вы отстреливаете себе ногу целиком.”
Это сказал Бьерн Страуструп, так что все хорошо.

“Я придумал термин ‘объектно-ориентированный’, и вот что я вам скажу: я не имел в виду C++.” — Алан Кей.

“В C++ всего 2 вещи получились не так: начальный замысел и реализация.” — Бертран Мейер

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

“C++ — это история, повторяющаяся как трагедия. Java — это история, повторяющаяся как фарс.” — Скотт МакКей

“Java, лучший аргумент за SmallTalk после C++.” — Фрэнк Винклер

“Если бы у Java был настоящий сборщик мусора, большинство программ удаляли бы себя во время исполнения.” — Роберт Сьюэл

И, возможно, наиболее всеобъемлющий приговор:
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп


3. Классы


Классы сводят меня с ума. Это может показаться странным, так что позвольте объяснить.

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

Однако в реальном мире есть только объекты. Классы существуют только в нашем сознании. Можете ли вы привести хоть один пример из реального мира, что класс — это реальная, физическая сущность? Нет, не думаю.

И вот в чем проблема. Вы когда-нибудь задумывались, почему программу на объектно-ориентированном языке понять настолько сложнее, чем на процедурном?

В процедурных программах процедуры вызывают другие процедуры. Процедурный код показывает… процедуры, вызывающие другие процедуры. Все хорошо и просто, так ведь?

В объектно-ориентированных программах объекты посылают сообщения другим объектам. Объектно-ориентированный код показывает… классы, наследующие другие классы. Ой. Кажется, что в ООП между исходным кодом и исполняемой программой нет никакой связи. Наши инструменты плохо помогают нам: IDE ведь показывают классы, а не объекты.

Я думаю, поэтому SmallTalk’еры так любят программировать в дебаггере: последний дает им почуствовать контроль над исполняемыми объектами и позволяет программировать их напрямую.

Вот, что я бы хотел сказать разработчикам инструментов: пожалуйста, дайте нам IDE, которая будет показывать объекты вместо классов!

4. Методы


Честно говоря, методы я тоже терпеть не могу.

Как мы все понимаем, методы в хороших объектно-ориентированных программах должны быть короткими и изящными. Множество маленьких методов удобнее для разработки, понимания, повторного использования и так далее. Так в чем же проблема?

Примем во внимание то, что на чтение объектно-ориентированного кода мы тратим больше времени, чем на его написание. Это и называется производительность: вместо того, чтобы часами писать большое количество кода, чтобы добавить новый функционал, мы пишем всего лишь несколько строчек, но при этом часами пытаемся понять, какие именно строчки нужно написать!

Одна из причин, почему мы тратим столько времени, в том, что нам приходится листать код туда-сюда… через множество маленьких методов.

Это также известно как синдром Затерянных в космосе и об этом говорится со времен создания ООП. Цитируя Адель Голдберг, “В SmallTalk все происходит где-то еще”.

Я уверен, что винить в этом стоит сегодняшние кодоориентированные IDE — учитывая, что объектно-ориентированный код не дает представлений об исполняемом приложении, IDE встает на нашем пути вместо то, чтобы помогать. Другая причина, по которой SmallTalk’еры так любят программировать в дебаггере — он помогает им хорошо видеть, какие объекты с какими взаимодействуют. Поэтому, я думаю, сегодня популярна разработка через тестирование (test-driven development, TDD), позволяющая увидеть взаимодействие объектов во время разработки.

И дело не в самом ООП — мы просто еще не поняли (после более чем 40 лет), как надо разрабатывать программы для него. Мы должны задаться вопросом: почему исходный код остается преобладающим отображением в IDE?

Я хочу IDE, которая позволит мне переключаться между кодом и исполняемым приложением. (Для получения представления об этой идее, загляните на сайт платформы для веб-разработки Seaside, позволяющей переключаться прямо с исполняемого приложения на редактируемый исходный код)

5. Типы


Ладно, признаю: я нетерпелив и ненавижу повторять слова дважды. Типы же заставляют меня это делать.

Кто-то сейчас наверняка подумал: “Но как же ты можешь писать на бестиповом языке. Ты никогда не будешь уверен, что твой код правилен.”

Конечно, “бестиповых” языков не существует — существуют статически и динамически типизированные. Статически типизированные мешают писать код в некоторых случаях. В принципе, ничего плохого в этом нет.

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

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

И наконец, типизация плохо ладит с тем фактом, что существуют разные понятия типов. Не бывает одной всемогущей системы. Вспомните те страдания, которые мы испытывали с обобщениями в Java. Сейчас разрабатывается много полезных систем типов, но расширить Java, чтобы уместить их все, мы не можем. Гилад Браха предложил сделать типизацию не только необязательной, чтобы запускать программы даже в том случае, если типизация некорректна, но и подключаемой, такой, чтобы мы смогли подключать разные системы типов в разных частях наших программ. Мы должны подумать над этим предложением, а заодно и над тем, как адаптировать языки программирования и среды разработки к разнообразным системам типов.

6. Изменчивость


“Перемены неизбежны — в отличие от мелочи из торгового автомата.” — Роберт Галагер

Мы все не любим меняться, правда? А если так, то почему же жалуемся, если вещи не становятся лучше? Мы знаем, что полезные программы должны меняться, или со временем они ухудшаются.

(Между прочим, знаете, в чем разница между железом и софтом? Железо ухудшается, если вы не поддерживаете его в рабочем состоянии.)

Учитывая, что реальные программы должны меняться, справедливо полагать, что языки и IDE должны поддерживать это. Предлагаю вам, однако, назвать хоть один механизм в языках программирования, который поддерживает изменчивость. Те механизмы, которые работают с изменчивостью, скорее, ограничивают и контролируют ее.

Наш мир непостоянен, но мы хорошо себя в нем чувствуем. Контекст — вот то, что позволяет нам справляться с переменами. Мы подстраиваем наше поведение, наши ожидания под контекст, в котором находимся, но наши программы почему-то ломаются, если контекст меняется.

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

7. Шаблоны проектирования


Паттерны. Не могу с ними, не могу без них.

Каждый шаблон проектирования делает ваш проект запутаннее.

Я все сказал.

8. Методологии


“Все методологии основаны на страхе.” — Кент Бэк

Похоже, некоторые из моих студентов работают по Agile-методологии в стиле Чака Норриса:

“Чак Норрис не занимается итеративной разработкой. Все получается с первого раза, каждый раз.”

“Чак Норрис не пишет документацию. Он смотрит в упор на код до тех пор, пока тот не скажет все, что надо знать.”

9. UML


Бертран Мейер рассказывает о том, что его удивляло, почему схематические языки программирования всегда были такими популярными, пока однажды его не осенило: “Пузыри не ломаются!”. (Другое высказывание, принадлежащее Мейеру: “All you need is code”)

Похоже, что с тем, что обычно понимается под разработкой через моделирование, тоже что-то не так: не код должен генерироваться из модели — модель должна быть кодом.

Между прочим, FORTRAN продавался как язык высокого уровня, из которого генерировался исходный код. А теперь язык высокого уровня для нас и есть исходный код.

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

10. Очередная новая вещь


И наконец, коронная фраза, которую я ненавижу: “Объектов недостаточно. Нужно еще...”. Все эти годы нам нужны были фреймворки, компоненты, аспекты, сервисы (которые, похоже, любопытным образом вернули нас к процедурному программированию!)

Если объектов никогда не было достаточно, почему же они исправно служили нам все эти годы?

Вывод?


25 лет назад мы не ожидали, что “новый” феномен ООП проживет столь долго.
Мы думали, что ОО-конфереции типа ECOOP, OOPSLA просуществуют лет 5, а затем затеряются в мейнстриме.

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

ООП позволяет упрощать сложные вещи через моделирование, но мы все еще не овладели этим, возможно, потому, что плохо различаем существенные и несущественные сложности.

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

Спасибо за прочтение!

Немного об авторе
Oscar Nierstrasz — профессор Computer Science в Бернском университете, основатель Software Composition Group, которая исследует механизмы, позволяющие компьютерным системам быть гибче и лучше приспосабливаться к изменяющимся условиям. (отсюда понятно стремление автора к внедрению механизмов изменчивости в ЯП)

Активный участник исследовательского ООП-сообщества, участник и председатель таких конференций, как ECOOP, ESEC и MODELS. (Данная статья — как раз речь Oscar'а на конференции ECOOP 2010). Также главный редактор The Journal of Object Technology.

Соавтор более 200 публикаций и 2 книг: Object-Oriented Reengineering Patterns и Pharo by Example. (обе книги, по-видимому, не переведены на русский, зато бесплатны и доступны для скачивания по ссылкам)
Метки:
Поделиться публикацией
Комментарии 253
  • +44
    Главное, что ООП решает поставленные задачи, а когда хочется поболтать, я говорю

    xn-----clcksaplxf6byd3cyb.xn--p1ai/

    P.S.: Не совсем из этой оперы, но смысл и сюда подойдет
    • –11
      Статья в стиле: я не понимаю ООП и не могу на нем нормально программировать, поэтому ООП — плохой. Интересно, автор про SOLID что нибудь слышал?
      • +41
        Т.е. Вы считаете, что человек, постоянно работающей в области ЯП, при этом имеющий тонну публикаций и исследований ничего не понимает в ООП?

        А может быть дело в том, что крутясь постоянно в тех кругах ему лучше видны его недостатки?

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

        И люди с ООП головного мозга пишут всякое такое:

        class ClassA {};
        class ClassB: private ClassA
        {
        public:
        ClassA& AsClassA()
        {
        return *this;
        }
        };

        А самое страшное — народ со скамьи разучился думать и писать ПРОСТО и это очень грустно :(
        • +51
          Ну, конечно, хотелось бы предметного диалога с автором. Несмотря на это, постараюсь прокомментировать статью и некоторые моменты, чтобы не быть голословным:

          Однако в реальном мире есть только объекты. Классы существуют только в нашем сознании. Можете ли вы привести хоть один пример из реального мира, что класс — это реальная, физическая сущность? Нет, не думаю.

          Тут автор явно передергивает. Понятно, что классы существуют только в нашем сознании, но, о ужас, не только классы, но и функции, переменные и проч. Например, функция — это лишь некоторая процедура в коде, которая вызывается через CALL и возвращается RET. А если копнуть глубже, то окажется, что есть только ассемблерные команды, и там вообще нет таких понятий, как процедуры, а есть регистры и память. А если еще глубже копнуть, то окажется, и этого нет, а есть заряды и токи, потенциалы и поля. А потом оказывается, что и полей нет, т.к. поля — лишь удобный инструмент физиков для предсказывания реальности, но это уже философия. Поэтому говорить, что классы существуют только в нашем сознании — это все равно, что сказать, что вода — это жидкость. Ну да, и что плохого?

          В процедурных программах процедуры вызывают другие процедуры. Процедурный код показывает… процедуры, вызывающие другие процедуры. Все хорошо и просто, так ведь?

          В объектно-ориентированных программах объекты посылают сообщения другим объектам. Объектно-ориентированный код показывает… классы, наследующие другие классы. Ой. Кажется, что в ООП между исходным кодом и исполняемой программой нет никакой связи. Наши инструменты плохо помогают нам: IDE ведь показывают классы, а не объекты.

          С тем же успехом можно утверждать, что параметры — вот они были объявлены my_param, а теперь вдруг при исполнении опа, и нет my_param, а есть лишь 0 в ячейке памяти. Неожиданно, правда? Так и с объектами, есть класс, который объявляет, что будет внутри, т.е. сосуд, а наполнение может быть самым разным. Это, на минутку, присуще всем языкам, ООП тут вообще ни при чем.

          Честно говоря, методы я тоже терпеть не могу.

          Хм. Тогда автор и функции тогда должен не любить. Потому что метод — это функция, где дополнительным параметром будет объект, т.е. экземпляр класса. Этот метод говорит нам о том, что будет действие именно над этим объектом, который стоит вначале, обычно перед точкой.

          Примем во внимание то, что на чтение объектно-ориентированного кода мы тратим больше времени, чем на его написание.

          Для того, чтобы использовать, нет необходимости читать код. Для этого есть доки. Это же можно отнести к любой парадигме, ООП тут не исключение. А абзац можно понять так: предположим, что читать код ООП очень тяжело. Вот видите, т.к. читать очень тяжело, то мы столько времени на это тратим, таким образом производительность падает. Хочется спросить: откуда первоначальное утверждение?

          Конечно, “бестиповых” языков не существует — существуют статически и динамически типизированные. Статически типизированные мешают писать код в некоторых случаях. В принципе, ничего плохого в этом нет.

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

          Можно еще долго комментировать это послание про ООП. Но, думаю, для начала достаточно.
          • –5
            Вы реально все это восприняли только в прямом смысле?

            Я сомневаюсь, что он не знает всех плюсов ООП, которых тоже весьма и весьма прилично.

            ИМХО Автор имел ввиду показать что существует множество заблуждений по поводу ООП:
            Что ООП ИДЕАЛЬНО описывает окружающий мир, что он ПРОЩЕ и УДОБНЕЙ, что ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ кода всегда нужно, что ПОСТОЯННЫЙ КАСТИНГ ТИПОВ это хорошо и т.д.

            Я так понял, что он просто попытался показать его под другим углом.
            • +23
              Это отлично, что он хочет сказать, что ООП — не панацея, что существуют другие парадигмы. Но только то, КАК он это сказал и какие аргументы привел, вызывает ряд вопросов.

              Вы реально все это восприняли только в прямом смысле?

              Хм, а можно все это как-то воспринять в переносном смысле? Какой тогда смысл в статье, если я должен додумывать, что же на самом деле хотел сказать автор? Если автор, как говорилось выше, такой профессионал, то он должен четко формулировать свою мысль, чтобы невозможно было понять мысль двояко. Или я ничего не смыслю в профессионализме?
              • +1
                Я думаю, дело в том, что это не послание публике, а послание таким же спецам на конференции, а они «смысл прохавают»
              • +12
                Единственное, что я вынес из статьи, это, что автор попытался объяснить: «нет ничего идеального и совершенного, ООП не панацея». Зачем только он это сделал непонятно: умные люди и так это знали, а для глупых, по-моему, ничего принципиально не изменилось.
                • +3
                  Я где-то 6-8 (не помню уже) лет занимался профессионально фехтованием.

                  У нас тоже была такая шутка:
                  " — Петров, ты почему халтуришь \ не занимаешься разминкой
                  — Тренер, так давно известно: профессионалам она не нужна, а остальным и так не поможет" )
                  • +1
                    Забавно. Тоже вспомнилось: «Книга оказала влияние, обычное для хороших книг: глупые стали глупее, умные умнее, а тысячи прочих ни в чем не изменились».
                • 0
                  > ИМХО Автор имел ввиду показать

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

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

                  Писать свой список вопросов не будут, т.к. по большому счету согласен с gridem habrahabr.ru/post/169601/#comment_5880081"
                  А от «дайте IDE с объектами вообще похихикал» :D Это как?
                  • 0
                    См. любую Smalltalk-среду с образом и GUI, а еще лучше сразу Self с изначальным Morphic-ом.
                    • +1
                      Я с Smalltalk не работал. Можно ссылку на скрин, где класс показан объектом?
                      • 0
                        Пожалуйста:

                        • +1
                          Хм… Напоминает Object Browser и Watch (при запущенной отладке) в Visual Studio. Возникает вопрос чем тогда не доволен автор статьи (он утверждает что таких инструментов вообще нет с ООП). Я кстати, подумал что он вообще хочет видеть реальные объекты в IDE. Поэтому и улыбнуло. А если так — то такое, как я уже сказал, есть.
                          • 0
                            Выше я показал два вида инспекторов объектов, доступных в Pharo (одной из реализаций Smalltalk). Да, они являются родственниками (а то и родителями) упомянутых инструментов в VS (или практически любой другой мейнстримовой среде). Только помощнее и поудобнее в некоторых аспектах. Но главное, позволяют работать с объектами напрямую в любой момент — но это не их личная заслуга. Просто в Smalltalk-ах нет разделения на время «редактирования», «выполнения» и «выполнения с отладкой» — любая программа выполняется в единой среде, в которой (если не отключены) живут все объекты, представляющие средства разработки, отладки, сами классы, методы… и вообще почти все, что есть в программной системе. Очень удобно и эффективно (с точки зрения разработчика, как миминимум).

                            Тем не менее, несмотря на свою относительную развитость, объектность и даже авангардность (да, я про систему, созданную более 30 лет назад!), среда Smalltalk все равно несет в себе, как очень точно подмечено, следы кодо-ориентированности. Программист даже в Smalltalk-е все равно значительную часть времени вынужден проводить, работая с кодом, а не с живыми объектами. Что уж говорить о «современных» «продвинутых» текстовых редакторах, которые по недоразумению кем-то были названы IDE :)

                            В принципе, это мое личное мнение, но автор, как мне кажется, говорил именно об этом. Так что, да: думаю, он хочет видеть реальные объекты в IDE… и как можно чаще. Тем, что это не удается делать чаще, он и недоволен. А про полное отсутствие он не говорит… даже упоминает кое-что (тот же Seaside).
                            • 0
                              Просто в Smalltalk-ах нет разделения на время «редактирования», «выполнения» и «выполнения с отладкой» — любая программа выполняется в единой среде, в которой (если не отключены) живут все объекты, представляющие средства разработки, отладки, сами классы, методы… и вообще почти все, что есть в программной системе. Очень удобно и эффективно (с точки зрения разработчика, как миминимум).

                              Если это так, то как оно сохраняется? И есть ли там понятие «перезапустить программу», например (да и есть ли понятие программы вообще)?
                              • 0
                                Если это так, то как оно сохраняется?

                                Что понимается под «оно»? Если речь о всей системе в целом, то она сохраняется в «как есть» в виде т.н. образа. В частности, это означает (любимый пример смоллтокеров:), что можно в процессе отладки программы сохраниться, а потом открыть сохраненный образ на другом компьютере и продолжить отладку.

                                И есть ли там понятие «перезапустить программу», например (да и есть ли понятие программы вообще)?

                                А что такое программа? Вычисления запускаются передачей сообщения некоторому объекту, который для его обработки передает сообщения другим объектам и т.д. Соответственно «перезапуск» программы выполняется остановкой процесса, выполняющего такие вычисления, и запуск нового аналогичным способом.
                                • 0
                                  Соответственно «перезапуск» программы выполняется остановкой процесса, выполняющего такие вычисления, и запуск нового аналогичным способом.

                                  А есть ли способ при этом определить, какие объекты, созданные на предыдущем запуске, надо убить, а какие оставить? И как-нибудь привести объекты в «первоначальное состояние»? Или всё это — просто загрузка сохранённого образа?
                                  Интересная модель. Надо будет поиграться.
                                  • 0
                                    Сборка мусора.

                                    Если есть глобальные объекты (что плохо), разумеется надо самому заботится об правильной переинициализации. Перезапуск образа в «начальное состояние» ничего не сбрасывает — разве что почистит внешние ресурсы (что тоже не всегда удобно, но как иначе?). Можно создать новый образ (из чистого) и загрузить туда нужный код. В общем, работа с образами удобна, но требует определенной дисциплины управления образами.

                                    Да, я в прошлом комментарии не упомямнул, что объекты из образа можно различными способами выгружать и загружать обратно. И, естественно, существует целый ряд инструментов для управления исходным кодом.
                            • 0
                              В Visual Studio они норовят исчезнуть при любой попытке убрать с них курсор.
                              Посмотреть код делегата, лежащего в поле какого-то объекта, мне не удалось. Кое-как добрался до Target объекта, но какая функция к нему привязана, осталось загадкой.
                              Есть ли возможность, например, поставить break point на изменение или на чтение поля конкретного экземпляра? Найти все ссылки на объект? А как-нибудь отфильтровать их?
                              Про ручное добавление метода к объекту в VS, речи, конечно, не идёт — C# и в коде сделать такого не позволит. Но интересно, возможно ли это в среде Smalltalk.
                              • 0
                                > В Visual Studio они норовят исчезнуть при любой попытке убрать с них курсор.

                                Вы с значениями по месту в коде не путаете. Окна Watch и Object Browser прекрасно живут как в отдельных вкладках, так и на втором мониторе.

                                > Есть ли возможность, например, поставить break point на изменение или на чтение поля конкретного экземпляра?

                                Поля кажется нет, а проперти да (перейдя кликом из Object Browser в исходник).

                                > Найти все ссылки на объект?

                                Shift + F12?

                                > Про ручное добавление метода к объекту в VS

                                Не понял что требуется.
                                • 0
                                  Поля кажется нет, а проперти да

                                  Это будет breakpoint на конкретный экземпляр объекта или на класс в целом?

                                  Окна Watch и Object Browser прекрасно живут как в отдельных вкладках, так и на втором мониторе.

                                  У меня Object Browser почему-то показывает только классы, а не объекты. И даже перейти на класс в этом окне из объекта в Watch пока не получается.

                                  Shift + F12?

                                  В окне Watch? Тоже не работает.

                                  Не понял что требуется.

                                  Добавить к объекту новый метод. С именем, сигнатурой и реализацией (например, как лямбда-выражение). Чтобы потом вызвать его, например, через dynamic.
                                  • 0
                                    Написать метод расширения…
                                    • 0
                                      Он будет у конкретного экземпляра или у класса в целом?
                                      • 0
                                        У класса в целом. Все пространство имен System.Linq; состоит из них, у коллекций нету методов ToArray, ToList, ToDictionary и прочих стандартнейших и привычных.
                                • 0
                                  Да — все перечисленное не только возможно, но в том или ином виде уже реализовано.
                                  Только методы добавляются не к индивидуальным объектам, а к классам — просто поведение объекта полностью определяется классом, к которому он принадлежит. Но при необходимости можно «на лету» создать новый класс с нужным методом и сделать объект его экземпляром. Это, конечно, не так уж и просто. Хотя не так уж часто такое требуется, но все равно особо не радует. И речь о желательности иметь бессклассовый объектный язык заходит в том числе и поэтому (среди прочих соображений).
                    • –13
                      Яростно плюсую
                      • +2
                        Тогда автор и функции тогда должен не любить. Потому что метод — это функция, где дополнительным параметром будет объект, т.е. экземпляр класса.

                        У метода есть неприятное свойство — требовать наличия дополнительного параметра, да ещё предварительно порождённого от конструктора.
                        • +7
                          У методов есть более неприятное свойство — они разделены друг от друга слоями Священной Инкапсуляции, и поэтому в типичных ООП-системах существенная часть методов просто передаёт вызов дальше, в какой-нибудь следующий класс.
                          Т.е. сидишь отслеживаешь граф вызовов всё дальше и дальше, и никак не можешь найти место — а где же, собственно, метод реализован?
                          • +5
                            Это уж как у автора фантазия работатает. Если москзг так устроен, то тут язык не причем. Языки с меньшим количеством ограничений вообще позволяют творить всякий ужос-ужос-ужос. И ничего, одни как-то пишут, другие это как-то разбирают. Это как любой инструмент: чем проще, тем больше можно сделать, но очень сложно. Сложным специальным инструментом можно сделать меньше, но проще и качественнее. Так что, имхо, все упирается в человека, вцепившегося рученками в этот самый инсрумент.
                            • 0
                              Вот когда граф вызовов отслеживаешь (если я правильно понял, вы говорите о call stack во время выполнения в дебаге?), реализация как раз таки и показывается.

                              Ну а если каша из реализаций и делегирований? Такой же код можно и в функциональном пихнуть ( {int, int, function {int, int -> int} -> int} ) — отгадай, что за функцию передали параметром в другую функцию.
                          • +2
                            Тут автор явно передергивает. Понятно, что классы существуют только в нашем сознании, но, о ужас, не только классы, но и функции, переменные и проч

                            Функции являются отражением действий или вычислений в реальном мире, переменные, грубо говоря, — отражением состояния вещей. Для классов такого чёткого отражения не нашлось: класс в ООП — это, по сути, протокол создания объектов, описатель будущих экземпляров. Что в природе ведёт себя так же, как классы в ООП? Мне в голову ничего не приходит.

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

                            Для того, чтобы использовать, нет необходимости читать код.

                            Если вы — автор этого кода, то читать вам его придётся. А читать код нам приходится гораздо чаще, чем писать. И да, это не специфично для ООП, ООП просто делает отслеживание потока контроля сложней из-за постоянного делегирования обязанностей, заставляя прыгать по всей системе. Поэтому автор и упоминает синдром «затерянных в космосе».
                            • 0
                              класс в ООП — это, по сути, протокол создания объектов, описатель будущих экземпляров. Что в природе ведёт себя так же, как классы в ООП? Мне в голову ничего не приходит.

                              Фабричный конвейер.

                              Т.е. метафора ООП хоть и не для любых моделируемых сущностей адекватна, но всё же осязаемее, чем «чистые функции» и т.п.
                              • 0
                                Фабричный конвеер соответвует фабричному методу в ООП — одна сущность порождает другую. Класс не соответствует конвееру ни по названию, ни по семантике (если, конечно, речь идёт о таких языках как Java и C++, в других языках, таких как Ruby, Delphi, Common Lisp и т.д. конструкторы сами по себе являются фабричными методами).

                                Т.е. метафора ООП хоть и не для любых моделируемых сущностей адекватна, но всё же осязаемее, чем «чистые функции» и т.п.


                                В том то и дело, что не обязательно опираться на что-то реальное — главное, чтобы «родительская парадигма» была хорошо известна. Тогда ответ на вопрос, как именно реализовать ту или иную фичу, становится очевидным. Если же хорошей аналогии нет, то каждый разработчик будет строить свои собственные абстракции со своими собственными правилами. А когда речь дойдёт до интеграции, то окажется, что одна половина дома построена из панелей, а вторая — из кирпичей (с)
                                • +1
                                  Класс соответствует спецификации, которой нет в природе (по каналу Дискавери что ли?), по чертежи и ТЗ вполне привычная вещь на производстве.
                                  Главное, в классах то, что они очень хорошо бюрократизируется, а бюрократия такая штука, что во всех случаях выбирается наименее эффективный способ реализации; однако, по-другому не умеют.
                                  • +1
                                    Хм, а чем концептуально отличается «фабричный метод в ООП» от класса?
                                    И то и другое — способ превращать указания «создай мне X» в экземпляры X.

                                    Речь, ещё раз, не о конкретной реализации в конкретных ЯП, а о понятии.
                                    • 0
                                      О понятии говорить сложно, потому что в разных языках программирования оно выглядит совершенно по разному. В некоторых ОО языках и конструкторов то нету, так что разговор совсем беспредметный получается.

                                      В общем и целом моя позиция в том, что для классов нет красивой аналогии ни в реальном мире, ни в живой природе (откуда явно пришли некоторые понятия), ни где-то ещё. Даже если взять конструкторы в виде статических фабричных методов (e.g. MyClass.new), то они всё равно не особо похожи на фабричное производство: на производстве есть отдельно схема и отдельно машина, создающая предметы по этой схеме; в ООП класс представляет из себя сразу и схему, и машину. Лично мне довольно сложно представить себе такую машину. А если ещё попробовать привизать к ней такие понятия как наследование или полиморфизм… Дэвид Линч отдыхает.

                                      И да, кстати, обратите внимание на терминологию: класс практически во всех ООЯП называется именно классом, а не фабрикой или чем-то таким. А это, опять же, ведёт к разной интерпретации разными людьми и вытекающими из этого проблемами.
                                      • 0
                                        К понятию класса приходишь постепенно, если много пишешь на процедурном языке, например на Си.
                                        В какой-то момент просто задалбываешься писать функции, которые принимают аргументом указатель на структуру.
                                        К понятию private приходишь, когда понимаешь, что все поля данной структуры предназначены для внутреннего пользования и объявляешь структуру уже в .c файле, в имплементации.
                                        Могу рассказать, как приходишь к понятию конструктор и деструктор.
                                        В общем-то, если много пишешь, сам придёшь к ООП от процедурного программирования.
                                        Но после ООП переходить на ФП — здесь уже нужна не практика, а стремление «сделать не как все». Подобное стремление особо развито у программистов не могущих проявить себя на фоне более умелых коллег.
                                        • 0
                                          Вы знаете, я вполне уверен, что у вас очень стройное представление о теме разговора, но не могли бы вы пояснить, к чему относится ваш комментарий?
                                          • +1
                                            Извините, он относится к комментарию megalol чуть выше.
                                            • +5
                                              Но после ООП переходить на ФП — здесь уже нужна не практика, а стремление «сделать не как все». Подобное стремление особо развито у программистов не могущих проявить себя на фоне более умелых коллег.

                                              Дело не в ФП.
                                              У умелых коллег есть фатальный недостаток — они ничего, кроме ООП не видели и видеть не хотят, и то, что есть везде (даже в pure c, типа приватности) считают достоинствами именно ООП. Запущенный случай синдрома утенка. Т.е. если «они» прочитали в книжке об ООП о том, что private — это хорошо, они не узнают о том, что в любой сишной либе сокрытие обеспечивается. В сишных книгах не пишут о таких специфических вещах. Сахарок неявного this считается чем-то фундаментальным. Полиморфизм на VMT — по-другому не бывает. Бывает.
                                              Есть лямбды в объектно-ориентированном руби, есть деструкторы в обобщенной STL. Парадигму составляют не фичи, а совокупность фич. Какие вещи являются специфичными именно для ООП? Да хреновые. У ООП, особенно статического и мейнстримного, есть несколько фатальных недостатков.

                                              1. Непринятие ФВП. Вместо этого — тонна паттернов вида «конструктор+метод exec», половина GoF в этих паттернах.
                                              2. Отсутствие или неэффективность двойной диспетчеризации. Лечится визитором и тонной мелких методов для эмуляции двойной диспетчеризации.
                                              3. Нельзя указать на то, что X — является одновременно чем-то и чем-то. Типа foo(x: IFooable, IBarable). Вместо этого нужно делать интерфейс IFooableAndBarable.
                                              4. И многое другое.

                                              Вот эти три пункта лечат тьмой однострочных методов. Они неэффективны. А «достоинства ООП» (не важно, появились они первый раз в ООП языке или нет) умные люди догадались оставить в пост-ООП языках, не дураки же.
                                              • 0
                                                Пост-ООП языки это какие, например?
                                                • +1
                                                  Clay, Rust, Julia. Go тоже можно сюда вписать, но он меня никогда не интересовал. Но в целом он вписывается в тот тренд, что в один момент появилось много языков, в которых отсутствие ООП упоминается как фича. Вполне обыкновенных языков, не ортодоксальной функциональщины. Они, конечно, вряд ли взлетят, потому что языку не достаточно быть просто лучше другого языка.

                                                  Clay — шаблоны С++ на стероидах (выводом типов, встроенным в язык предикатами а-ля boost:enable_if, мощная compile time рефлексия). На порядок лаконичнее С++ (код может выглядеть как питон с фигурными скобками), но с теми же минусами в виде выпадения ошибки компилятора в неочевидном месте, которые слегка лечатся предикатами. Множественная диспетчеризация есть.

                                                  В Rust используются тайпклассы. Вместо передачи в функцию объекта, который в свою очередь содержит указатель на VMT, используется пара указателей — один на таблицу методов, другой на сам объект. Отсюда, например, x: IFooable, IBarable реализуется легко: нужно передать 3 указателя: на x, и на 2 таблицы методов. Соответственно не нужно городить N*M искусственных классов или, что делается чаще, даункастить, получая проблемы уже в рантайме. На тайпклассах делать частичную специализацию подобно шаблонам С++, но без минусов шаблонов и их избыточной сложности. А вот с двойной диспетчеризацией в Rust проблемы, насколько я знаю.
                                                • –2
                                                  Что мешает сделать класс FooBarable с полем type?
                                            • 0
                                              Т.е. по вашему, тысячи программистов пишущих на функциональных языках (иногда — крупные и сложные проекты) так ничего в своей жизни и не поняли?
                                              • –1
                                                Причём здесь поняли или нет, они сделали — работает — молодцы. Проблема ФП в том, что на каждую тысячу таких программистов приходится миллион пишущих на ООП Языках и тысяч десять пишущих по-старинке на процедурных. И они тоже делают крупные и сложные проекты, и даже не иногда, а почти постоянно. Для разработки на ООП языках это норма, для ФП языков — это скорее исключение. Мало кто берётся за тот же хаскель, чтобы разработать новый движок для сайта или написать полезное приложение, в 99% случаев возьмут более понятный и привычный подход.
                                            • 0
                                              Как раз-таки конвейер без схемы мне представить проще: у меня в соседнем доме пекарня, и в машину с одной стороны засыпают муку, с другой выезжают по ленте лепёшки. Даже если у неё есть какой-то «отсек для схемы лепёшек», вряд ли её оператор им когда-либо пользуется. И пирожки с яблоками эта машина не начнёт печь ну ни по какой схеме.

                                              А устоявшаяся терминология — вопрос исключительно исторический. Одно и то же понятие называется по-английски «нитками», по-русски «потоками» — и что, его по-разному из-за этого интерпретируют? «Сокращённый путь» и «ярлык», который до компьютеров означал этикетку, и так далее.
                                              • 0
                                                Так в том то и дело, что класс — это «конвеер + схема». Представить эти предметы по отдельности легко, а вот вместе, в одном неделимом предмете они мне как-то не встречались.

                                                Одно и то же понятие называется по-английски «нитками», по-русски «потоками» — и что, его по-разному из-за этого интерпретируют?

                                                Но и английский, и русский варианты отражают связанную последовательность (в данном случае — последовательность команд). А вот к чему относится слово «класс» я так и не понял. Но более важно то, что слова «нить» и «поток» описывают абсолютно чёткое понятие, а вот «класс» в разных языках программирования может означать очень разные вещи.
                                      • 0
                                        > Что в природе ведёт себя так же, как классы в ООП?

                                        ДНК
                                        • +2
                                          ДНК описывает ровно одну особь — даже родители этой особи имеют другие цепочки ДНК, и даже при бесполом размножении и отсутствии мутаций дочерние особи не будут идентичными хотя бы из-за разных условий развития. ДНК как раз показывает всю абстрактность понятия класса — в природе сущесвтуют объекты, взаимодействующие друг с другом, но в виды/классы/царства их объединяем уже мы. Природа, по сути, придерживается утиной типизации — если объект умеет крякать, то мы мы можем объединить его по этому признаку с другими подобными объектами и назвать их всех утками. Но нет никакой метасущности DuckClass, из которой были порождены все утки.
                                          • +3
                                            ДНК описывает миллиарды клеток особи
                                            • +3
                                              ДНК задаёт миллионы разных клеток организма. Из класса всегда пораждаются одинаковые объекты.
                                              • –1
                                                Если объекты одинаковые, нафиг они нужны? У клеток стейт разный. Объекты как раз и интересны состоянием. Хреновая архитектура с блобом, да.
                                                Можно еще взять концепцию «ген как класс». Спецификация, по которой генерируется белок. Это поинтереснее, потому что и наследование можно найти — подтипы 5HT рецепторов, например, интерфейс один, суть разная. Это если очень надо, чтобы классы были по каналу Дискавери.
                                                Но зачем оно надо, не понятно. Чертежей в природе, тоже не бывает, например, но это не значит, что чертежи не существуют. В общем и целом — в быту да, любят дактайпинг, но на производстве попытка засунуть в ЧПУ станок ежа вместо ужа может быть плачевной, и дактайпинг там не к месту, чем больше модель соответствует спеке, тем лучше.
                                                • 0
                                                  Слово «чертёж» гораздо лучше отражало бы классы как схемы для объектов, но даже чертежи и схемы плохо соотносятся с такими понятиями ООП как полиморфизм или наследование. А без более или менее чёткой аналогии, как я уже говорил, теряется преимущество единой модели. Не смертельно, но и приятного мало.
                                                  • 0
                                                    Наследование интерфейсов есть. Полиморфизм, соответственно тоже. Принятого в ООП единичного наследования реализации, скорее нет, но это специфичная именно для программирования вещь. Множественного наследования полно.
                                                    • +2
                                                      Эээ, наследование интерфейсов чего? Это что ли я взял у Васи его чертёж и перерисовал под свою задачу? Тут максимум прототипирование, с наследованием ничего общего. То же самое касается полиморфизма, пояснитесь, пожалуйста.
                                                      • +1
                                                        У деталей тоже есть интерфейсы — например, поверхности, которые позволяют их соединять. Соответственно, два предмета с общим механическим интерфейсом являются полиморфными.
                                                        Тут максимум прототипирование, с наследованием ничего общего.

                                                        Как это ничего общего. В прототипном ООП нет классов, а тут есть класс — чертеж детали, и экземпляр — конкретная деталь, которая обладает своими интерфейсами, определяемыми классом, и состоянием.
                                                        • 0
                                                          У деталей тоже есть интерфейсы — например, поверхности, которые позволяют их соединять. Соответственно, два предмета с общим механическим интерфейсом являются полиморфными.

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

                                                          Как это ничего общего. В прототипном ООП нет классов, а тут есть класс — чертеж детали, и экземпляр — конкретная деталь, которая обладает своими интерфейсами, определяемыми классом, и состоянием.

                                                          Я говорю про прототипирование и наследование самих по себе чертежей. Наследование — это не просто «взять за основу и перерисовать», это расширение класса. Опять же, чертежи это свойство не отражают.

                                                          В общем, если вам нравится, используйте на здоровье. Я хотел указать на несоответствия в ООП, которые могли вызвать у автора батхёрт, и мне кажется, я назвал уже достаточно таких несоответствий.
                                                • +1
                                                  Это сжатый/зашифрованный исполняемый файл, содержащий код и данные всех объектов (клеток) и описывающий их поведение. То что мы считаем её одним целым лишь ограничения текущего уровня наших знаний (зачеркнутый текст).

                                                  > Из класса всегда пораждаются одинаковые объекты.

                                                  И точно так же одна и та же последовательность нуклеотидов (=код класса) всегда порождает одинаковые объекты (происходящие в процессе создания экземпляра изменения это ошибки, в идеальной системе их не должно быть).

                                                  > Особи, созданные по одной ДНК — это как? Клонирование что ли?

                                                  Да. Классы точно такие же клоны, разве нет?

                                                  > А вот инстансы класса Person, даже имея разные имена, будут реагировать на раздрожители (сообщения) одинаково, потому что это прописано в их методах.

                                                  Добавив ему состояние (которое есть у Васи и Пети) получим разные реакции на одинаковые раздражители. И кстати, никто не запрещает делать это состояние зависимым от бесконечного числа динамических/случайных параметров => разные экземпляры класса практически всегда будут вести себя по разному.

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

                                                  Человек одев крылья, хвост и клюв своеобразной формы становится птицей?

                                                  Различная последовательность ни о чем не говорит, тем более без распаковки сравнивать их недопустимо. Не удивлюсь если окажется что все птицы имеют одинаковые участки ДНК, воссоздающие эти органы, но с совершенно разным набором параметров в зависимости от вида.

                                                  > Найдёте для них «метасущность», порадившую оба предмета?

                                                  Табурет :)
                                                  • +1
                                                    ДНК — декларация, а не исполняемый файл. Это вполне себе файл данных.
                                                    И точно так же одна и та же последовательность нуклеотидов (=код класса) всегда порождает одинаковые объекты

                                                    Это не так
                                                    • +1
                                                      А как? Может быть где-то можно по подробнее про это почитать? (лучше не слишком научно)
                                                      • +1
                                                        ДНК — код на языке, который конвертируется в другой язык (условно — РНК) который интерпретируется в рибосомах (результат интерпретации — белок). Интерпретатор обладает собственным состоянием и может из одного и того же кода создавать разные белки (читать, например, elementy.ru/news/431959)
                                                    • 0
                                                      > Особи, созданные по одной ДНК — это как? Клонирование что ли?
                                                      Да. Классы точно такие же клоны, разве нет?

                                                      Это как бы был намёк, что в природе клонирования не существует. А если проводить аналогию с лабораторными экспериментами, то при чём тут наследование?

                                                      Добавив ему состояние (которое есть у Васи и Пети) получим разные реакции на одинаковые раздражители. И кстати, никто не запрещает делать это состояние зависимым от бесконечного числа динамических/случайных параметров => разные экземпляры класса практически всегда будут вести себя по разному.

                                                      Вы пытаетесь моделировать, я же говорю про аналогии. Реально в программе у вас будут объекты типа Person с 3-4мя свойствами, и реагировать на сообщения они будут вполне определённо. И наследоваться Person будет от какого-нибудь GenericUser (или вообще от Object), но никак не от Monkey.

                                                      Различная последовательность ни о чем не говорит, тем более без распаковки сравнивать их недопустимо. Не удивлюсь если окажется что все птицы имеют одинаковые участки ДНК, воссоздающие эти органы, но с совершенно разным набором параметров в зависимости от вида.

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

                                                      > Найдёте для них «метасущность», порадившую оба предмета?

                                                      Табурет :)

                                                      И каков же был механизм порождения?
                                                      • 0
                                                        > Это как бы был намёк, что в природе клонирования не существует.

                                                        Это не так ru.wikipedia.org/wiki/Клонирование_(биология)

                                                        > Реально в программе у вас будут объекты типа Person с 3-4мя свойствами, и реагировать на сообщения они будут вполне определённо.

                                                        Вы наверное хотели сказать в простой программе?

                                                        > Вообще отличный вариант — при изучении и работе с ООП в качестве аналогии использовать слабоизученные понятия из совершенно другой области

                                                        Я так и не увидел аргументов против того что ДНК это программа, что кстати и написано в её определении: «Дезоксирибонуклеи́новая кислота́ (ДНК) — макромолекула (одна из трех основных, две другие — РНК и белки), обеспечивающая хранение, передачу из поколения в поколение и реализацию генетической программы развития и функционирования живых организмов. Основная роль ДНК в клетках — долговременное хранение информации о структуре РНК и белков.».

                                                        Кроме этого есть еще РНК: «РНК состоит из длинной цепи, в которой каждое звено называется нуклеотидом. Последовательность нуклеотидов позволяет РНК кодировать генетическую информацию. Все клеточные организмы используют РНК (мРНК) для программирования синтеза белков.». Эта программа выполняется в рибосомах и на выходе имеем новые экземпляры белков. Аналогия, ИМХО, полная (и даже проще чем с ДНК).

                                                        > И каков же был механизм порождения?

                                                        Без спинки сидеть неудобно :)

                                                        ЗЫ: цитаты из википедии.
                                                        • 0
                                                          Нашел простенький ролик: www.youtube.com/watch?v=xIvexSkcorE

                                                          Разве не компьютер? :)
                                                          • 0
                                                            Это не так ru.wikipedia.org/wiki/Клонирование_(биология)

                                                            А, ну ок. Это то, что я выше упоминал как бесполое размножение.

                                                            Вы наверное хотели сказать в простой программе?

                                                            В любой программе, не пытающейся моделировать конкретно человека как билогический вид. Если Person у вас играет более или менее важную роль, то будет 10-12 полей. Если вы пишете очередной фейсбук, может быть будет 30-40 полей. Но никак не тысячи полей и методы, зависящие от внешних рандомных факторов.

                                                            Я так и не увидел аргументов против того что ДНК это программа, что кстати и написано в её определении:

                                                            Так я не понял, мы сравниваем ДНК с классами или с программой? Или и с тем, и с другим? И вы всё ещё считаете это интуитивной аналогией, на которой стоило бы строить модель? Ну ок, каждому своё.

                                                            «Без спинки сидеть неудобно :)» — это вы и называете «наследованием»?
                                                            • 0
                                                              > В любой программе

                                                              Я бы не стал обобщать, ИМХО, это все впереди :)

                                                              > Так я не понял, мы сравниваем ДНК с классами или с программой?

                                                              Я думаю с кодом класса (с той структурой которая служит для создания экземпляра). Однако возвращаясь к начальному вопросу, похоже что лучшим примером создания экземпляров классов в реальности будет или создание экземпляров РНК по ДНК или же создание экземпляров белков по РНК (при условии что рибосомы создают один и тот же белок).
                                                          • 0
                                                            Это как бы был намёк, что в природе клонирования не существует.

                                                            Охренеть
                                                    • 0
                                                      > ДНК описывает ровно одну особь — даже родители этой особи имеют другие цепочки ДНК

                                                      Все особи созданные по одной ДНК (= классу) одинаковы, изменения же в ДНК подобны рефакторингу (случайные изменения => ошибки допущенные программистом).

                                                      > Но нет никакой метасущности DuckClass, из которой были порождены все утки.

                                                      Определенная последовательность нуклеотидов, отвечающая за определенные признаки, как раз ей и будет (можно назвать её интерфейсом). И только по этой последовательности можно точно отнести создаваемые особи (объекты) к какому либо типу, одинаковых признаков у разных особей для этого недостаточно (умение крякать не делает человека уткой).
                                                      • 0
                                                        Особи, созданные по одной ДНК — это как? Клонирование что ли? Даже если так, то отличия между особями всё равно будут. Даже если Вася и Петя — близнецы и обладают абсолютно одинаковой ДНК, то на разные раздрожители они всё равно будут реагировать по разному. А вот инстансы класса Person, даже имея разные имена, будут реагировать на раздрожители (сообщения) одинаково, потому что это прописано в их методах. Если вам всё ещё нравится такая аналогия, и вас не смущает разница ни в терминологии, ни во внутренних механизмах классов в ООП и ДНК в живых организмах, то ради бога, пользуйтесь ей. Но, как я уже говорил выше, перечисленных отличий достаточно для недовольства автора изначальной статьи.

                                                        Наличия крыльев, хвоста и своеобразной формы клюва достаточно для того, чтобы называть животное уткой, даже если последовательность нуклеотидов у этого животного совершенно другая. Вы сами назвали слово «интерфейс», а теперь взгляните на Go, где объект считается удовлетворяющим интерфейсу просто если содержит соответсвующие методы. При этом никакого «кровного родства» (наследования или чего-то ещё) между объектами с одним интерфейсом может и не быть.

                                                        Если отойти от живой природы, то можно найти ещё более яркие примеры: офисное кресло и железный трон не имеют ничего общего, кроме того, что на них принято сидеть; тем не менее, и то, и другое вполне попадает под определение стула. Найдёте для них «метасущность», порадившую оба предмета?
                                                    • 0
                                                      Нет, не ДНК. Единственное, что действительно похоже на классы — виды живых существ. Хоть и не для всех случаев, но можно сказать, что вид является в природе не просто абстрактным понятием, т.е. это реально существующий пример ООП класса в реальной жизни.
                                                    • –1
                                                      ведь одной из фишек ООП обычно называют как раз отражение реального мира, не так ли?
                                                      Есть несколько абстракций, которые иногда используются на начальных этапах обучения ООП. Признаться — они меня всегда бесили. По-моему, также, как есть гуманитарный и технический склад ума, тамже существует и «тип мышления, легче обучающегося через аналогии» и «тип мышления, не требующего аналогий при обучении». Мне нафиг не нужны отображения вроде «class Car — это как машина в реальном мире, у неё есть разные характеристики (properties), она всякое умеет (methods)» и т.п. Мне достаточно понимания того, КАК работает та или иная конструкция. Тем не менее, выделение сущностей — чертовски хорошая идея, позволяющая четко отразить взаимосвязи между компонентами, модулями, классами и т.п.
                                                      • 0
                                                        Аналогии дают одно хорошее преимущество — они явно задают контекст. Если вы видите объект типа «Car», то вы уже заранее можете ожидать, что у него есть метод «drive». Если же вы видите абсолютно новое понятие, то вам именно что придётся сначала изучить, как с ним работать. Т.е. в первом случае у вас в голове уже есть некая модель объекта, во втором — вам сначала придётся её построить. И ладно бы на изучении объекта дело и заканчивалось, но если каждый программист использует свой собственный набор моделей, то где гарантия, что при интеграции эти модели совпадут, а не приведут к куче несовместимостей в коде? Если я в коде на C++ привык помечать все переменные в своих функциях как const, то мне будет довольно неприятно работать с библиотекой, постоянно использующей references и поэтому требующей изменяемых переменных. Единая парадигма или единая аналогия, которой приедживаются все разработчики, значительно снижает количество таких проблем несовместимости. Программы пишутся людьми для людей, и только потом — для компьютеров (с) Сассман.
                                                      • +1
                                                        Соответственно, в ФП принято оперировать понятиями из математики — чистые функции, отсутствие состояния, алгебраические типы данных и т.д. ООП само по себе, у него нет «родительской парадигмы» — оно не отражает ни реальный мир, ни какую-то другую науку.

                                                        Ну здрасьте. ООП – в чистом виде платоновские эйдосы, прямо вместе с иерархиями. Ничем не более и не менее абстрактное понятие, чем математика. И «не наука» в той же степени, что математика.
                                                        • 0
                                                          Интересно, сколько из присутствующих здесь разработчиков ассоциирует ООП с Платоном.
                                                        • 0
                                                          >Что в природе ведёт себя так же, как классы в ООП?

                                                          ИДЕИ.
                                                          Есть мир реальный, который мы осязаем, есть мир идей — т.е. работа нашего мозга, мышление (в том числе абстрактное). Эту тему хорошо развил Платон. Объекты в ООП соответствуют предметам реального мира, а классы — идеям реального мира (т.е. объектам идеального мира Платона). Вот машина (объект), вот еще одна машина (объект), и все это — машина как идея (класс), частный случай транспортного средства (абстрактный класс).
                                                          • +1
                                                            Почему-то на мой комментарий о классах целая куча людей сразу стала искать, что же в природе похоже на классы в ООП — ДНК, чертежи, идеи. И почему-то все пропустили основную мысль: у ООП нет очевидного аналога, с которым можно было бы сравнивать, на примере которого можно было бы объяснять парадигму новым разработчикам, и основываясь на котором можно было принимать архитектурные решения. Ни ДНК, ни чертежи, ни философия Платона не входят в ряд всем известных знаний; ООП не проводит явных аналогий с ними ни по терминологии, ни по свойствам. При желании можно найти общие черты между ООП и чем угодно. Но вопрос не в том, что в реальном мире сопоставить парадигме, вопрос в том, чему сама парадигма изначально была сопоставлена.
                                                            • 0
                                                              Вы слегка противоречите сами себе)

                                                              у ООП нет очевидного аналога,

                                                              и
                                                              вопрос в том, чему сама парадигма изначально была сопоставлена.

                                                              — т.е. все-таки аналог есть?

                                                              Я согласен со второй цитатой. НЕВОЗМОЖНО создать нечто, не имеющее аналогов в реальном мире. И реальный, и техногенный мир построен на одних и тех же фундаментальных понятиях.
                                                              • 0
                                                                И в чём же противоречие? Вопрос: на основе каких идей из реально мира было создано ООП? Ответ не очевиден. По-моему, всё очень логично.

                                                                Я согласен со второй цитатой. НЕВОЗМОЖНО создать нечто, не имеющее аналогов в реальном мире.

                                                                Вы плохо знаете математику.
                                                                • 0
                                                                  Человек, фактически, мыслит в ООП-парадигме, идентифицируя явления окружающего мира в виде объектов (обладающих структурой и поведением, т.е. данные + методы) и обобщая их в виде понятий, идей (классы, дальше иерархия классов). Так что, вопрос «на основе каких идей реального мира было сделано ООП?» сам по себе странен — ООП это отражение системного подхода, нашего способа описания мира! Хорошо, а процедурное, функциональное, логическое программирование — какое там соответствие?

                                                                  Про математику я бы не спешил с выводами. Вообще тут еще стоит определиться что есть аналог, но для предметного разговора Вам хорошо бы привести примеры, что есть в математике такое, чему нет никакого соответствия, аналогии в реальном мире. Достаточно одного примера.
                                                                  • +3
                                                                    Про математику я бы не спешил с выводами. Вообще тут еще стоит определиться что есть аналог, но для предметного разговора Вам хорошо бы привести примеры, что есть в математике такое, чему нет никакого соответствия, аналогии в реальном мире. Достаточно одного примера.

                                                                    Бесконечная последовательность.

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

                                                                    Бла-бла-бла. Вы не представляете, сколько раз я вёл подобный диалог, и каждый раз безрезультатно. ООП отражает реальный мир ни чуть не больше, чем процедурное, функциональное или какое либо ещё программирование. То, что ООП прихватизировало понятие «объект» ещё не значит, что оно отражает мир лучше. Я бы сказал, что оно отражает реальность гораздо хуже того же процедурного подхода, потому что когда мы пишем программу, мы описываем, что мы делаем над объектами (процедуры над структурами), а не что сами объекты делают. point.add(another_point) — мы прибавляем одну точку к другой, а не одна точка берёт и прибавляет к себе другую. connection.open() — мы открываем соединение, а не само соединение берёт и ни с того, ни с сего решает открыться. Переставьте this с места перед точкой в список аргументов и вы получите чистый процедурный подход. И именно этот подход будет отражать наши действия в реальности. feed(cat) — покормить кота, а не cat.feed() — кот кормит.

                                                                    Обобщение понятий по общим признакам — это интерфейсы. Классы задают строгую иерархию, которой объекты реального мира не обладают. Камень и автомат калашникова не имеют ничего общего в своём происхождении (читай, не имеют общего класса-предка), но оба могут быть использованы как оружие (реализуют интерфейс «оружие»). Отношения между объектами реального мира гораздо сложней, чем это описывает ООП. Если не верите, попробуйте составить мало-мальски серьёзную онтологию на основе иерархии классов. А потом сравните, например, с логическим программированием и подумайте, так ли хорошо ООП описывает мир.
                                                                    • +2
                                                                      feed(cat) — покормить кота, а не cat.feed()

                                                                      Просто Вы положили действие в основу всего, и пытаетесь, мысля процедурно, трактовать ООП (где в основе данные, или точнее данные+методы). В Вашем подходе есть действие «покормить», ну и аргумент — кого, логично. Но взгляните: в реальном мире действие кто-то совершает. Оно не может быть само по себе, действие — это динамический аспект некой системы. Возможность действия сформирована неким предметом, системой, и это действие — часть его поведения. В ООП это называется метод) Поэтому:

                                                                      Cat cat;
                                                                      cat.eat(); — мы сказали коту «иди поешь!»

                                                                      или
                                                                      Human human;
                                                                      Cat cat;
                                                                      human.feed(cat); — мы сказали человеку «покорми кота»

                                                                      Обобщение понятий по общим признакам — это интерфейсы

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

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

                                                                      Бесконечная последовательность.

                                                                      Вселенная по-вашему конечна? Есть граница?
                                                                      • 0
                                                                        Вселенная по-вашему конечна? Есть граница?

                                                                        Я вам специально написал «бесконечная последовательность», а не «бесконечная вселенная». Рассуждать о бесконечности вселенной бессмысленно — мы не видели её границ, так что не знаем точно. А вот бесконечные последовательности одназначно существуют в математике. Не нравятся бесконечные последовательности, ок, найдите в природе аналог любого ненатурального числа, например, минус единицы. Можете нарисовать мне минус одно яблоко? А как насчёт мнимой единицы яблока? На самом деле в природе нет ни сложения, ни вычитания (есть перенос яблок из одного места в другое), ни дробных чисел, ни корней квадратных и т.д. Математика — это формальная система, удобная абстракция, которая позволяет проще оперировать объектами реальности. Но далеко не все элементы абстракции имеют хотя бы один аналог в реальности.

                                                                        Cat cat;
                                                                        cat.eat(); — мы сказали коту «иди поешь!»

                                                                        И часто вы разговариваете с котами? Нет, серьёзно. Говорить коту «иди поешь» — это либо вы — Куклачёв, либо просто не соответсвует реальности. И именно такое передёргивание понятий и ведёт к плохому дизайну, оторванному от реальности.

                                                                        Пример с человеком уже лучше, но если это человек изменяет состояние кота, то в чём отличие класса Cat от одноимённой структуры? Мы модифицируем структуру извне, а значит кот теряет свои объектные свойства.

                                                                        Ну и да, как там с точками? Точке вы тоже говорите «сложись с вон той другой точкой»? А соединение с сервером тоже превращается в живое существо, которое может открывать и закрывать себя?

                                                                        Так что хреновенько ООП отражает наш способ описания мира.

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

                                                                        ООП не противоречит реальности, оно просто слабо с ней связано. С этим надо смириться и не пытаться следовать идеологиям, которые на практике больше мешают, чем помогают.
                                                                        • +2
                                                                          > И часто вы разговариваете с котами?

                                                                          У вас какие то неправильные коты похоже, т.к. все мои кошки прекрасно понимают когда им говоришь «иди ешь» :) (и по сути это единственный случай когда они добровольно слушаются)

                                                                          > Так что хреновенько ООП отражает наш способ описания мира.

                                                                          Да нет, нормально оно все отражает, хотя и довольно упрощенно (собственно в этом и есть весь смысл — описать сложную систему так чтобы её можно было понять).

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

                                                                          А вот это полностью зависит от реализации, никто не заставляет вас его оживлять, что мешает создать ConnectionManager который будет управлять соединениями вместо самого соединения? (другое дело что это не всегда оправдано и не всегда может быть удобно, хотя бы из-за многословности).
                                                                          • 0
                                                                            Да нет, нормально оно все отражает, хотя и довольно упрощенно (собственно в этом и есть весь смысл — описать сложную систему так чтобы её можно было понять).

                                                                            Вы говорите про абстракцию, к ООП она ортогональна.

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

                                                                            И получить, опять же, процедурный код.
                                                                            • 0
                                                                              > Вы говорите про абстракцию, к ООП она ортогональна.

                                                                              ООП это и есть абстракция реального мира («реальный мир» здесь далеко не в буквальном смысле).

                                                                              > И получить, опять же, процедурный код.

                                                                              O_O, правда? Может быть объясните почему?
                                                                              • 0
                                                                                O_O, правда? Может быть объясните почему?

                                                                                Ну вот, пошли по кругу. Если над соединением оперируют внешние к нему методы, чем оно, как объект, отличается от структуры в процедурном программировании?

                                                                                ООП это и есть абстракция реального мира («реальный мир» здесь далеко не в буквальном смысле).

                                                                                ООП — это парадигма. Если вы хотите сказать, что с её помощью можно строить абстракции реального мира, то я не спорю — абстракции можно хоть на бумаге строить. Если вы подразумеваете, что приципы, заложенные в ООП, отражают принципы реальности, то я уже привёл с десяток примеров, показывающих, насколько плохо оно это делает.
                                                                                • +1
                                                                                  Ваш троллинг основан на том, что критерии реальности у вас свои: яблоко, например, реально, а долг в долговой книге — нет. Передвигать яблоки можно, а разрезать нельзя. И так далее.
                                                                                  • 0
                                                                                    О, отлично, теперь ещё и троллем назвали. Если вас смущает, что математика — это модель над реальностью, почитайте первый томик Кнута, где он описывает историю математики, когда и для чего в неё добавлялись новые элементы. В любом случае, я попытался поддержать культурную беседу. Если вам это кажется троллингом, не вижу смысла продолжать.
                                                                                  • +1
                                                                                    Если над соединением оперируют внешние к нему методы, чем оно, как объект, отличается от структуры в процедурном программировании?

                                                                                    Так оперирование идет не напрямую. Как с тем же котом, говорим человеку «корми кота», передавая ему объект «кот». В методе человек:: кормить идет не просто cat.сытость += 10 (т.е. работа с объектом как со структурой, в процедурном стиле), там естественно дергаются какие-то методы объекта «кот». И таких уровней вложенности может быть хоть сколько: каждый объект умеет что-то делать по внешней «просьбе», отсылая для этого «просьбы» другим объектам (инкапсулированным в него, или переданным как параметры).

                                                                                    Напомню, что изначальная идея ООП даже не в классах и вызове методов, а «программа состоит из объектов, объекты обмениваются сообщениями». Посмотрите на мир вокруг: разве он не состоит из объектов (предметов, систем), обменивающихся сообщениями (поля, излучения)?
                                                                                    • 0
                                                                                      В методе человек:: кормить идет не просто cat.сытость += 10 (т.е. работа с объектом как со структурой, в процедурном стиле)

                                                                                      То, о чём вы говорите, называется уровнем абстракции — работа со структурой ведётся не нарямую, а через логические методы. К ООП это, опять же, ортогонально.

                                                                                      Посмотрите на мир вокруг: разве он не состоит из объектов (предметов, систем), обменивающихся сообщениями (поля, излучения)?

                                                                                      А вы посмотрите на тред и удивитесь, сколько есть разных мнений о том, что же такое ООП и как оно отражает мир. И при этом вы первый, кто заговорил о полях и излучениях как о сообщениях.
                                                        • 0
                                                          Апелляция к авторитету — поскольку некто знаменитый, влиятельный либо уважаемый убеждён в чём-то, то оно обязано быть верным.
                                                      • +15
                                                        Статье уже более двух лет, и там же, в коментах, автору давно объяснили моменты, где он «ошибается».
                                                        • –64
                                                          Я всегда знал, что с этим ООП что то не так, оказывается я был прав ))) хорошо в свое время я его не понел
                                                          • +41
                                                            Непонимание никогда не бывает благом.
                                                            • –34
                                                              думаю что тебе написать, но глаза закрываются, ибо устал я сегодня… можно я тебе завтра отвечу на свежую голову ))
                                                              • +41
                                                                После «не понел» можно даже ничего не отвечать =)
                                                                • +1
                                                                  deleted
                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                    • 0
                                                                      Нет, была стандартная головоломка — выделять привычные шаблоны, давно замылившие глаз. И ломать. Думаю, что профессионал бы сделал на порядок красивее.
                                                                  • +1
                                                                    Ух какие все тут злые…
                                                            • –11
                                                              Гениальные и простые слова — абсолютная истина.
                                                              Думаю, большинство программистов, которые застали до ООП период, сейчас в глубине души считают именно так, как сказано в статье, слово в слово. Но вслух сказать все боятся, ибо — тренд, ибо «мы же так этого хотели!, мы же так к этому стремились, сжигая все мосты и занимая все фонарные столбы по дороге!»…
                                                              • +1
                                                                На мой взгляд, слишком радикальные мнения в статье высказаны.
                                                                Да, есть плюсы в ООП: возможность группирования данных по смыслу и добавить в языки тонны синтаксического сахара (например, перегрузка операторов и приведение типов).
                                                                Но есть и минус — разрекламированные расширенные возможности по повторному использованию кода в ООП на практике редки. Например, если есть проект «хлебопечка» — классы «хлебопечки» и «муки», а мы захотим сделать новый проект «мельница» и использовать класс «мука» из прошлого проекта, скорее всего окажется, что тот класс совсем не то, что нам нужно для этого проекта. Иные свойства, иные методы.

                                                                Меня больше интересует, что придет на смену ООП и ПОП. Ведь если честно, такой уж принципиальной разницы между ООП и ПОП я не вижу. Многие фичи из ООПа, до того как он стал мейнстримом, реализовывали через ПОП, просто нотация была не
                                                                obj.func(...), а prefix_func(obj, ....). Процедурные типы позволяли реализовать в ПОП аналог виртуальных функций. Но ООП позволило все это расписать красиво, за что видимо и пользуется популярностью сейчас.

                                                                Но что придет на смену? Я ожидаю нечто типа «Knowledge Oriented Programming». Работа программиста должна быть сходна с работой скульптура, когда формируем результат, беря заготовку и шлифуя ее добавлением новых знаний о продукте — определений, ограничений, реакций. Я верю, что скоро программирование как таковое будет идти на вполне обычном литературном языке без какого-либо строгого синтаксиса. И несмотря на это, с типизацией рано прощаться — может быть произойдет переход от типизации данных к их классификации, но суть от этого резко не поменяется.
                                                                • 0
                                                                  Knowledge oriented — это декларативное. Компьютеру нужны четкие процедуры, возможно с ростом AI и будет так. А по поводу литературных слов, так есть всякие DSL. Он на той же Scala можно DSL писать.
                                                              • +3
                                                                Никто не говорит, что ООП идеальная парадигма, но лучше пока не придумали.

                                                                >>Можете ли вы привести хоть один пример из реального мира, что класс — это реальная, физическая сущность? Нет, не думаю.
                                                                А кто сказал, что в ООП класс является «физической сущностью»?
                                                                • +1
                                                                  но лучше пока не придумали

                                                                  по какой шкале мерять какая парадигма лучше?
                                                                  • –6
                                                                    По популярности.
                                                                • +13
                                                                  Кратко — бредятина.
                                                                  • –2
                                                                    Я так понял, что автор теоретик, а не практик и никогда в жизни не учавствовал в больших проектах, где без ООП невозможно что-то нормально сделать, да и поддерживать потом будет просто нереально. Я например тоже знаю как пользоваться рубанком, топором, молотком, но я не буду говорить профессиональному плотнику, что ручная циркулярка это отстой и типа обычная ножовка круче (хотя правда тоже пользоваться ей знаю как).

                                                                    Знать ООП он знает, но видимо не было проектов, где ему он реально бы пригодился. А говоря вот так открыто и категорично, что ООП фигня (самому ведь не приходилось) показывает человека не с хорошей стороны.
                                                                    • +8
                                                                      Поясните пожалуйста, где автор, видный деятель ООП-сообщества и профессор CS, заявляет, что ООП – фигня?
                                                                    • +20
                                                                      Мне плевать на ООП, мне плевать на патерны и прочую требуху. Я пишу код так что бы он работал, был понятен и легко модифицировался. А отвечает ли он каким то правилам или нет меня мало волнует.
                                                                      Когда я учился на мехмате одни студенты пытались выучить все что им давали, а другие ничего не учили но сторались понять суть. Так вот понимание сути делает вас человеком который может все, а заучивание в лучшем случае дает ограниченное понимание, в худшем вы наделаете кучу ошибок.
                                                                      • –11
                                                                        Краткий пересказ статьи автора, спасибо кэп.
                                                                        • +4
                                                                          Причем здесь автор? Я вообще то высказывал свое мнение.
                                                                        • –4
                                                                          Держите нас в курсе.
                                                                        • +5
                                                                          У каждого свое мнение. Каждая сторона права, и в тоже время никто не прав. Через некоторое время будут холивары «ООП vs (что-то новое)». Таков Мир.
                                                                          Лично я не знаю, как бы я проектировал без ООП.
                                                                          • +4
                                                                            Если бы точно такую же статью написал кто-нибудь другой «неизвестный», то почти все бы проголосавали против (поставили минусы). А комментарии были бы в стиле «Да ты программировать вообще умеешь?» с большим количеством плюсов.
                                                                            Авторитет имеет значение.
                                                                            • –2
                                                                              Да, если бы не упоминание Дейкстры, то дальше бы даже не читал… Просто слишком много про ООП говорят те, кому нечего сказать.
                                                                            • 0
                                                                              Интересно, как выглядит объектно-ориентированная среда разработки, о которой мечтает автор?
                                                                              • +2
                                                                                Видимо, как Pharo, про которую он написал книгу, или как Seaside, о которой говорится в статье.
                                                                                • –3
                                                                                  Дааа, выглядят они в стиле 90-х годов…
                                                                              • +10
                                                                                Интересно читать ругательные статьи про ООП.
                                                                                Сделал я большой проект процедурным методом, и теперь мне в него лезть очень страшно.
                                                                                С трудом изучал ооп (вот есть в нём один настоящий минус по крайней мере — изучать самому после процедурного подхода тяжело), но когда наконец более-менее разобрался, начал переделывать этот проект на ооп.
                                                                                Теперь в процедурную реализацию, которая пока работает, лезть по-прежнему страшно. А вот в ооп-реализации даже через несколько месяцев я легко могу вспомнить, где что нужно найти и поменять или как можно что-то добавить. И очень часто я поменяв или добавив что-то достаточно основательное, запускаю — и с удивлением обнаруживаю, что оно работает с первого раза.
                                                                                То, что проект написанный при помощи ооп, которое я использовал в первый раз, гораздо понятнее и проще в поддержке и обновлении, чем тот процедурный, который казалось бы написан давно знакомым методом — очень сильно меня впечатляет до сих пор.
                                                                                Для меня главный принцип ооп — разделение обязанностей. Если хорошо продумать круги обязанностей каждого модуля и как можно лучше разделить модули — получается очень здорово. Мне нравится.
                                                                                • +1
                                                                                  Для многих ООП рассматривается как стиль программирования.
                                                                                  Если код в проекте может встретиться единожды и этот код с полной уверенностью больше нигде не пригодится, его все равно «оборачивают» в класс, подобное видел и с функциями.
                                                                                  Если уж нужно ООП то и использовать нужно грамотно.
                                                                                  А не
                                                                                  class HelloWorld { print "hello world"; }
                                                                                  • +2
                                                                                    Ну, в C#, например, как попало функцию не кинешь не обернутую в класс.
                                                                                  • 0
                                                                                    Прямо про меня история. Тоже получил своего опыта с процедурной разработкой (когда программа на 1-2 тысячи строк становится абсолютно неподдерживаемой). С трудом выучил ООП самостоятельно (ну вот ни разу не просто оказалось). Теперь процедурный стиль вспоминаю как страшный сон.
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • +1
                                                                                        Поддержу. Запихать в голову функциональное программирование после 10++ лет джавы — не просто.
                                                                                        • +2
                                                                                          Во-вторых, что настолько сложного в изучении ООП? Функциональное программирование после императивного — это да, а разнесение функциональности по классам и прочее чем сложно для понимания?


                                                                                          Тяжело пытаться объяснить. Вот что сложного на клавиатуре печатать? А многие до сих пор тремя пальцами набирают. Понятия ООП тяжело проецируются на традиционные алгоритмы. Ко всему прочему, на реальный мир они тоже тяжело проецируются (в реальном мире нет классов и уж тем более — инкапсуляции с интерфесами). Это все очень высокие абстракции и в совокупности это дает сложности изучения.

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


                                                                                          Можно хоть на ассемблере писать. У всего есть своя цена.

                                                                                    • +1
                                                                                      А мне нра. Правда, иногда люди перегибают палку, и лепят классы туда, где намного лучше подходит процедурный стиль, например. Так они привыкли — возможно даже и не знают, что бывает по-другому.
                                                                                      • +2
                                                                                        Про Лисп говорят, что в каждой нетривиальной программе содержится (как минимум один) интерпретатор Лиспа. Мне всегда казалось, что к ООП это тоже относится — в каждой написанной на процедурном языке нетривиальной и (успешно) развивающейся программе реализована более или менее развитая самодельная объектная модель.
                                                                                        • +2
                                                                                          Согласен. Ядро линукс к примеру хоть и написано на С, но очень многие вещи сделаны в ООП стиле:
                                                                                          структура данных и набор функций оперирующих с ней -> класс и методы
                                                                                          файловая система вообще реализует полиморфизм
                                                                                        • +2
                                                                                          «Я не люблю кататься на велосипеде потому, что надо крутить педали.»

                                                                                          «ООП не оправдало наших надежд!»

                                                                                          «Сейчас мы запили ФЯ с аспектами и монадами!»

                                                                                          Какой-то старческий бубнёж. Всех ООП устраивает, а Оскара не устраивает. И что? Отформатировать диск? Или весь интернет сразу? Ведь всё, что есть или является ООП или очень стремиться им стать. Наверное, назло Оскару.
                                                                                          • +2
                                                                                            Всех ООП устраивает


                                                                                            откуда такая информация, что «всех» устраивает?
                                                                                            • +3
                                                                                              Оскара не устраивает.

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

                                                                                              Меня не устраивает термин ООП. Уже давно, почти с самого начала, это не объектное, а классовое и интерфейсно ориентированное программирование. И парадигма звучит не как «всё есть объект» а как «для всего есть абстракция и контракт». Именно в переходе от объектов к классам происходит смещение крыши у некоторых разработчиков и появляется ощущение пустоты в душе.

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

                                                                                              Возможно критики ООП просто плохие полемисты и вселенная ждёт своег спасителя который прийдёт и раскроет заговор оопэшников. Но пока сторонники функциональной парадигмы пишут своё ПО на IDE которое полностью оопэшное и запускают его на осях которые полностью оопэшные. И даже те кто программирует железо тоже пишут свой асемблер на оопэшном IDE.

                                                                                              Мир не-ООП вокруг крайне мал. А этот мир создают тысячи вендоров и миллионы разработчиков в жёсткой конкуренции. Сейчас ООП вчистую выигрывает эту конкуренцию, а значит — всех устраивает.
                                                                                              • 0
                                                                                                Оскара не устраивает.


                                                                                                Вопрос был не о том ;)

                                                                                                анализа литературы по разработке и аудитории различных конференций


                                                                                                Неужели не нашлось литературы по FP, или логическому программированию? Или не проводиться конференций по этим технологиям?

                                                                                                Но пока сторонники функциональной парадигмы пишут своё ПО на IDE которое полностью оопэшное и запускают его на осях которые полностью оопэшные.


                                                                                                Есть и обратная сторона медали. ООП-шники используют в своей работе много «вещей» написанных на функциональных языках, например RabbitMQ — используя его вы думаете о меседжинге и очередях, а не о функциональщине и Erlange. Тоже самое и с IDE — какая мне разница на какой технологии она написана и насколько ее создатель разделяет мои взгляды на программирование? (главное чтобы работала). Вопрос ведь не в том, что я использую, а на чем я пишу/хочу писать/люблю писать.

                                                                                                Мир не-ООП вокруг крайне мал.


                                                                                                У меня есть свой взгляд на эту ситуацию (хотя я очень не люблю сравнивать OOP VS. FP и не вижу конструктива в этом). Но… FP — это программирование с точки зрения математики (чем «функциональнее» язык, тем он ближе к формальным математическим законам), FP дает вам «Formal provability» и требует от вас того же. ООП — это программирование с гуманитарной точки зрения — создавай объекты как ты «видишь мир», описывай взаимодействие как ты его «видишь». Эта свобода все облегчает — мне нужно знать формальные законы, которые связывают мои типы данных и их преобразования. Но отсюда и проблемы — imagination меняется с изучением домена, рефакторить не просто, разбираться в чужом коде сложно — это чужой imagination. Отсюда паттерны, соглашения и тд.

                                                                                                С этой точки зрения ситуация очевидна. У нас очень много людей, которые пишут и читают художественную литературу. И катастрофически мало людей, которые доказывают математические теоремы или читают чужие доказательства.
                                                                                                • +3
                                                                                                  Ещё я заметил, что сторонники ООП практически никогда не выступают с критикой других парадигм. Кстати, я вообще сомневаюсь, что ФП можно назвать парадигмой в силу минимализма ограничений.

                                                                                                  То, что вы говорите разумно и все это понимают, в частности майкрософт понимает настолько, что даже развивает отдельный функциональный язык для своей платформы F#, правда, одновременно интегрирует принципы фцнкционального программирования и в C# в виде лямды и методов расширения.

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

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

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

                                                                                                  Кроме этого я практически не встречал предложений а как же всё-таки надо. Хотя давно известно «критикуешь — предлагай»

                                                                                                  Я уверен, что эти статьи, которые критикуют ООП, сродни критики трудов Ницще или Арестотеля, они скорее ставят целью показать насколько автор критической статьи превосходит общепризнаваемую концепцию и возвышается над серой массой.

                                                                                                  Математика это да. Но сколько математики нуждающейся в нарушении принципов ООП даже в математическом проекте типа Matlab или AutoCad? Даже в этих специальных пакетах она накрепко инкапуслирована в своих библиотеках и составляет наверное не очень большую часть кода. И самое главное никоим образом не подвергает принципы ООП критике.

                                                                                                  Единственная польза от подобных статей это то, что они всё-таки заставляют выбрать язык для узучения для фана функциональный. Чтобы посмотреть из-за чего же всё таки этот крик и недовольство.
                                                                                                  • +1
                                                                                                    Ещё я заметил, что сторонники ООП практически никогда не выступают с критикой других парадигм.


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

                                                                                                    А поверхностый взгляд на вопрос приводит к критике вида «все это фигня» — что не разумно считать критикой at all.
                                                                                                    • +2
                                                                                                      Кстати, я вообще сомневаюсь, что ФП можно назвать парадигмой в силу минимализма ограничений.

                                                                                                      Ничего себе минимализм — отсутствие состояния.
                                                                                                      Но сколько математики нуждающейся в нарушении принципов ООП даже в математическом проекте типа Matlab или AutoCad? Даже в этих специальных пакетах она накрепко инкапуслирована в своих библиотеках и составляет наверное не очень большую часть кода.

                                                                                                      Я могу бесконечно критиковать ООП в матлабе.
                                                                                                      Во-первых, подобно PHP, вместо того, чтобы взять за основу динамическое ООП типа смолтока, взяли за основу Java. В динамическом языке. Кошмар. Но это к делу не относится.

                                                                                                      Есть оптимизационная либа CPLEX с двумя интерфейсами, классическим матлабным и ООП. Вот эквивалентный код.
                                                                                                      y = cplexqp(cov(dailyReturns), linearPart, -oneVec, 0, expectedReturn - rf, 1);
                                                                                                      Против:
                                                                                                      cplex = Cplex('A'); cplex.Model.sense = 'minimize'; cplex.addCols(zeroVec', [], zeroVec', inf * oneVec'); cplex.addRows(0, oneVec, inf); cplex.addRows(1, expectedReturn - rf, 1); cplex.Model.Q = cov(dailyReturns); cplex.Param.qpmethod.Cur = 6; %(1) concurrent algorithm cplex.Param.barrier.crossover.Cur = 1; %(2) enable crossover cplex.solve(); y = cplex.Solution.x;

                                                                                                      В реальном скрипте приходится писать по второму варианту из-за строчек (1) и (2) с опциями. Не-ООП интерфейс не полон. Хороший matlab-style код выглядел бы как y = cplexqp(..., ..., cplexoptimset('Crossover', 1)); — так устроен родной генетический оптимизатор, например.

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

                                                                                                      1. Функции не нужен конструктор. Когда нужен, он элементарно делается на ФВП. y = @(y)@(x) foo(x, y); Десяток паттернов вида конструктор+метод (от Команды до Абстрактной фабрики) — завуалированные функции.
                                                                                                      2. Функции не нужен метод Solve, она по определению что-то делает.
                                                                                                      3. Не нужно разбираться, где точки входа и выхода. Если выходов несколько, можно вернуть кортеж.
                                                                                                      4. Методы addRows и addCols превращаются в параметры. Если функция выглядит тяжеловесной, умолчания всегда можно на месте упаковать: add5 = @(x) add(x, 5);
                                                                                                      5. Параметров у таких функций много, поэтому нужна возможность IDE выдачи названий параметров, а редкие параметры именуются а-ля cplexoptimset('Crossover', 1).

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

                                                                                                      Первоклассная функция — это такой ограниченный объект с одним входом и выходом. В отличие от объекта в ООП, эта ограниченность дает возможность функции комбинировать. Я не люблю ФП, потому что не считаю, что отсутствие состояния стоит секса со стеком трансформеров, но сами функции люблю, потому что это простые инженерные коробочки; у каждой всегда ясно, где точка входа, где выход.
                                                                                                      • –1
                                                                                                        К сожалению, я практически ничего не понял из того что вы написали. Это слишком специфические примеры для обсуждения которых требуется хорошее знанием функционального языка.

                                                                                                        Кроме того я не спорю, что для ФП есть обширная область применения. Тем более в силу моего увлечения ИИ я постоянно чувствую притяжение тёмной стороны силы со стороны ФП.

                                                                                                        Да, в ООП есть состояние, а в ФП нет и этим всё сказан