Why are SLSB not very object oriented?

[drapierwim]

I've been reading in the seam documentation and in 'chapter 2.1.1 Stateless contexts' there is a paragraph that says

Stateless components are not very interesting, and are arguably not very object-oriented.

Can somebody explain this more in detail, perhaps by a little example?

Thanks

[christian.bauer]

It's typical for Gavin King documentation, you'll somtimes find "arguably not very object-oriented". I'm sure you can have an argument with him about the exact meaning, I had that a few times and I suppose we agree to disagree now. ;)

[drapierwim]

Now I wonder why you disagree? For now I'm thinking of SLSB as not OO simply because they don't enclose state and behavior.

I'm just a student and still learing and very interested in this topic

[marius.oancea]

Yes, agree. This is the only reason to consider stateless bean not OO.
You could imagine stateless beans like static objects (even if they are not) and i think you already know static objects are also not considered part of OO paradigm.

Only my 2 cents
Marius

[christian.bauer]

I think object-orientation means "type inheritance" and that encapsulation is something completely different (basically, a scalar type that does not expose components but only operators is "encapsulated"). I can encapsulate stuff just fine in procedural programming languages. I can also put "state and behavior" with a type in procedural programming. But I can't do inheritance and polymorphism. You see why its arguable? :)

[gavin.king]

The point is that OO programming is supposed to encourage a style where the functionality that operates upon state, and the state that is operated upon, are packaged into a single component definition. SLSBs package only operations, and must have their state stored elsewhere (eg, the HttpSession) and passed in as parameters. This is a procedural style of development.