Consequences in Java

Creation Code 128A in Java Consequences

The Consequences section of a pattern s catalog entry lists both the good and bad effects of the pattern Your pattern, being the most advanced and excellent one the world has yet seen, may not have any apparent drawbacks, but think hard on this point it wouldn t be good if you steered someone into using your pattern if that pattern s going to cause him or her problems For your new Veto pattern, you might say: The consequence of this pattern is that it allows you to encapsulate the voting objects so that any object may make its decisions independently of the code in other objects, and any object may veto a request You are also assured that each link in the object chain gets a chance to veto a request before sending it on to the next object On the other hand, encapsulating all the decision-making components into discrete objects can be a problem because doing so can deny one object needed information from the rest of the objects If that s the case in your implementation, consider combining two or more link objects into one as needed so that encapsulation won t be violated Another potential problem comes when one object in the chain of objects doesn t pass on a veto correctly Because the objects are in a chain, you re dependent on the correct functioning of each link in the chain to get the proper results

The Implementation/Sample Code section of a pattern s entry in a pattern catalog outlines the techniques you use when implementing this pattern and/or sample code For the Veto design pattern, you might say something like this: When you want to check if a request will be accepted or vetoed, give each link (and the Link interface) a method that will be passed a Boolean value If any link vetoes the request, that link should pass a value of false to the next link in the chain, and any such veto should be passed on by having each subsequent link in the chain pass on a value of false if it was passed a value of false The last link in the chain should be connected back to the client code so that that code may receive the results of the accept/veto process Here s some sample code that implements the new Veto pattern Each link in the chain can veto a request sent to it, and in this example, it s simply passed a Boolean true/false value to a method named check that must be implemented by each link Here s what that method looks like in the Link interface:

public interface Link { public void check(boolean b); }

To connect the links in a chain, you pass the next link in the chain to the current link s constructor when you instantiate the current link The following code shows what that looks like in the Link1 class, the first of the links in our chain, which implements the Link interface:

public class Link1 implements Link { Link next; public Link1(Link n) { next = n; } }

If the link s check method is passed a value of true, this link just passes that value along to the next link in the chain

public class Link1 implements Link { Link next; public Link1(Link n) { next = n; } public void check(boolean b) { if(b){ nextcheck(true); } }

On the other hand, if the check method is passed a value of false, meaning some link in the chain has already vetoed the request, this link should pass on that veto by calling the next link s check method with a value of false

public class Link1 implements Link { Link next; public Link1(Link n) { next = n; } public void check(boolean b) { if(b){ nextcheck(true); } else { nextcheck(false); } } }