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 .

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


8 × = thirty two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
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.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close