The Robert C. Martin Clean Code Collection (Collection) (Robert C. Martin Series)

by Robert C. Martin

If our application needs a Map of Sensors, you might find the sensors set up like this: Map sensors = new HashMap(); Then, when some other part of the code needs to access the sensor, you see this code: Sensor s = (Sensor)sensors.get(sensorId ); We don’t just see it once, but over and over again throughout the code. The client of this code carries the responsibility of getting an Object from the Map and casting it to the right type. This works, but it’s not clean code. Also, this code does not tell its story as well as it could. The readability of this code can be greatly improved by using generics, as shown below: Map<Sensor> sensors = new HashMap<Sensor>(); … Sensor s = sensors.get(sensorId ); However, this doesn’t solve the problem that Map<Sensor> provides more capability than we need or want. Passing an instance of Map<Sensor> liberally around the system means that there will be a lot of places to fix if the interface to Map ever changes. You might think such a change to be unlikely, but remember that it changed when generics support was added in Java 5. Indeed, we’ve seen systems that are inhibited from using generics because of the sheer magnitude of changes needed to make up for the liberal use of Maps. A cleaner way to use Map might look like the following. No user of Sensors would care one bit if generics were used or not. That choice has become (and always should be) an implementation detail. public class Sensors { private Map sens...