Anonymous methods/functions: a fundamental feature or a violation of OO principles?

Question

Is the recent movement towards anonymous methods/functions by mainstream languages like perl and C# something important, or a weird feature that violates OO principles?

Are recent libraries like the most recent version of Intel's Thread Building Blocks and Microsofts PPL and Linq that depend on such things a good thing, or not?

Are languages that currently reject anonymous methods/functions, like Java, making wise choices in sticking with a purely OO model, or are they falling behind by lacking a fundamental programming feature?

Answer 1

The expressive power of lambda expressions combined with fluent APIs like LINQ far outweigh any perceived violation of pure OO principles.

Answer 2

Object Orientation is a design philosophy, not a set of commandments on stone tablets.

Since lambda functions increase the power/expressiveness of the language many-fold, refusing them merely on "it violates pure OO model" is rather self-defeating: the overall goal is to design good software, NOT to design OO code.

Plus, I'm not quite certain that correctly written lambda functions "violate OO model" per se. More like are outside of the model.

Answer 3

Python has always had them.

A function is a class of objects with a really narrow interface and not many attributes.

Python function objects have a number of built-in attributes, and you can always add more if you want.

Answer 4

No inherent violation of OO pronciples anyway.. Not that I can see...

Encapsulation, Inheritence and Polymorphism being the canonical list, AM are not inconsistent with any of the three... They are a method, not a Type... So just like a full .Net 1.1 representation of a Method Delegate, they can be written to use or abuse any of the three OO principles.

Answer 5

C# has always had delegates; its always had event handling. The CLR 2.0 (and C# 2.0) introduced the concept of anonymous delegates to meet a variety of needs that could probably have been solved with design patterns in any OO technology. They've just made it official that functions are "first-class objects" in these technologies.

I dare say that the mixture of functional and object features in a technology like C# has become so useful that its hard to imagine writing applications without the benefits of both worlds.

Answer 6

Callbacks are a fundamental part of OO. It rather makes sense to have good syntactical support for the common case of a single-method callback object. Exactly how that is implemented is another matter.

Answer 7

Java's not "sticking with a purely OO model" out of principle; the Java community just can't agree on what functional additions to the language should look like or whether they're worth the additional complexity in the syntax. According to James Gosling:

Closures were left out of Java initially more because of time pressures than anything else. In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues. But as is normal in so many design issues, the simplifications didn't really solve any problems, they just moved them.

(From "Understanding the closures debate", which is a pretty good overview of the state of the functional programming debate in the Java community as of last summer. The consensus seems to have been to punt on it for now.)

Answer 8

How would it violate OO principles?

It doesn't violate encapsulation: A class is still in full control of which functions get access to its private members.

It doesn't interfere with inheritance or polymorphism either.

It only violates OO principles if you're a Java programmer and define "OO principles as "can be implemented in Java"

Luckily, no one outside the world of Java, have ever used such a definition of OOP.

It may be said to violate Java's philosophy, which I'd say is a good thing, because Java's philosophy is essentially "start with a broken and mangled version of OOP, and stay there, without ever adding to it or evolving it in any meaningful way". That's not a philosophy that deserves to stay unbroken.

But it doesn't violate the principles of OOP.