Defensive Programming – Is It Necessary for Private Code?

api-designdata structuresjavaprogramming practices

I'm writing a Java implementation of a card game, so I created a special type of Collection I'm calling a Zone. All modification methods of Java's Collection are unsupported, but there's a method in the Zone API, move(Zone, Card), which moves a Card from the given Zone to itself (accomplished by package-private techniques). This way, I can ensure that no cards are taken out of a zone and simply vanish; they can only be moved to another zone.

My question is, how necessary is this kind of defensive coding? It's "correct," and it feels like the right practice, but it's not like the Zone API is ever going to be part of some public library. It's just for me, so it's kind of like I'm protecting my code from myself when I could probably be more efficient by just using standard Collections.

How far should I take this Zone idea? Can anyone give me some advice on how much I should think about preserving the contracts in classes I write, especially for ones that aren't really going to be publicly available?

Best Answer

I'm not going to address the design problem - just the question of whether to do things "correctly" in a non-public API.

it's just for me, so it's kind of like I'm protecting my own code from myself

That's exactly the point. Maybe there's coders out there who remember the nuances of every class and method they ever wrote and never mistakenly call into them with the wrong contract. I'm not one of them. I often forget how code I wrote is supposed to work within hours of writing it. After you think you've gotten it right once, your mind will tend to switch gears to the problem you're working on now.

You have tools to combat that. These tools include (in no particular order) conventions, unit tests and other automated tests, precondition checking, and documentation. I myself have found unit tests to be invaluable because they both force you to think about how your contract will be used and provide documentation later on how the interface was designed.

Related Solutions

Java Design – Designing an Iterable but Immutable Collection

It appears you have two requirements here:

Event exposes collections, but callers cannot modify those collections.
Event can modify its collections, but only through the Event class.

It sounds like you need to use immutable collections, for example, java.util.Collections.unmodifiableList(List list). However, you do not want to store an immutable collection as the state in Event. It could work like this:

public class Event {

  private List<Player> players;

  public List<Player> getPlayers() {
    return Collections.unmodifiableList(players);
  }

  public void addPlayer(Player p) {
    players.add(p);
  }
}

This allows modifying the collections through Event, while still allowing callers to get an immutable reference suitable for iteration. The call to Collections.unmodifiableList(players) wraps the list players and does not copy it.

If this needs to be thread-safe then there are additional concerns to address here, but that was not a requirement. It sounds more like your Event class needs to handle invariants and data integrity between multiple collections that model the same objects. That concern should easily be addressable using this technique.

REST API Client – When to Use Abstract Classes vs Interfaces

The over-engineering architects will disagree with me, but in a language such as C#, interfaces only exist to allow multiple inheritance, and they do that poorly, having no implementation. That is, if you can find some common implementation code, it is better to use a base class instead of an interface, except when you need some form of multiple inheritance. Since C# only allows multiple inheritance in the form of interfaces, you are stuck with an interface.

In the case of your specific example, you have not explained why the design warrants interfaces or classes. What you call a "request" seems to be a combination of of an action (verbs) and parameters (nouns). This can be expressed in many ways, but the most logical for me would be a composite object containing the action and parameters. The action does not have to be specified using a class or an interface.

Best Answer

Related Solutions

Java Design – Designing an Iterable but Immutable Collection

REST API Client – When to Use Abstract Classes vs Interfaces

Related Topic