Strategy Pattern for EJB stateless session beans

[vShyam Sundar]

Hi all,
Can any one help me in understanding how a strategy pattern can be used with stateless session beans for code re usability


Thanks,
Shyam.

[Hebert Coelho]

I use like this:

@Entity
public class CarImp implements Car{
//...
}

@Statless
public class CarDAOImp implements CarDAO{
//put a crud in here
}

@Statless
public class CarFacadeImp implements CarFacade{
     //add your methods and inject other interfaces here
     @EJB
     PersonFacade;
     @EJB
     CarDAO
}

This is how I use it.

[vShyam Sundar]

Hebert, Can you explain me in detail?


Thanks,
Shyam.

[Hebert Coelho]

vShyam Sundar wrote:Hebert, Can you explain me in detail?


Thanks,
Shyam.

Which detail do you need? I do use like that, all my façades are stateless that implements an Interface.
Those interfaces are injected inside others Session Beans.

[vShyam Sundar]

So by this way you say that. your injected bean acts as a strategy algorithm which can be changed without clients knowledge(In this case bean's knowledge)

[Hebert Coelho]

Yes. That is how I see it. [=

[Roberto Perillo]

Hebert Coelho wrote:Yes. That is how I see it. [=

Hum... in your example, who is the strategy? How do you choose different strategies at runtime?

[Mr sujeet khandelwal]

Hi Shyam,

As far as i know strategy pattern is not used for code re usability. Strategy pattern is to used to select the algorithm at run time.

In EJB, we can have multiple implementation of business interface and at run time we can decide conditionally which implementation has to be selected.

Thanks

[Roberto Perillo]

Mr sujeet khandelwal wrote:In EJB, we can have multiple implementation of business interface and at run time we can decide conditionally which implementation has to be selected.

Conditionally? With "ifs"?

[Hebert Coelho]

Mr sujeet khandelwal wrote:As far as i know strategy pattern is not used for code re usability. Strategy pattern is to used to select the algorithm at run time.

Hello, Mr sujeet.

I have read the book HeadFirst Design Pattern and I wrote an post about strategy: Design Pattern: Strategy.
And the Strategy principles are:

Identify everything that changes and isolate it from what does not change.

Program to an interface.

Give priority to composition rather than inheritance.

As I can see, it is a good pattern that helps with code resuability.

[Andrew Moko]

Hebert Coelho wrote:

Mr sujeet khandelwal wrote:As far as i know strategy pattern is not used for code re usability. Strategy pattern is to used to select the algorithm at run time.

Hello, Mr sujeet.

I have read the book HeadFirst Design Pattern and I wrote an post about strategy: Design Pattern: Strategy.
And the Strategy principles are:

Identify everything that changes and isolate it from what does not change.

Program to an interface.

Give priority to composition rather than inheritance.

As I can see, it is a good pattern that helps with code resuability.

Seperation of concerns. That was a good read!!

[Roberto Perillo]

Hebert Coelho wrote:
Hello, Mr sujeet.

I have read the book HeadFirst Design Pattern and I wrote an post about strategy: Design Pattern: Strategy.
And the Strategy principles are:

Identify everything that changes and isolate it from what does not change.

Program to an interface.

Give priority to composition rather than inheritance.

As I can see, it is a good pattern that helps with code resuability.

Right... in the example of your blog, do you agree that, when you say "engineBehavior = new RegularEngine();", you are not isolating things that change from what does not change? In your example, having an interface or not doesn't make any difference, right? Also, in the second figure of your post, don't you mean "Batman" instead of "Bataman"?

[Andrew Moko]

Coming to think of it, with every child object created there's an unused RegularEngine object. That's not a good practice imho

[Roberto Perillo]

Andrew Gabriel wrote:Coming to think of it, with every child object created there's an unused RegularEngine object. That's not a good practice imho

Agreed. In his examples, objects will also be created unnecessarily.

[Hebert Coelho]

Andrew Gabriel wrote:Coming to think of it, with every child object created there's an unused RegularEngine object. That's not a good practice imho

How you would do it? When a class need to extend another?

[Roberto Perillo]

Hebert Coelho wrote:How you would do it? When a class need to extend another?

In your examples, you already know the algorithm that you are going to use, so you don't really need to apply the Strategy pattern. This would be over design.

But, one thing that would improve your example would be:

public abstract class ToyCar {

    private EngineBehavior engine;

    protected ToyCar(EngineBehavior engine) {
        this.engine = engine;
    }

    protected EngineBehavior getEngine() {
        return engine;
    }

    public abstract void startEngine();

    // More code here...
}

public class SuperHeroCar extends ToyCar {

    public SuperHeroCar(EngineBehavior behavior) {
        super(behavior);
    }

    public void startEngine() {
        getEngine().startEngine();
    }
}

This improves your design, since no objects will be created needlessly. The object model also makes more sense now, because in your domain, toy car is an abstract concept. In order to get the engine, only subclasses of ToyCar will be able to do so, and the getEngine method won't be available in the ToyCar's API.

[vShyam Sundar]

Hebert, as your first reply says. That you will be invoking your session beans again from a bean . Does this not make 'N' number of network calls in the case of EJBs existing in the Remote location.Which in turn leads to poor performance

I think a Session bean can invoke a method in java class where a strategy pattern could be applied--> please comment on this.


Robert and Hebert. Thanks for your valuable replies. I am in the process of learning things.

Thanks,
Shyam.