Java Map interface impl for composition

One of the mantras of object-oriented programming is that you should always favor composition over inheritance. However, it's always annoying when you want to implement Map but don't want to copy-paste-edit a bunch of methods that are just pass-through to the underlying map. This is code to do that, so I won't be tempted to just extend HashMap anymore.

  private final Map<String,String> m_map = new HashMap<String,String>();
 
  // begin Map impl
  public void clear(){ m_map.clear(); }
  public boolean containsKey(Object key){ return m_map.containsKey(key); }
  public boolean containsValue(Object value){ return m_map.containsValue(value); }
  public Set<Map.Entry<String,String>> entrySet(){ return m_map.entrySet(); }
  public boolean equals(Object o){ return m_map.equals(o); }
  public String get(Object key){ return m_map.get(key);}
  public int hashCode(){ return m_map.hashCode(); }
  public boolean isEmpty(){ return m_map.isEmpty(); }
  public Set<String> keySet(){ return m_map.keySet(); }
  public String put(String key, String value){ return m_map.put(key,value);}
  public void putAll(Map<? extends String,? extends String> m){ m_map.putAll(m) ;}
  public String remove(Object key){ return m_map.remove(key);}
  public int size(){ return m_map.size(); }
  public Collection<String> values(){ return m_map.values(); }
  // end Map impl

Books, January 2009

Thinking in Java by Bruce Eckel — I've literally been reading this book for 9 years. This was the book I learned Java from many years ago when I was a student, through the graciousness of Eckel making it available for free electronically. I accidentally bought two copies, so I now have one at work and one at home. I finally got around to reading the chapters on annotations, enums, inner classes, and generics.


Getting Things Done: The Art of Stress-Free Productivity by David Allen
— Mr. Allen, where have you been all my life? As he freely admits, a lot of the stuff in the book is common sense, but its the implementation that people get hung up on. I've started writing down everything I need to do, which alone has made me more productive with lower stress. Highly recommended.

The Little Schemer by Daniel P. Friedman and Matthias Felleisen — This series is one of the weirdest. The Socratic style is off-putting to some, including me, at least initially. Some of the text borders on cheesy, but I'm growing my appreciation of whimsy. I still don't understand they Y combinator, so I'm going to need to revisit this in a few months.

Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers) (Jul 1, 2005) by Venkat Subramaniam and Andy Hunt — Another great book in the "Pragmatic" tradition. I was expecting a book with more on agile software development methods, but this is more individual things developers can do to increase their productivity. While I already do a lot of these, it's always good to be reminded of what you're naturally doing and why it works.

After The Gold Rush by Steve McConnell — Recommended for anyone interested how software development can become a true engineering discipline instead of the craft that it currently is in most of the industry.

Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister — From the authors who wrote "Peopleware. While the word "agile" isn't used in the book, a lot of the topics here strongly related to agile practices.

Bargaining for Advantage: Negotiation Strategies for Reasonable People 2nd Edition by G. Richard Shell — An excellent "soft skills" book. I've read "Getting to Yes" and "Getting Past No", and this book was an excellent complement to those two. Lots of concrete strategies for negotiation and guidance for what works in what situations.