iOS Recipes - Matt Drance [2]
2.2 Categories
A fair number of recipes make use of categories on standard Apple classes to accomplish tasks. Categories are an incredibly powerful feature of the Objective-C programming language, and they tend to alienate new Cocoa programmers. Categories can also quickly pollute namespaces and create (or mask) unexpected behavior in complex class hierarchies. They aren’t to be feared, but they are to be respected. When considering a category, do the following:
Ask yourself whether a subclass or a new class would be more appropriate. As The Objective-C Programming Language from Apple states, “A category is not a substitute for a subclass.”
Always prefix category methods when extending a class you don’t control (for example, UIApplication) to avoid symbol collisions with future APIs. All new category methods in this book use a prp_ prefix.
Never override defined methods such as ‑drawRect: in a category. You’ll break the inheritance tree by masking the source class implementation.
2.3 Synthesized Instance Variables
You’ll find few, if any, instance variable (ivar) declarations in the header files and examples that accompany this book. We’ve chosen to exclusively use Objective-C 2.0 properties, with the modern runtime’s ivar synthesis feature, for declaring class storage. The result is less typing and less reading so we can concentrate on the recipe itself. We explain this further in Recipe 35, Leverage Modern Objective-C Class Design .
2.4 Private Class Extensions
Private class extensions are another relatively new feature of Objective-C, and we use them frequently in this book. Private extensions can increase readability by minimizing header noise, and they also paint a much clearer picture for adopters or maintainers of your code. In Recipe 35, Leverage Modern Objective-C Class Design we introduce both private class extensions and synthesized instance variables for anyone unfamiliar with either technique.
2.5 Cleanup in ‑dealloc
In addition to releasing all relevant instance variables in the ‑dealloc, our examples set them to nil. This practice is one of the most hotly debated topics among Cocoa programmers, and both sides of the argument hold weight. This book is not meant to participate in the debate at all: we set them to nil, but that doesn’t mean you have to do so. If you don’t like nil-in-‑dealloc, feel free to leave it out of your own code.
2.6 Blocks vs. Delegation
Blocks are a new feature added to C and Objective-C in Mac OS X Snow Leopard and iOS 4.0. Because of the relative youth of this feature, the debate on when to use blocks or delegates remains heated. In the book we use both at what we felt were appropriate times. You’re more than welcome to add blocks to a recipe that uses delegates, or vice versa. Our goal is ultimately to help you find the simplest and most natural solutions you can.
Above all, this book is about reducing complexity and repetition in your code. Rather than go for the quick fix to a problem, we opted for solutions that will be readily available for the long haul. We hope that the ideas in these pages assist you in your journey as an iOS developer.
2.7 Online Resources
This book has its own web page, http://pragprog.com/titles/cdirec, where you can find more information about the book and interact in the following ways:
Access the full source code for all the sample programs used in this book
Participate in a discussion forum with other readers, iOS developers, and the authors
Help improve the book by reporting errata, including content suggestions and typos
Note: If you’re reading the