Strings in Cocoa: Part I06/29/2001
In the next two columns we will delve into the fundamentals of the classes
NSMutableString; these two classes make up the majority of Cocoa's string-handling ability.
We'll start today by dealing with the various ways to create strings, and the basic manipulation methods that allow us to extract substrings, and search and compare strings too. However, before I get into that, I want to start with a mini-lesson about another concept of object-oriented programming: class clusters.
Another lesson in OOP
NSMutableString classes are prime examples of the use of class clusters in Cocoa. A class cluster is a way of grouping closely related classes into a small number of abstract classes. In this scheme, the complicated mess of interfaces for the various classes are kept private, while the abstract classes' interface is kept public. Here,
NSMutableString are the abstract classes with which you program. Cocoa handles the rest beneath the surface.
When you create an instance of
NSString, you don't actually have an object that is exactly an
NSString. Rather, you have an object that is an instance of a highly specialized type of string. You may have many of these specialized strings whose implementations vary based on specific features and behaviors.
For example, you might have a special string class that implements only C-type strings, and another string class that implements strings with UTF-8 encoding. The reason you create separate, specialized, string class implementations is in the interest of efficiency. It is much more resource-savvy to have low-overhead classes with very specific functionality than one aggregate class that can do everything.
Now you can imagine that the number of classes could quickly grow if you continue along this course, leaving you with a complicated set of classes to worry about and organize. So, what a class cluster accomplishes is to hide all those specialized classes from you, the developer, and simply provide a general, abstract class, thereby simplifying the interface without sacrificing functionality or leanness of implementation. You get the best of both worlds with class clusters.
In this case,
NSString and its subclass
NSMutableString are the abstract public classes of their particular class cluster. This is possible because presumably all strings would have the same behaviors, which are methods. So when you create a new string instance, there is some work going on behind the curtain to choose the class that would best suit your needs.
Let's discuss strings, how they work in Cocoa, and some of the concepts that Mike Beam introduces in this column.
Also in Programming With Cocoa:
Other examples of class clusters in the Foundation Framework are the classes
NSNumber. When we get to
NSArray, I will talk more about class clusters, in particular some subtleties that come into play when you subclass these abstract classes that are the faces of class clusters.
Now let's move on to
NSString, and see what we can make of it.
The fundamentals of strings
NSString provides you with a plethora of methods for creating and initializing new strings. One of these methods that you will likely employ quite frequently is the creation of static, or constant, strings. These are
NSString instances that are compiled into the executable, which means it is always with us, and can never be removed from memory. Objective-C provides us with a great syntax for creating these constant strings, which goes as follows:
NSString *aString = @"Hello, again.";
Strings of the
@"..." construct are truly
NSString objects. Thus, any time we have a method that takes an
NSString argument, we can use
@"..." strings as we would any object variable.
I have included with this column a small application that is simply a button and a text field, which serves as a string tester for your use. The way I use it is to put any of these string operations we talk about in this column and the next into the button's action method. I set up an example in the code, feel free to muck around with it all you want.