3 Replies - 9837 Views - Last Post: 12 December 2007 - 07:53 PM Rate Topic: -----

#1 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2069
  • View blog
  • Posts: 4,307
  • Joined: 11-December 07

UnsupportedOperationException - bad design or practical compromise?

Post icon  Posted 12 December 2007 - 04:15 PM

A stupid example to illustrate what I'm talking about:

public interface A {
	 public void doSomething();
} // interface

public class B implements A {
	 public void doSomething() {
		  throw new UnsupportedOperationException();
	 } // doSomething
} // class B


I once read an article where the author gave the opinion that it's a bad design to include a method that does nothing. It seems sensible but I came across a problem the other day where the design would be overly complicated. It was at this point I began wondering why the Exception is in the API at all.

A quick Google showed Sun's opinion that the Collections Framework hierarchy requires the UnsupportedOperationException to prevent an explosion of interfaces; and even if they chose that route, the Collections Framework would still not be flexible enough to allow the implementation of all imaginable collections.
Source: http://java.sun.com/...esignfaq.html#1

So, the first point of debate is to what extent should throwing UnsupportedOperationException be avoided in this context? Are there any common reasons for it to be acceptable or any common design pitfalls to avoid.

The second point is in relation to my current project. Basically, I'm crating a set of classes to represent physical objects in a tabletop wargame. Things like Board, Soldier, Squad, Army, Terrain.... and also some more abstract concepts to do with the game mechanics like MovementArrow, DamageMarker, etc...

A simple hierarchy turned out to be impractical. I've gone for the decorator design pattern so I can choose the getters and setters on an individual basis for each class of entity. This works out quite well in all but a few cases:

It makes sense to be able to change a soldier's footprint from a square to a circle. However, a Squad's footprint is calculated from the footprints and locations of all the squad members. Therefore, it makes no sense to call setFootprint on a Squad. There are other similar examples throughout the various classes.

The second point of debate: is my current situation is a result of a poor design? Can you see a better design that would eliminate useless methods without causing a class explosion?

Thanks for reading. I look forward to hearing your opinions - especially on the general case. My code works just now, and if it's not broken I don't fix it.

Is This A Good Question/Topic? 0
  • +

Replies To: UnsupportedOperationException - bad design or practical compromise?

#2 Programmist  Icon User is offline

  • CTO
  • member icon

Reputation: 252
  • View blog
  • Posts: 1,833
  • Joined: 02-January 06

Re: UnsupportedOperationException - bad design or practical compromise?

Posted 12 December 2007 - 04:41 PM

I can't see your code, but if you have methods that do nothing, my instinct says that your design is flawed. If you want a good example of using the decorator pattern, look at the java.io package. I would also recommend not just confining yourself to the decorator pattern. Who says you can't combine patterns? Also remember the basic OO design principles. If two classes are very similar, yet have some differences that would require methods that don't quite fit (empty methods?), then you need to go back to look at what differs and encapsulate it. You might consider encapsulating these differences within another class/interface hierarchy (Strategy pattern anyone?). Just my observations. Sounds like you're not going to change what you have, but maybe this will give help you on the next go round.

As far as the UnsupportedOperationException, I really don't have much to say about it. Seems that Sun made a practical decision. If you are unsatisfied with the Java Collections API, there are many others that do things differently. Google has one and so does Apache. And they have some interesting collection types.
Was This Post Helpful? 0
  • +
  • -

#3 Martyr2  Icon User is online

  • Programming Theoretician
  • member icon

Reputation: 4423
  • View blog
  • Posts: 12,293
  • Joined: 18-April 07

Re: UnsupportedOperationException - bad design or practical compromise?

Posted 12 December 2007 - 04:50 PM

I have to agree with programmist here. If you run into a bit of these unsupported functions it means you are not properly matching up your interfaces with the objects. Either because the interface design is flawed or because your class is simply not matching it as closely as it should.

The way I design interfaces is by first designing the classes and as programmist eluded to, extrapolate your interfaces by encapsulating similar functionality, leaving what is unique in the object. I find this gives better interface design and almost always leads to interfaces that match objects 100%. I have yet to design an interface that needed to implement a function for interface purposes, but then throw an UnSupportedOperationException.

I am sure there is a reason...like if you do develop an interface and later go back to add more classes to it only to find you don't need all (but you need a large percentage of) the interface functions defined.

But if you are running into a bunch of these unsupported feature exception cases, you should immediately stop and again look at how your interfaces are design. You may need even to break down an interface into something a bit smaller.

Just my thoughts but I am largely in agreement with Programmist. :)
Was This Post Helpful? 0
  • +
  • -

#4 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2069
  • View blog
  • Posts: 4,307
  • Joined: 11-December 07

Re: UnsupportedOperationException - bad design or practical compromise?

Posted 12 December 2007 - 07:53 PM

Thanks for the fast replies. It's always nice to get instant gratification. :)

On reflection I think you guys may be right. Taking my above example, I'll never be able to iterate through a collection of GameObjects (my interface) and call setFootprint on each one, not unless I want to start handling a bunch of exceptions -- and I don't.

Looking at the classes themselves, all of the getters are used (whether the return values are calculated or stored). It's the setters that are use inconsistently.

Martyr2, I found your method of interface design interesting. I designed the interface first which is probably why I'm running into this problem. I think I'll work on other parts of the application for a while to get a better idea of exactly how all these classes will be used. That will help me choose between designing several interfaces or simply removing the methods that aren't used in every implementing class.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1