Programmers often treat all kinds of errors the same, especially when a user interaction is involved.  The problem is, not all errors have the same “meaning”, and not all errors should be handled the same way.  If, as a User, I attempt to use the program for something, and it reports a message target at a programmer (displaying a stack-trace, for instance), it can be confusing.  As a High-Level programmer, if a library call fails but my code gets back few details (getting only ‘There was an SQL error’, without the SQL statement that caused the error), it can be just as frustrating.

What do you mean by low-level or high level?

There usually different “levels” to an application, and each level has a specific type of concern.  Errors on lower levels should be filtered up in as appropriate a manor as possible, so that the higher levels can handle them as gracefully as possible.  Applications can have many different layers, but conceptually they can usually be represented in exactly four levels. What are those four layers? I’m glad you asked, because I’ve listed them below, from highest to lowest.

The User

This, of course, is the person using your application. Most often they are a human being, but someday users may include Artificial Intelligence or Extra Terrestrial entities.  Users are often task-oriented, although some of them are naturally explorers.  Task-Oriented users are more damaged by unexpected errors. Exploring users are more interested in seeing what is and isn’t possible, so errors often define a boundary for them, but these users are also most likely to find bugs in your application.

High-Level Code

This is sometimes called the “Domain” level.  The public methods in these classes are often task-oriented, and the class often define nouns that the User would be able to identify with.  Code in this level translates between user requests and low-level requests. This is of course an idealized definition, but the closer to this definition you can make your reality, the easier to maintain your application will be.

Low-Level Code

This is the library or framework code.  Code in this level usually is used to handle resources, and to actually get things done.  Most Low-Level code is “possibility” oriented. The API defined allows you to do simple, atomic, operations that might not be meaningful on their own, but can be strung together in a useful manor.

Resources

These are “external” things used by the application. Some examples are memory, files, databases, and sockets . Consumable (memory, disk-space, etc…) resources can run out unexpectedly, even if you “check” before hand.  Many resources fail for various reasons, for example sockets might fail because of a disconnected wire, files might fail because of a physical disk error, and database operations might fail due to overloaded CPU or low available memory.

Note, that there can be some “blurring” of levels, depending on the project you are working on.  For example, the developer of an HTTP Client library is probably writing “high-level” code, in that it represents the domain of HTTP, and provides “task-oriented” interfaces.  However, when that HTTP Client library is used in an application, it becomes “low-level”, because the User probably doesn’t care about the HTTP Protocol, and instead only cares about “downloading a file” or “viewing a web-page”.

From my experience, each of the levels correspond to a different kind of error, and those errors should all be handled differently. The likelihood of most of the types of errors can be managed, but not eliminated completely.

Error Handling

Handling User errors

This is the highest-level error.  It is caused by a user doing something they shouldn’t.  Most commonly this means the user entered an invalid input somewhere.  Whenever possible, the User Interface should be designed to prevent user errors.  For example, if you need a date then you provide a “Date Widget” and if you need a number you disallow non-numeric input.

Sometimes, it isn’t feasible to simply “prevent” user error.  In this case, the user input must be validated.  The best place to validate it is in the High-Level code.  Since this code is closest to the user, it has more knowledge about the user.  The High-Level code knows whether to pop-up a dialog box, print a line to the console, or update a form with error messages.

It may sometimes useful abstract the “error reporting” interface, so that it can be reused by different  UI interfaces. For example, domain level code might be used in a Web App, as well as a native GUI app, or even a command-line app.  Having an reusable interface for reporting multiple user errors helps in porting to new user interfaces.

Usually, it should be considered a bug in the high-level code if invalid user input causes a lower level exception. Low-Level code must verify the input it receives from higher-level code.

There are times, however, when it is infeasible to verify before hand whether an input is valid, and the validation must be handled a lower-level code.  In this case, the lower-level code should report the error to the higher level code, which should handle it and pass that information on to the user in an appropriate manor.

Handling Bugs

Bugs can happen in either low-level code, or high-level code.

In High-Level code, it means that some method (often a user task-oriented method) has violated some constraint, or failed to handle a lower-level error. In Low-Level code
it means that a method (part of a framework or library) has violated some constraint, or failed to properly handle a Resource Error.

First and foremost, it is rarely appropriate to show all the detail of “bug” caused errors to the user.  Most users would prefer not to experience bugs at all, but because this is the real world, we have to handle the bugs some how.  Most times, its enough to tell the user “There was an internal error.  Click ‘Report’ to send a bug report.”  The bug report should include any useful state information, but absolutely must include a full stack trace.  If possible, the high-level state should be recoverable, so that the user doesn’t lose any of their work, and can try either a slightly different approach, or wait for a bug fix.

The number of errors of these kinds can be reduced by Unit Testing, improving API design, Integration Testing, and User Testing.

Resource errors

These are Exceptional Circumstances.  Resource errors can be caused by bad data, connectivity issues, database constraint violations, file corruption, file-not-found, out-of-memory, and many more uncontrollable problems.

Resource errors should be reported to the user with as much detail as is likely to be useful to them.  If the user specifies a file, and that file is in the wrong format, this could be treated as a user error, and the user should be informed of the file they chose, and what was wrong with it.  Low-level code should report to higher-level code something along the lines of “I expected a FOO file,” and the higher-level code should report something like “The file c:\my.bar is not a FOO file. “  If a file can not be found, an appropriate message should be displayed, etc…

For this reason, low-level code which handles resources should report errors with as much structured information as feasible to higher-level code.  The higher-level code can then query that structure and produce an error message which is appropriate for the user.  For example, an SQL error at the lower level might mean different things; Typically duplicate a record might a User Error, but a syntax error is likely Low-Level Programmer Error.

There is far less that can be done to reduce resource errors, as they are often caused by external circumstances.  Often times using redundancy can reduce the frequency of fatal errors, but the errors themselves will still occur, and should still be handled appropriately.

One very common cause of bugs is miscommunication. This is really not a bug, but an unimplemented feature; if there was a requirement that wasn’t met, it is often labeled as a bug. It really could have been a misunderstanding of what the requirement actually was, or even that there was a requirement at all. No one is to blame, but that doesn’t mean someone couldn’t have prevented it. If you think there is a missing requirement, bring it up. If you don’t understand a requirement, get it clarified.

Bad assumptions can also lead to bugs. Specifically, if you assume that some external API will handle all the cases you need it to, but for at least one case the behavior isn’t what you assumed, you have a bug. It can be hard to determine for this whether the bug is in your code or the external code. Usually that can be determined by the documentation of the third party code. If its not documented, its undefined.

Ambiguity can lead to bad assumptions. If the documentation is ambiguous, try looking in the source, or writing a unit test. Update the documentation to be less ambiguous if you have access. Also make sure to add assertions to your code.

Mistakes happen. A bug can be the result of a simple mistake. Sometimes you type one thing while you’re thinking something else. If you were (un)lucky enough to type something the compiler was okay with, a bug is born. eg, A common bug in c and c++ is the =/== bug where “if (i = 1)” is an (=) assignment, but was probably meant as an (==) comparison.

What was I writing about? Forgetfulness might also lead to bugs. “Oh, I’ll just fill this method out later,” or “I’ll write the ‘else’ case tomorrow.” Judicious use of “TODO” comments and the like can help with this problem.

“That does not compute.” Sometimes, there isn’t a bug, per se, but your algorithm fails in certain cases. Maybe the case is impossible to solve in human-scale times, maybe you’re using a heuristic that has a flaw. These kinds of “bugs” are harder to solve, since the programmer has done everything right. Research other algorithms, or put in checks to verify (as much as possible) the input will work with the algorithm.

And as such, these bugs get into the code base. The next phase should filter out bugs. The testing phase. How do bugs progress from codebase into production systems?

Murphy’s law applies a few ways to testing. There is always “the tiniest little change that couldn’t possibly cause any problems.” If you don’t test after making it, it will cause a problem.

Unit testing can do a lot to verify that one unit works for the tested use cases. Sometimes the unit test doesn’t find bugs that come from complex interactions between two separate units, or the unit test doesn’t actually test all cases.

Putting your product in front of a user can help you find more bugs. Murphy’s law as it applies: The first thing a user will do is the only combination of things you didn’t test. That combination will fail. This is not a bad thing though. It lets you know exactly what unit-test you forgot to write. Don’t just fix the bug, fix the test. Write a test that fails for that series of actions, and then make the code work correctly.

No code will ever be 100% bug free. If it is 100% bug free, it probably isn’t very useful. Of course, this is a generalization, but it is often the case. Don’t become discouraged because of bugs. Fix them one at a time, and document the ones you won’t fix in this release as “unsupported features”. If you think a poor design is causing the easy of creating bugs, or a better design would prevent them, then go ahead and consider refactoring. Just know that a new design will have new bugs too. They may be easier to spot and easier to fix, so don’t rule the redesign out flat.

So now we know the reasons bugs get created, how do we find their cause?

Causality. We know of the existence of a bug because of its effect. A number is wrong, or we get a NullPointerException, or Mr. Smith gets Mrs. Robinson’s bill. Where in the codebase should the “correct” behavior be? Look there, add debug logging or break points of some sort. Assert your assumptions and watch what happens. What if that code appears to be doing the right thing? Maybe the bug happens before that point. From where in the codebase does this behavior get invoked? Repeat the process there. Feel free to use “gut” intuition to find where you think the bug is, but verify that the bug is there before “fixing” it.

Also, no bug is so old that it can’t be fixed. Even 25 year old BSD bugs can be found and fixed.

The problem that I seem to run into time and again is that I’m an OO programmer first.  I tend to think of things top-down.  What’s the overall system look like? What are the large pieces? What fits “in” those large pieces?

When you work this way, you tend to end up with a tree of objects or even more complex graph of objects.  The interesting thing about a graph of objects is that it is, above all else, a graph, and there are many ways to represent graphs.

Fundamentally, all graphs are a set of Nodes and (directed) Edges, lets examine a few common ways to represent nodes and edges.

• Each node knows which other nodes it connects to. In other words, the nodes know there out-going edges. This is close to how most common OO programming languages work; an object is the node, and any reference to another object is a one-way edge.
• Each node knows which other node connects to it. The nodes know about there in-coming edges. This is the strict opposite of the above. It is also common in relation models with one-to-one relationships.
• A list of nodes and a list of edges are maintained independently from each other.  This is common in relational models with many-to-many relationships.
• A combination of all of the above.

Any graph can be represented in any one of the above ways (as well as many others).  This is important to realize, because it gives you the ability to refactor an OO design into something that better fits the relational model.  There will always be a disconnect between OO and RDBMS, because they look at design in fundamentally different ways, but that doesn’t mean you can’t work with both of them in the same system, leveraging their individual strengths.

A common idiom is to use Dependency Injection to separate the creation of the object from the use of the object. The client object has some way to receive other objects it needs to “talk” to, but the client object doesn’t care how they were created:

class MyClient {
   MyFooService fooService;
   MyBarService barService;
   public MyClient(MyFooService fooService, MyBarService barService) {
      this.fooService = fooService;
      this.barService = barService;
   }

   public void doStuff() {
      fooService.iLikeFooFighters();
      barService.buyRoundsForEveryone();
   }
}

From this code snippet, FooService and BarService could be interfaces, abstract classes, or even concrete classes. If you change your mind later about them, MyClient doesn’t have to change at all

Another common approach for DI is to use setter based injection. This approach is useful for complex object graphs that have cyclic dependencies. I’ll leave it as an exercise for the reader to re-write MyClient with setters.

So, in this phase one, you’ve separated the concern of object creation and wiring from object usage. It is perfectly acceptable to stop here. However, depending on how complicated your object system is, you may wish to separate the concerns even further. You can do this via the Builder pattern (nb. The current Wikipedia entry on Builder pattern is incorrect and misleading.)

With the builder pattern, you separate the concern of creation from the concern of “wiring”. The builder accepts a series of objects that belong in a graph. The builder knows how to connect the objects through DI, but doesn’t care where the objects came from or how they were created/configured.

In a recent project of mine, I had to create a Robot instance, and wire it with a lot of components. To make things worse, some of the components also needed sub-components, and some components needed to know about other components, and some needed to know about the robot itself. I had successfully created a class that would create the components and wire them together, but it was a bit fragile (do things in the wrong order and you get an NPE, since not all of the components were created yet).

To solve this design issue, I created a class (HardwareContext), which held a reference to every component that it takes to build a robot. Those fields were populated using setter based dependency injection. Once those references are all created, hardwareContext.wireRobot() is called, and that is where all of the object graph is connected. This would allow me to create a new hardware context that wired the components differently if I needed to. It also allows me to create a new HardwareSpecification (the class that creates components), which creates different configurations for the robot.

This leads to a highly extensible and configurable system. It also makes it easy to figure out where to add a line of code. If the line is doing wiring, it goes into the Context, if it is creating an object, it belongs in the Spec. Easy, clean, clear.

“Why am I getting ‘Exception in thread “main” java.lang.NoClassDefFoundError: FOO (wrong name: Foo)’?”
Remember, Java is case sensitive, but the Windows file system is *not*.

public class Foo {
  public static void main(String...args) {
    new FOO();
  }
}

class FOO {
  public FOO() {
    System.out.println("Works like a charm.");
  }
}

When you compile this on Linux, you get “Foo.class” and “FOO.class”, but on Windows, you only get one file. Oops!

So, its always a good idea to follow good convention with regards to capitalization. Use CamelCase, and treat abbreviations as words. Use XmlParser rather than XMLParser. Note that some of the standard Java API doesn’t do that (URL for instance).

The truth is that using any of those approaches to design may well leave you with a brittle, unmanageable, ugly mess. Personally, I strive for the “real-life concepts” as one top-level goal. The other top level goal is decoupling. Transcending all goals, of course, is creating a “correct” program. Not necessarily “correct” in the academic sense. I don’t verify every algorithm I use, and I don’t necessarily determine valid pre/post conditions. I mean correct in as much as, it works for what I need it to work for.

For small programs, this is pretty easy. When you get to larger systems, this becomes a slightly different problem to solve. In the days of goto, spaghetti code arose due to poor organization and ad hoc control transfer. Structured programming helped some by organizing the control codes into a set of well-defined idioms. Object oriented programming helped further by organizing responsibility into encapsulated modules. All of these paradigms had something in common; you could write brittle code or malleable code in any one of them. Granted, writing flexible code has gotten easier with Object Oriented programming, but only if you know what makes code brittle.

Over dependence of one section of code on another section of code. In software engineering, we call this coupling. If the behavior of A is dependent on the behavior of B, then A is dependent on B. Changing the behavior of B could change the behavior of A. This isn’t always a bad thing, but if A and B are written by different people (or the same person at different times) with different goals, it could be catastrophic. It isn’t always feasible to decouple two classes, or two methods, or even two lines of code, but if you can do it easily, consider what might be gained by that.

One syndrome I’ve noticed is that with any concept, some people take it to the extreme. For those readers who stopped at the above paragraph and decided I was right, and everything should be as decoupled as possible, you might see a design that I would call disintegrated. It is possible to create code that is so decoupled as to be impossible to figure out how one thing affects another, even though the overall system is design for A to affect B. Don’t do this

One approach to decoupling two classes is to have them communicate through an event system. This will couple them both to the event system, but not to eachother. This approach allows you to replace one of the pair without changing the other side at all. This makes a lot of sense for GUI applications, for example, where user interactions with the component (such as a button) generates an event that can be handled very differently, depending on the needs of the program. Most object oriented languages, and Java in particular, already has a useful mechanism for invoking behavior on other objects. Its called method invocation, the act of making a method call. Event systems are useful for decoupling the method call from the class that needs to know about the call, its not so useful as a replacement for normal method invocation.

There are plenty of other ways to decouple you code (often through use of patterns), but I won’t get into them here. GIYF

Software design is about making difficult choices. If you didn’t have to make choices, then it would be easy to create a simple program that can design software. Your job as an engineer is to decide what should be decoupled from what. Decoupling can be a great tool to create a reusable component, but not everything should be designed to be reusable. If you’ve written something that was coupled, but needs to be made reusable… Well, thats what refactoring is for. Decoupling two classes that only communicate with each other can actually add complexity for that use case, so unless you strongly believe that at least one of the two classes will be useful in other situations, it is a waste of cognitive power to separate them.

My goal for production-quality software design? Create the simplest design that meets all my requirements, but is flexible enough to adapt to future requirements.

Let’s say that I have a value that represents an angle. I could use a double to represent the radians, or I could create a class called Angle, which internally might use a double to represent radians. If you are trying to avoid primitive obsession, you would use the latter. Now you have value objects of type Angle which can be used in meaningful ways. So, we’re done, right? I say no.

Angle is now its own form of primitive. Just as an Integer object is an abstraction of a numeric value in a specific set of reals, an Angle instance is an abstraction of a geometric/trigonometric angle. This means that it can be the building block for other more specific types. For instance, a 2 dimensional vector can be represented in “polar form” as an Angle and a Magnitude. In a physical simulation, a Magnitude is often a Distance, so we’ll assume that case for this article.

So, we can create a Vector interface (not to be confused with the java.util.Vector class). We can then create a PolarVectorImpl class which uses Angle and Distance. We can even create a CartesianVectorImpl which uses two Distance objects to represent the vector. Whats more, is these can both be used by anything that expects a Vector, with no extra work in the client code. We can easily create a rotate(Angle) method, or any other useful methods.

Another important and related concept that we haven’t touched on is mutability. If an object is mutable, that means that the apparent state of the object can change over the lifetime of the object. If an object is immutable, the apparent state of the object will appear the same throughout the lifetime of the object. This means that any invocation of one method on that object will always have the same outcome as any other on that same method. Also, any object that is returned from those methods must either be immutable themselves, or be distinct instances. Why is this important? Immutable objects have some benefits.

• Immutable objects are inherently thread safe.
• Immutable objects are easy to reason about.
• Immutable objects are easier to debug.
• Immutable objects can be passed around freely without defensive copying.

On the down side, immutability makes a pretty boring universe. If you’re object is expected to do different things depending on what has happened to it in the past, that object must be mutable. It must have state.

What does this have to do with primitive values? Its common to create immutable value objects. If we design the Angle class to be immutable, then we can safely say that one instance represents exactly one angle throughout its lifetime. All of our Angle objects are value objects. They are utility objects and reusable in many projects. On the other hand, if we’re doing a simulation of sorts, it might be useful to have a mutable angle, something that we can adjust over time. Lets call this class Heading. What’s in a Heading? An Angle, of course. Now here’s where things get interesting…

Since an Angle is a measurable thing, its easy to compare two values for equality. For Angles specifically, they are equal if their values represent the same geometric angle. Once equality is established, those objects are equal for ever. Not so with Heading. A Heading may represent the same angle at one moment in time, but at another moment they represent very different angles. For this type of object, equality only makes sense for the identity. A Heading instance is its own object, and can be queried/manipulated by many other objects/methods within the project.

The benefit of this design, is a manipulator/querier need not know who “owns” the Heading instance. A Robot might have a Heading, and a SteeringServo might manipulate that Heading. You can create the Robot and the SteeringServo objects independently of each other. The SteeringServo doesn’t even need to know its the Heading of a Robot. Once the Robot and SteeringServo both have the same Heading instance, they become connected without being coupled. This is huge goal for Object Oriented designers/programmers. The correct functioning of a SteeringServo isn’t dependent on the correct functioning of a Robot, or even of a Heading, only on itself. Similarly, a Robot’s correct functioning isn’t dependent on the correct functioning of the SteeringServo. The program as a whole may not work if there is a bug, but it easier to look at one class and ask yourself “Is there anything wrong with this code,” than it is to ask the same question about the whole project.

If you think all of this abstraction is unnecessary or unhelpful, think about all the layers beneath our Heading class. Lets have some fun and break it down into its most primitive parts.

• Heading instance is an identity value containing an Angle and representing a direction at a point in time.
• An Angle is an equal-comparable value containing a double and representing a direction.
• A double is a equal-comparable and order-comparable value containing an ordered set of bits and representing a real number.
• A bit is an equal-comparable value containing a memory cell representing true or false.
• A memory cell is often times a capacitor that is either charged or uncharged

If you had to think about the implementation details of a bit every time you used a double, it would make the mental weight of programming so immense that no useful programs could be written. Heading can now be used very easily without adding the mental weight of how its implemented. SteeringServo can be implemented without the mental weight of what it is steering. Overall, the practice of this kind of decoupling will make your program easier for the most important source-code interpreter. You.

public class Bob {
  double distance;
  double duration;
  double weight;
  /* ... rest of code which handles calculation based on distance,
          duration, and volume, based on some predefined units for each. */
}

While there isn’t anything broken about this code, it needlessly couples the algorithms used in Bob with the units used to express distance, duration, and weight. A more robust design would give each of these there own types, which could be unit-independent. We’ll deal with just Distance. I’ve decided to implement the Distance class use meters as its underlying representation, but this fact is hidden from all clients of the class. Furthermore, I’ve tried hide that fact from as many internal methods as possible.

public final class Distance {
    private final double meters;

    private  Distance(double meters) {
        this.meters = meters;
    }

    public double getMeters() {
        return meters;
    }

    public static Distance fromMeters(double meters) {
        return new Distance(meters);
    }

    public Distance times(double scalar) {
        return fromMeters(getMeters()*scalar);
    }

    public Area times(Distance distance) {
        return Area.fromSquareMeters(getMeters() * distance.getMeters());
    }

    public Distance plus(Distance distance) {
        return fromMeters(getMeters() + distance.getMeters());
    }
}

So, what do we have here? Distance now has methods that give you more meaningful operations. A Distance multiplied by another Distance is specifically an Area, but a Distances multiplied by a scalar (simple number), is just a scaled Distance. You can’t add an arbitrary scalar to Distance on accident.

If we were using simple double distance and used the convention that distances was measured in meters, we might see code like distance+=3; // add three meters Unfortunately, if we switch to a different metric, we just broke that line. Using the non-primitive Distance, the same line would be distance = Distance.plus(Distance.fromMeters(3)); Now, no one is constrained to use meters. We could easily add fromInches, getInches, fromYards, getMicrons, etc… We could also decide change the internal representation of Distance to use BobUnits (3.14 Bob Units is one Meter ), and no client code need be touched!

Another useful example are measurements which usually have other associated values with them. For example, Angles. Angles can be measured in Degrees, Radians, and many other units. They also have associated sine, cosine, tangent. So, lets take a look at an Angle class:

public final class Angle {
    private final double radians;

    private Angle(double radians) {
        this.radians = radians;
    }

    public double cosine() {
        return Math.cos(getRadians());
    }

    public double sine() {
        return Math.sin(getRadians());
    }

    public static Angle fromCartesian(Distance x, Distance y) {
        return fromRadians(Math.atan2(y.getMeters(), x.getMeters()));
    }

    public static Angle fromRadians(double radians) {
        return new Angle(radians);
    }

    public Angle plus(Angle angle) {
        return fromRadians(getRadians() + angle.getRadians());
    }

    public double getRadians() {
        return radians;
    }
}

Again, we arbitrarily choose radians as the implementations unit, and again we don’t expose this to the client, and we don’t rely on it internally unless we have to. We have an Angle plus an Angle is an Angle. We also have a way to get an angle from a Cartesian coordinate.
What’s more, we have sine() and cosine(). That’s the big deal with Angle! Now our clients don’t need to use ugliness such as “Math.cos(angle * degreeToRadians)”. If they have an Angle, they can get the sin, cos, degrees, radians, etc… Without having to know the details of the underlying units.

Now, any of these can be turned into interfaces or abstract classes, and then you could have different implementations based on the system needs. For instance, if you’re dealing with subatomic measurements, meters doesn’t make sense for distances, and seconds doesn’t make sense for durations. You could have a MicronDistanceImpl implementation of Distance, and NanosecondDurationImpl implementation of Duration. Similarly for a cosmic simulation, you could have light-years for Distance and millennia for Duration.

Oh, almost forgot. This also gives you the ability to have nice toString() representations. I haven’t added those to the above classes, but I could imagine the toString printing “12.0 meters” and “32.6 degrees”. This will help when presenting these values to a user as well.

This kind of abstraction is what makes good design. Next time you declare something as a primitive (or a dumb primitive wrapper such as Double, or Integer), think about what type units you might assign to it. You’ll find that your classes become simpler as well, since they don’t get bogged down in the formulas needed to convert between units. It also gives you much more expressive power. Think of a Speed class which has Distance and Duration fields. Maybe even a method on Distance public Speed divide(Duration duration);

First, for those who don’t know, a Flyweight is a stateless object that represents some behavior for a set of other objects. For example, if you had to have an ‘e’ Glyph”object for every letter ‘e’ in this article, you’d have a lot of instances of the e glyph object. Using a flyweight, you have one instance of the ‘e’ Glyph, and whenever you need to evoke the behavior, you pass in the “state” (eg. the position on the screen) to the appropriate method.

For small sets of Flyweights, where the difference between any two instances is mostly behaviorally, enums are very useful. They wouldn’t be so useful for the ‘e’ Glyph example, since we’d have to write an enum with every character we wished to support. Glyphs also mostly differs in the shape, which can be broken down into data rather than behavior.

So, for our example, we’ll be using a Flyweight to mimic animals. Lets start out with our different types of animals.

public enum AnimalType {
    Cow,
    Chicken,
    Pig,
    Lion
}

Now, if we wanted to have an Animal class. Lets assume that we have an “World” class that contains information about our animal’s world. Including food sources and animal position, etc…

public final class Animal {
   private final AnimalType type;
   private final World world = World.getWorld();
   private int hungerLevel;
   public Animal(AnimalType type) {
      this.type = type;
   }
}

Now, objects aren’t generally useful unless they have behavior. We’re going to add simple delegation from the Animal class to its AnimalType instance.

public final class Animal {
   private final AnimalType type;
   private final World world = World.getWorld();
   private int hungerLevel;
   private int restLevel;
   public Animal(AnimalType type) {
      this.type = type;
   }

   public void eatFood() { type.eatFood(this);}

   public void sleep() {
     type.sleep(this);
   }

   public World world() { return world; }
}

public enum AnimalType {
    Cow {
        public void eatFood(Animal animal) {
            animal.world().findGrass().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findBarn().sleptInBy(animal);
        }
    },
    Chicken{
        public void eatFood(Animal animal) {
            animal.world().findCorn().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findCoop().sleptInBy(animal);
        }
    },
    Pig{
        public void eatFood(Animal animal) {
            animal.world().findTrough().getContents().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findBarn().sleptInBy(animal);
        }
    },
    Lion {
        public void eatFood(Animal animal) {
            animal.world().findPrey().consumeBy(animal);
        }
        public void sleep(Animal animal) {
            animal.world().findSavana().sleptInBy(animal);
        }
    },
;
    public abstract void eatFood(Animal animal);
    public abstract void sleep(Animal animal);
}

So, as you can see, each animal has its own behavior. This particular flyweight implements the Strategy pattern for both eatFood() and sleep().

One of the more important points that this article makes is:

There is absolutely nothing wrong with having a multi-layered application. In many cases, anything but that would be a bad design. It’s absolutely critical, however, to not think of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.

I think that all of us can get stuck on the trying to move some logic into a place where it doesn’t really belong. If moving the logic into another location causes your system to be more complicated, then its probably the wrong place to move it.