cool - gear girl

[Peter Korsten]

Andrew Robinson schreef:

> I would love an Objective C primer that assumes you know Basic, rather
> than all these ones that assume you either know nothing, or some other
> brand of recent language.

To be honest, a book that presumes you know nothing would be the better 
choice, because object-oriented programming requires a rather different 
approach than what you're used to.

> Objective C is making sense to me, because I can understand the
> underlying assembler opcodes, but the syntax is annoyingly unfamiliar,
> and the tutorials I have tried seem to place huge emphasis on a)
> functions, b) pointers and c) structs, which don't have equivalents in
> Basic, and therefore I'd be happy not knowing about until I was
> writing something a) large b) highly optimised or c) involving a
> database respectively.

Wow, you have quite a history there, but not anything used in the 
last... 15 to 20 years?

Just a very quick run-down: object-oriented programming requires you to 
think in terms of collections of data, and operations you can perform on 
that data. Suppose you have someone's personal details, including first 
name, last name, identity card number, and address. But the address is 
implemented in a different way: rather than allowing for a single 
address, you allow for a home, a business and a billing address. Now you 
could decide to have variables like home_street, home_number, home_town, 
home_postcode and the same for business_* and billing_*. But an address 
is an address, so you make a new class 'Address' with those four fields, 
and put three instances of the Address class in the PersonalDetails class.

Now, if this is an application where you have an account, you could make 
an 'Account' class with the fields 'balance' and 'currency'. This class 
would also have operations, like 'addAmount( float amount )' that adds 
the amount to the balance (or deducts it, if its a negative amount).

Instances of the PersonalDetails and the Account classes could be put in 
a Customer class. Or even better, put an array of Accounts in the 
Customer class.

So you see, you have the same elements: simple variables, arrays, and 
subroutines that are now called 'functions' or 'methods', depending on 
whether you're in an procedural or object-oriented language.

The difference with what you're used to is also structured programming. 
This means, no jumps (goto, gosub, jmp, jnz, etc.), and stuffing 
everything in 'if', 'for' and 'while' constructs.

Pointers, ah, well, they're a difficult subject to get your head around. 
You might decide to ignore them completely and go full-out 
object-oriented, but there's no real getting around them in C and C++. 
(I don't know Objective C, but I doubt it's much different.)

Another important aspect is exception processing. This is quite 
primitive in C++, as far as I'm concerned, and a lot more useful in 
Java. (Again, I don't know how it works in Objective C.) What these do 
is handling error conditions in a central location. Rather than checking 
the result of each and every function call, an exception is thrown if 
something goes wrong and this cascades all the way down, if no exception 
handler for that exception exists in the current scope. You can make 
your programs a lot more error-prone by religiously using exceptions.

Then there's the bit about public and private variables and functions. 
This will also be an unfamiliar subject, but see public variables as 
global variables. If you make all variables global, meaning accessible 
from the entire program, you introduce yet more possibilities for bugs. 
So you should make public those variables and functions that need to be 
public, and make the rest private: meaning, that they can only be 
accessed from the class in which they are declared.

So... it's actually a bit longer than I had thought this mail would be, 
but maybe it'll help you dealing with object-oriented programming. I'd 
say that recognising the underlying concepts in assembler will help, but 
don't try to write a program as you would have in Basic or assembler, 
because whilst you might get away with it, you'd be making your life a 
lot more difficult.

- Peter