PicoContainer
  1. PicoContainer
  2. PICO-328

Better syntax for decorator chains

          Details

          • Type: Wish Wish
          • Status: Open Open
          • Priority: Minor Minor
          • Resolution: Unresolved
          • Affects Version/s: None
          • Fix Version/s: 3.0
          • Component/s: PicoContainer (Java)
          • Labels:
            None
          • Number of attachments :
            0

            Description

            Lets suppose we have the following three classes that implement a single interface:

            interface Service {
	void doSomething();
}


public class A implements Service() {
	void doSomething() {}
}

public class Decor1 implements Service() {
	public Decor1(Service delegate) {
		/../
	}
	
	public void doSomething() {
		//do stuff
		delegate.doSomething();
	}
}


public class Decor2 implements Service {
	public Decor2(Service delegate) {
		/.... /
	}

	public void doSomething() {
		//do stuff
		delegate.doSomething();
	}
}

            Now I want to wire them up in a decorator fashion.

            MutablePico pico = new PicoBuilder().withCaching().withLifecycle().build();

//Results in   Decor2 --- wraps --> Decor1 --wraps --> A
pico.addComponent(Service.class, Decor2.class, new ComponentParameter(Decor1.class))
    .addComponent(Decor1.class, Decor1.class, new ComponentParameter(A.class))
    .addComponent(A.class, A.class);

            The problem here is that I've never found it intuitive reading to understand how the decorators wire together.

            So, perhaps if we had some better support for a decoration pattern, it would be useful:

            //Possibility 1

            pico.addComponent(Service.class, Decor2.class)
		.wraps(Decor1.class)  // wraps Can be of the form implementation + parameters
		.wraps(A.class);
);

            //Possibility 2

            pico.addComponent(Service.class, new DecorationBuilder(Decor2.class)
						.wraps(Decor1.class)
						.wraps(A.class)
);

            The second one intrigues me the most because it is almost a quasi ComponentAdapterFactory, and it would allow us to create a specific language for wiring particular components beyond just decoration, but its downside is syntax complexity. (Then again, I actually kinda enjoy working with JMock2 these days so maybe the syntax isn't a problem)

              People

              • Assignee:
                Unassigned
                Reporter:
                Michael Rimov
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: