For many developers like myself, I learned a language as a means to create a program on a specific platform. Back in the early 90’s, I learned Pascal because that was the language that PC and Macintosh’s used. Later in the 90’s, I learned C++ because this was the buzzword language that BeOS, the powerful multimedia rich operating system, used. I learned other languages throughout my career, like Java and C#, but none has stood out more than Objective-C.Objective-C was used by NeXT and later by Apple when NeXT was acquired by them in 1996. Apple needed a next generation operating system badly and they needed one that was easier to develop for than Mac OS 7. Truthfully, programming on the Mac early in my career was a painful experience, littered with bugs, crashes and painful debugging sessions. Pascal as a programming language was not fun for me. C++ in MetroWerks looked really cool, but a program made with the PowerPlant library still had problems because of the nature of Mac OS 7.
When Windows 95 came out, Microsoft introduced an easier way to create programs for a platform. I got sucked into MFC, which was built in C++, and I created programs as soon as I learned how to subclass CWindow.
So how does this bring me here, to Objective-C and Mac OS X? Well, when Steve Jobs came back to Apple in 1996, he brought into the company one of the greatest accomplishments he and his team at NeXT created: an Objective-C based framework named OpenStep. Although Microsoft had MFC, which seemed so much better than programming with the Win32 API, OpenStep, later renamed Cocoa, was a radical departure from conventional object oriented programming.
MFC, which stands for Microsoft Foundation Classes, was built in C++ and allowed developers to create programs using reusable modular code and event messaging. A dialog class would respond to messages sent to it via a series of macros created by the compiler. Those who are familiar with programming with MFC and Visual Studio know about the event map macros. Objective-C and Cocoa were different in that you didn’t have to create a subclass in order to gain functionality in a particular module, or that you didn’t have to worry about sending a message to an object method that doesn’t exist. You see, for those who didn’t catch that last statement, that is probably one of the biggest distinctions between Objective-C and C++. In Objective-C, you are actually sending a message to an object. Even if the method doesn’t exist in the object, that’s ok in Objective-C. In MFC, built around C++, you are actually calling a function. In order to call that function, you must first declare it somewhere in your code. Messages aren’t really sent to objects in C++, but many frameworks create message-like mechanisms by storing an array of functions that would respond to a particular message posted to an event class. This is what MFC does when Visual Studio embeds your code with macros that insert extra event functionality.
So, I am assuming that if you have read the article to this point that you are most likely a C or C++ developer who is looking into Objective-C and trying to understand it more. If you were like me, you probably bought the Objective-C book published by Apple or downloaded the PDF(http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf) available from the Apple Developer Connection and either forced yourself to learn the language and accept it or gave up on trying to understand it altogether. If that is the case, I don’t blame you for feeling a little lost. Honestly, I felt that same way too. I learned the language and I compared it to every other language that I have learned, wondering why Apple choose such a strange language. When Cocoa became available in Java, I headed down that path since it is more like C++ and much more familiar to me than Objective-C. However, I quickly learned that programming with Java and Cocoa was not optimal for me or for my projects.
The first problem was that I really didn’t understand Objective-C. The second problem was that I constantly compared it to C++, thinking it was weird. The solution to both of these problems was understanding how Objective-C worked and not comparing it to C++. The first and most important attribute to learn about Objective-C is that programs built in this language can have dynamically loaded code. You might think, “big deal! I can do that with a DLL!”, but what you don’t realize is the mechanism that sits behind DLL usage: in order to use a DLL, you have to reference the DLL in your project and link you application to it via the compiler. When you compile your application, the compiler links the code into the binary executable, effectively copying the code into the application. Even if you are using a dynamically linking the library, there is only a reference to the DLL on the file system, however, if the DLL is different or missing, your application will not launch. In Objective-C, you don’t have to link to a library at compile time: you can wait until your program is running to load the library and call the functionality that is inside of it. If the library is different or missing, your program will still launch and execute.
This is hard for a lot of developers to understand, but this is similar to the COM interface in Windows. You can call invoke code within another file using an Interface class to understand the contents of that code. Objective-C is built around the Interface concept, which is evident when you declare a class in Objective-C: class declaration has 2 parts: the interface portion (in the header file) and the actual code declaration part(in the implementation file). In C++, you would declare a class as follows:
class MyClass
{
private:
int _someVariable;
protected:
int _someOtherVariable;
public:
MyClass(); // constructor
~MyClass(); // destructor
int CheckCPU();
int CheckHardDisk();
};
The CheckCPU function would be coded in a separate .cpp file as follows:
int MyClass::CheckCPU()
{
// do some work
return 0; // return an int
}
Objective-C is a little different: 2 keywords are used in the declaration of a class and the implementation of the methods: @interface and @implementation. To declare the above listed class in Objective-C, you would type the following:
@interface MyClass : NSObject {
// declare my class variables
@private:
int _someVariable;
@protected:
int _someOtherVariable;
}
// declare my class methods
-(int)CheckCPU;
-(int)CheckHardDisk;
@end
To implement the CheckCPU function, you would type the following:
#import “MyClass.h”
@implementation MyClass
-(int)CheckCPU
{
// do some work
return 0; // return an int
}
@end
Notice the usage of @interface in the .h file and @implementation in the .m file. Each one of the keywords is terminated by the @end keyword. It’s different, but very powerful!
At first glance, what might also seem odd is how methods are built. When you look at them, they look like typecasted C variables:
-(int)CheckCPU;
The minus(-) sign in front of the method indicates that the method is an instance method. Obj-C uses a plus sign (+) to indicate that a method is a class method. An instance method is one where you have to create a new instance of a class in order to use the method. A class method is like a static function in C++ where you don’t have to create an instance of a class in order to use the method.
Objective-C is a simple language that can be learned in a day. However, if you are a seasoned C++ developer, you might find it hard to absorb Objective-C and accept it. I have worked with Objective-C and Cocoa for quite some time now and there is a lot of good reasons to use this combo in your next Mac OS X project.
Now, I’m not saying that Objective-C is the end-all language, but it is certainly very impressive. Although there are a lot of features that C++ has that Objective-C doesn’t have, Apple certainly has made up for some of those lacking features in the frameworks they have built. For those of you like me, where you have written a ton of code in C++, there is good news. Most of that code can be reused in your Mac OS X project since applications built in Cocoa/Objective-C can call C++ code as well. Although Objective-C classes cannot inherit from a C++ class, it is good to know that you do not have to scrap your code for this awesome programming language.
Take a look at the resources listed below and the articles listed on http://developer.apple.com. There are sample projects listed on the website showing you how to use C/C++ with a Cocoa project and likewise, articles to further educate you on Objective-C and other topics related to the language. Once you start effectively working with the language, you will understand why it has become such a popular language in the developer community. Happy coding!
Additional Resources:
http://en.wikipedia.org/wiki/Objective-C
http://www.cplusplus.com/doc/tutorial/
http://www.cs.bell-labs.com/who/dmr/chist.html
http://www.otierney.net/objective-c.html
http://lambda-the-ultimate.org/node/1963
http://www.mactech.com/articles/mactech/Vol.13/13.03/CandObjectiveCCompared/