Given the following code:

class AnimalDescriptor {
    String species;
    boolean hasLegs;
    boolean hasTeeth;
    boolean hasHair;

    public AnimalDescriptor(String species, boolean hasLegs, 
                            boolean hasTeeth, boolean hasHair) {
        this.species = species; 
        this.hasLegs = hasLegs; 
        this.hasTeeth = hasTeeth; 
        this.hasHair = hasHair;

class Animal {
    AnimalDescriptor control;
    String name;
    int numberOfLegs;
    int numberOfTeeth;
    String colorOfHair;

class doStuff {
    public void go() {
        AnimalDescriptor dog = new AnimalDescriptor("dog", true, true, true);
        AnimalDescriptor pirahna = new AnimalDescriptor("pirahna", false, true, false);

        Animal fido = new Animal();
        fido.control = dog;
        fido.name = "Fido";
        fido.numberOfLegs = 4;
        fido.numberOfTeeth = 42;
        fido.colorOfHair = "black"; //All good here

        Animal bob = new Animal();
        bob.control = pirahna;
        bob.name = "Bob";
        bob.numberOfTeeth = 42; //So far so good
        bob.numberOfLegs = 2; //This should pass compilation, but fail 
                              //validation at run-time, since it is 

Is there a pattern name for what I'm doing here? I've tried searching variations on my question title but haven't gotten anywhere.

Obviously, this is an extremely simple and abbreviated example, AnimalDescriptor should have a bool .validate(Animal a) method, as well, and Animal should have an .isPropertyAvailable(String propertyName) method, among other additions. I didn't want to bog everything down with a 500-line minimal-case example.

There's no way that I'm the first or only person to do this, and I'm mainly looking for something I can latch on to for further research into best practices, implementation pitfalls, etc.

EDIT: To provide a little more clarity, in my system, there are ~20 booleans in the "control" class (AnimalDescriptor). I'm tracking ~106 items (Animals) in ~103 categories (AnimalDescriptors) that share a pool of common properties, but each item only has the properties that are designated by its "control" configuration. Plus, the system should be able to expand to, say, 104 categories (AnimalDescriptors) over the next 5 years. We have a functional (if ugly) implementation, so I don't need validation or exception how-tos -- I'm more interested in how this problem has been approached in other domains/applications, benefits of implementation in a functional (as opposed to object-oriented) context, best practices, etc. It seems like there should be a name for this, but I don't know what it is.

  • Which language are you using? If you are using a statically-typed language, you may be better off defining classes for your 1000 types of animal (I'm not saying you have to hand-type it all). Nov 27, 2013 at 18:19
  • The system is currently an ugly combination of Java and Actionscript (presentation and 75% of the business logic in Actionscript, persistence and the rest of the business logic in java) -- we're currently in the process of a refactor to try and fix this.
    – ffxtian
    Nov 28, 2013 at 6:56
  • There are two reasons we've not gone with individual classes thus far: 1. our environment is such that the system should be able to grow from 1000 different control types to 2000 (or 10000) without a programmer having to define additional classes 2. the "animals" only have varying properties, not varying methods (e.g., generic .move() and .feed() methods, not .run() vs. .swim() vs. fly()).
    – ffxtian
    Nov 28, 2013 at 7:07

1 Answer 1


You seem to be describing the prototype pattern, where some of the properties of your items are determined based on some other object accessible in the system. In fact, the particular use you're describing, wherein some runtime validation code will access the properties of a particular object's prototype, is very close to how JavaScript manages its prototype based inheritance model.

If you want to different this pattern to express the variable requirements of your items from the more general prototype pattern, you might want to refer to this model as a prototype driven schema.

You could also probably just call it a schema, since the fact that you're only testing for if a particular property is allowable or not is a mere implementation detail rather than a useful feature of the pattern. (If you really wanted to prevent a pirana from having legs, you'd do what @aaron-kurtzhals suggested and just make a Pirana class.)

  • Thanks so much -- it does make more sense to call it a schema rather than a pattern. The main "problem" is, I suppose, maintaining validation/coherency across differing types with a fixed set of functionality.
    – ffxtian
    Nov 28, 2013 at 7:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.