Re: SEMI-OT: "Tricks" of the "Trade"
Re: SEMI-OT: "Tricks" of the "Trade"
- Subject: Re: SEMI-OT: "Tricks" of the "Trade"
- From: "David W. Halliday" <email@hidden>
- Date: Fri, 08 Jun 2001 12:36:31 -0500
- Organization: Latin AmeriCom, formerly Latino Online
Charles Bennett wrote:
>
NOTE: This message has various parts of various messages munched and
>
combined. Hopefully, not completely out of context..
>
>
David Halliday Wrote:
>
>
> I must admit, I did have a passing acquaintance with SmallTalk
>
> before learning Objective-C, but that was really nothing more than reading the
>
> SmallTalk 80 article in Byte magazine oh so many years ago.
>
>
<OFFTOPIC>
>
The issue with the smalltalk balloon floating away over a sea of other
>
languages? Never heard of it.. ;-)
Yep. That's the one. (Chuck, do you recall what year that was? [Feel free to mail me off list.])
>
>
...
>
>
</OFFTOPIC>
>
>
and Erik Thorteran wrote:
>
> I think my problem is that whenever I try to make a class, it fails
>
> miserably, so I make one mega-class that gets everything done.
>
>
Don't feel bad about the mega-class approach, it's called "procedural progrmming"
>
and folks have been doing it for years.
>
>
To switch to object oriented programming, the way you THINK about the problem you are trying to solve has to change.
>
When you finally "GET IT" it's almost tantamount to a religious
>
conversion. The light bulb comes on and you will discover that it's really hard to
>
think about problems the "old" way. If you really love programming and,
>
since you started at 12, I think you must really want to do it, keep reading,
>
playing around, and asking questions.
This "GET IT" experience is why it's referred to as a paradigm shift---a fundamental change in the way one perceives
the world (at least the programming world).
>
>
...
>
>
> Also, it does not make sense to me to subdivide this
>
> mega-class because it is so tightly-woven, and between class method
>
> calling is hard if they don't know about each other.
>
>
they get to "know about" each other via their header ".h" files. Objects that need
>
to communicate with each other usually include each others header files, so they know
>
what method the other object can perform. This also lets the compiler check your syntax
>
and catch typing errors early.
>
>
Feel free to ask specific questions. I can't speak for the list, but you can email
>
me offline if you want. My 9 year old daughter is following in your foot steps
>
so I'm used to answering these kind of questions.
Certainly, ask away. This was the intent of my P.S..
By the way, an example may help. Let's suppose we have two classes that are "highly coupled". Let's call these A
and B.
//file A.h
#import SuperA.h
@class B; //let's the compiler know that "B" is a class type
@interface A : SuperA
{
B * myB; //we have an instance variable that is to be an instance
//of B (one of the reasons we needed the "@class B"
//declaration)
...
}
-(id) myMethod:(B *)aB; //An instance method that takes an
//instance of B as an argument.
...
@end
//end file A.h
//file B.h
#import SuperB.h
@class A;
@interface B : SuperB
{
A * myA;
...
}
-(id) myMethod:(A *)anA;
...
@end
//end file B.h
//file A.m
#import A.h
#import B.h
@implementation A
- (id) myMethod:(B *)aB
{
...
}
...
@end
//end file A.m
//file B.m
#import B.h
#import A.h
...
//end file B.m
>
>
chuck
I hope this helps.
David email@hidden