10 edited title
| link

How to improve upon Bloch's Builder Pattern, to make it more appropriate for use in classes that may be extended and subhighly-extended many times over?extendable classes

9 deleted 40 characters in body
source | link
  1. The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

  2. The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics generics associated to it, is unwieldy.

So that is my question: How can I improve upon (what I call) the Bloch Builder, so I can feel free to attach a builder to any class--even when that class is meant to be a "base class" that may be extended and sub-extended many times over--without discouraging my future-self, or users of my library, because of the extra baggage the builder (and its potential Needable generics) impose on them?

  1. The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

  2. The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics associated to it, is unwieldy.

So that is my question: How can I improve upon (what I call) the Bloch Builder, so I can feel free to attach a builder to any class--even when that class is meant to be a "base class" that may be extended and sub-extended many times over--without discouraging my future-self, or users of my library, because of the extra baggage the builder (and its potential Needable generics) impose on them?

  1. The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

  2. The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant generics associated to it, is unwieldy.

So that is my question: How can I improve upon (what I call) the Bloch Builder, so I can feel free to attach a builder to any class--even when that class is meant to be a "base class" that may be extended and sub-extended many times over--without discouraging my future-self, or users of my library, because of the extra baggage the builder (and its potential generics) impose on them?

8 formatting
source | link

-1- The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

-2- The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics associated to it, is unwieldy.

  1. The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

  2. The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics associated to it, is unwieldy.

Thank you.

ElaboratingAddendum
My question focuses on part 2 above, but I wanted to elaborate a bit on problem one, including how I've dealt with it (I'm only asking for a response to the other part--part 2--above...not this part):

-1- The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" This is not to prevent extending classes from having to re-implement these chains, which, of course, they must--rather, how to prevent non-sub-classes, that want to take advantage of these method chains, from having to re-implement every self-returning function in order for their users to be able to take advantage of them? For this I've come up with a needer-needable design that I'll print the interface skeletons for here, and leave it at that for now. It has worked well for me (this design was years in the making...the hardest part was avoiding circular dependencies):

public interface Chainable  {  
    Chainable chainID(boolean b_setStatic, Object o_id);  
    Object getChainID();  
    Object getStaticChainID();  
}
public interface Needable<O,R extends Needer> extends Chainable  {
    boolean isAvailableToNeeder();
    Needable<O,R> startConfigReturnNeedable(R n_eeder);
    R getActiveNeeder();
    boolean isNeededUsable();
    R endCfg();
}
public interface Needer  {
    void startConfig(Class<?> cls_needed);
    boolean isConfigActive();
    Class getNeededType();
    void neeadableSetsNeeded(Object o_fullyConfigured);
}

-1- The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

-2- The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics associated to it, is unwieldy.

Thank you.

Elaborating a bit on problem one, including how I've dealt with it (I'm only asking for a response to the other part--part 2--above...not this part):

-1- The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" This is not to prevent extending classes from having to re-implement these chains, which, of course, they must--rather, how to prevent non-sub-classes, that want to take advantage of these method chains, from having to re-implement every self-returning function in order for their users to be able to take advantage of them? For this I've come up with a needer-needable design that I'll print the interface skeletons for here, and leave it at that for now. It has worked well for me (this design was years in the making...the hardest part was avoiding circular dependencies):

public interface Chainable  {
   Chainable chainID(boolean b_setStatic, Object o_id);
   Object getChainID();
   Object getStaticChainID();
}
public interface Needable<O,R extends Needer> extends Chainable  {
   boolean isAvailableToNeeder();
   Needable<O,R> startConfigReturnNeedable(R n_eeder);
   R getActiveNeeder();
   boolean isNeededUsable();
   R endCfg();
}
public interface Needer  {
   void startConfig(Class<?> cls_needed);
   boolean isConfigActive();
   Class getNeededType();
   void neeadableSetsNeeded(Object o_fullyConfigured);
}
  1. The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" For those who may be curious, I've addressed this part at the bottom of this answer-post, but it's not what I want to focus on here.

  2. The second problem, which I am asking for comment on, is "how can I implement a builder in classes that are themselves intended to be extended by many other classes?" Extending a class with a builder is naturally more difficult than extending one without. Extending a class that has a builder that also implements Needable, and therefore has significant and self-referential generics associated to it, is unwieldy.

Addendum
My question focuses on part 2 above, but I wanted to elaborate a bit on problem one, including how I've dealt with it:

The first problem is "how to share self-returning method chains, without having to re-implement them in every...single...class?" This is not to prevent extending classes from having to re-implement these chains, which, of course, they must--rather, how to prevent non-sub-classes, that want to take advantage of these method chains, from having to re-implement every self-returning function in order for their users to be able to take advantage of them? For this I've come up with a needer-needable design that I'll print the interface skeletons for here, and leave it at that for now. It has worked well for me (this design was years in the making...the hardest part was avoiding circular dependencies):

public interface Chainable  {  
    Chainable chainID(boolean b_setStatic, Object o_id);  
    Object getChainID();  
    Object getStaticChainID();  
}
public interface Needable<O,R extends Needer> extends Chainable  {
    boolean isAvailableToNeeder();
    Needable<O,R> startConfigReturnNeedable(R n_eeder);
    R getActiveNeeder();
    boolean isNeededUsable();
    R endCfg();
}
public interface Needer  {
    void startConfig(Class<?> cls_needed);
    boolean isConfigActive();
    Class getNeededType();
    void neeadableSetsNeeded(Object o_fullyConfigured);
}
    Question Protected by World Engineer
7 deleted 12 characters in body
source | link
6 added 6 characters in body
source | link
5 moved part 1 of 2 to bottom, to more focus on part 2
source | link
4 added 1 characters in body
source | link
3 Reframed as a question, with the pattern mega-section posted as an answer
source | link
    Tweeted twitter.com/#!/StackProgrammer/status/434184973713940482
2 deleted 21 characters in body
source | link
1
source | link