Анонимные методы / функции: фундаментальная особенность или нарушение принципов ОО?

Question

Является ли недавнее движение к анонимным методам / функциям основных языков, таких как perl и C #, чем-то важным или странной функцией, которая нарушает принципы ОО?

Являются ли последние библиотеки, такие как самая последняя версия Intel Thread Building Blocks и Microsoft PPL и Linq, которые хороши или нет, зависит от таких вещей?

Являются ли языки, которые в настоящее время отвергают анонимные методы / функции, такие как Java, разумным выбором, придерживаясь чисто ОО-модели, или они отстают от недостатка фундаментальной функции программирования?

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Инкапсуляция, наследование и полиморфизм, являющиеся каноническим списком, AM не несовместимы ни с одним из трех ... Это метод, а не тип ... Так же, как полное представление .Net 1.1 делегата метода, они могут быть написаны для использования или злоупотребления любым из трех принципов ОО.

Answer 4

C # всегда имел делегатов; У него всегда была обработка событий. В CLR 2.0 (и C # 2.0) была введена концепция анонимных делегатов для удовлетворения разнообразных потребностей, которые, возможно, можно было бы решить с помощью шаблонов проектирования в любой ОО-технологии. Они только что официально заявили, что функции являются «первоклассными объектами». в этих технологиях.

Осмелюсь сказать, что сочетание функциональных и объектных функций в такой технологии, как C #, стало настолько полезным, что трудно представить, что написание приложений без преимуществ обоих миров.

Answer 5

Java не «придерживается чисто OO-модели» из принципа; сообщество Java просто не может договориться о том, как должны выглядеть функциональные дополнения к языку или стоят ли они дополнительной сложности в синтаксисе. По словам Джеймса Гослинга:

  

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

(От " Понимание обсуждения замыканий " ;, который является довольно хорошим обзором состояния дебатов по функциональному программированию в сообществе Java по состоянию на прошлое лето. Похоже, консенсус на данный момент уже решен.)

Answer 6

Python всегда имел их.

Функция - это класс объектов с очень узким интерфейсом и небольшим количеством атрибутов.

Объекты функции Python имеют ряд встроенных атрибутов, и вы всегда можете добавить больше, если хотите.

Answer 7

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

Answer 8

Как это нарушит принципы ОО?

Он не нарушает инкапсуляцию: класс все еще полностью контролирует, какие функции получают доступ к своим закрытым членам.

Это также не мешает наследованию или полиморфизму.

Это нарушает принципы ОО только в том случае, если вы являетесь программистом на Java и определяете «принципы ОО, поскольку» могут быть реализованы в Java »

К счастью, никто за пределами мира Java никогда не использовал такое определение ООП.

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

Но это не нарушает принципов ООП.