Bouncer Pattern

I don't know if it's a global term, but where I come from a bouncer is a doorman at a night club. If he doesn't like you, or you don't fit the night club's desired clientele, he refuses to let you in. If you want to argue, he'll punch you and throw you out into the street.

In software, a bouncer is a method whose raison d'être is to either throw an exception or do nothing. A simple Java bouncer would be one that checks that a parameter is not null, and throws an IllegalArgumentException if it is.


Is this the same as an assertion, or a precondition? --RalphMellor

It's an assertion. The bouncer only does its job when called on. Of course, if a method has a precondition it wants to check, it could assert that the precondition is satisfied by calling an appropriate bouncer at the top of the method.

Personally, I can only think of one reason why a bouncer method is useful: you can put a nice, readable name or an assertion (e.g. checkBoundingBoxConstraint). If this assertion is needed in more than one place OnceAndOnlyOnce favors the bouncer method too.


 void checkNotNull(String name, Object obj) {
 if (obj == null)
  throw new IllegalArgumentException(name + " is null");
 }

public void doStuff(String name, Object value) { checkNotNull("name", name); checkNotNull("value", value); ... do stuff ... }

In this example, checkNotNull is the bouncer.

This example is maybe too trivial, as the pattern is most useful when the condition to be checked is more complex and needs to be used for multiple methods, such as there exists a row in the database with this primary key.


java.lang.SecurityManager[http://java.sun.com/products/jdk/1.2/docs/api/java/lang/SecurityManager.html] is a collection of bouncers. -- MartinPool

[JavaSecurityManager]


This is similar to another pattern on Wiki (I can't find the page), where an object has an OK() method that validates its internal structure. CodeClassInvariants?


In NewYorkCity, there are many clubs that have two different roles for doorman. First is the bouncer role described above. Second is the role of choosing people for admittance based on appearance, style, etc., etc. Studio 54 was the first to do this. You could critically describe this as a typical manifestation of the kind of insecure status-seeking behavior highly apparent in large cities. You could charitably describe this as the maintenance of a social environment that is impossible without this sort of social filtering.

This possibly has nothing to do with BouncerPattern and OO design; I just felt like throwing it in.

This could be related. The first role matches SecurityManager's bouncer methods and similar constructs whose purpose is to decide whether something is possible or permitted based on the state of the object containing the method (i.e. letting people in based on how busy the club is, or whether it's a free night..etc). The second is more like the GatedCommunity? described below, where the bouncer's purpose is to check the data provided as an argument in the context of the object (is someone dressed well enough for this club..). With that analogy, the above example of checkNotNull is actually of the second category. Not sure if this is actually a useful extension of the analogy, but it seems consistent to me. =) -- TorneWuff


Also see GuardClause.

A bouncer is effectively a guard clause which can check object state or parameters, with the added constraint that because it is a method it is liable to be called from anywhere and so can play no role in executing the business logic of its caller. They should never return answers like the guard clauses do. This is consistent with my opinion of real bouncers, i.e. that they have no intelligence and are only good at ejecting people. --JohnFarrell

How about the GatedCommunityPattern? (discussion moved to that page)


Category: JavaIdioms

Parallel: GatedCommunityPattern

Contributors: RalphMellor, JohnFarrell, MartinPool, MartySchrader


EditText of this page (last edited May 25, 2005)
FindPage by browsing or searching

This page mirrored in JavaIdioms as of April 29, 2006