Is Java’s String Class a God Object?

In October I wrote a blog entitled Top Trumps in God Objects where I talked about the discovery of an object I’d found with 167 disparate methods that linked this object with all other parts of the application and, as you’d expect, followed the general criteria for a God or Monster Object. It was recently pointed out to me that method count alone isn’t an indication that an object is a God Object, which is quite true. The comment also went on to site the String class as an object that isn’t a God Object, but has a large number of methods.

This got me thinking: is the String class a well designed class in terms of the general rules of Object Oriented Design? Does it, in fact, break the single responsibility principle or the laws of demeter and is it tightly coupled to all other parts of an application? Is it a God Object?

The easy way to answer this is to look at a String in terms of the Single Responsibility Principle, and the best way to do that is to count the number of method calls it has and figure out what they do.

If you do that you’ll find that Java’s String class has 66 method calls in it’s repertoire and you may conclude that a number this high could be the first sign of a God Object.

Next, if you look at these 66 method calls you can group them into several different areas of responsibility. For example there are:

Conversion Methods

  • getBytes(...)
  • getChars(...)
  • valueOf(...)
  • toUpperCase(...)
  • toLowerCase(...)
  • toCharArray(...)


Methods that split String

  • substring(...)
  • split(...)
  • subSequence(...)


Equivalency Methods

  • equals(...)
  • matches(...)
  • compareTo(...)


Search Methods

  • indexOf(..)
  • lastIndexOf(...)
  • charAt(...)
  • contains(...)


Combining Methods

  • append(...)
  • concat(..)
  • +
  • +=

…and more besides.

Using the lists above, you could now write a CRC card for a String that goes something like this: “A String is responsible for combining itself with other Strings to create new Strings AND converting itself into other objects or arrays of objects AND splitting itself into different pieces AND comparing itself to other String objects AND performing searches on itself”

Sticking to the letter of the law then the lists above show that String’s method calls break down into at least five areas of responsibility, which means that, by the book, the Single Responsibility Principle has been violated.

Taking this to its logical conclusion, then you could refactor a String to look something like this….

However, and this is the question, why isn’t Java’s String class composed of some data and a bunch of classes that operate on it? The answer is both a matter of opinion and multifaceted. Firstly, history… Java as grown over time as so has the String class; methods have been added piece-meal as the Java version number ticks ever upwards. Secondly, pragmatism. A String object in it’s current design may break the Single Responsibility Rule, but it doesn’t matter, it’s easier to leave it as it is and get on with writing the programs that count. Lastly, and I think that this is important, we all generally know what a String is. Its name and meaning is in common usage. If we had to define what a String’s responsible for using a CRC card, then we’d write something like: “a String is responsible for being s String”.

A String may have 66 methods, but I believe that by general consensus it’s not a God Object. However, software is just a matter of opinions, so I’ll leave you answer the other questions I posed at the beginning of this blog and to make your own mind up…

Reference: Is Java’s String Class a God Object? from our JCG partner Roger Hughes at the Captain Debug’s Blog .

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


5 × four =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books