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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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