Object-Oriented Programming in Objective-C - Let's see if I'm getting this right

[fractionMan]

Once you've got the basics, go off and look at design patterns. They'll serve you well.

 

[EastEnder]

The key to getting OO right is encapsulation and data hiding. An object should only ideally do one thing and users of that object should need no special knowledge of how the data is organized or processed within it.

All too often people make objects that do loads of things or expose their internal data structures. That way madness lies, but also a lot of OO code I've seen. Hence why rewriting stuff is so prevalent within the industry - it's often easier to rewrite stuff than pull apart badly written OO.

yeah, yeah, that's what all the boring text books say - ignore the hype Crispy! What you wanna do is have one HUGE object that does absolutely everything, make all the data public to save faffing around with endless accessor methods, and make all the method names anagrams of naughty words.

And always remember - only girls write comments.

 

[fractionMan]

No, what you shoud do is comment every single line!

things like

/** Add one to I, print it out and return the new value
*/
public int addOneToI(){
//add one to i
i++;
//print it out
System.out.println(i);
//return i
return i;
}

 

[Crispy]

It's going well. I am making a class for dealing with fractions and so far it can set and retreive denominators and numerators (in one method too! "setTo:Over:"), add two fractions together, and can reduce a fraction to its lowest common denominator. When I first typed

-(void)   add: (Fraction *) f
{
numerator = (numerator*denominator) + (denominator*[f getDenom]);
denominator = (denominator*[f getNum]);
}

and realised that I was going to use an instance of the class I was editing to operate on itself, I had a little shiver of 'oooh I see how powerful this is'

 

[fogbat]

It's going well. I am making a class for dealing with fractions and so far it can set and retreive denominators and numerators (in one method too! "setTo:Over:"), add two fractions together, and can reduce a fraction to its lowest common denominator. When I first typed

-(void)   add: (Fraction *) f
{
numerator = (numerator*denominator) + (denominator*[f getDenom]);
denominator = (denominator*[f getNum]);
}

and realised that I was going to use an instance of the class I was editing to operate on itself, I had a little shiver of 'oooh I see how powerful this is'

Recursion may actually make you spill your load

 

[Bob_the_lost]

No, what you shoud do is comment every single line!

things like

/** Add one to I, print it out and return the new value
*/
public int addOneToI(){
//add one to i
i++;
//print it out
System.out.println(i);
//return i
return i;
}

*Murders fm brutally*

I blame lazy lecturers

 

[MikeMcc]

Recursion may actually make you spill your load

Until you forget the escape clause and you bang your head against the screen when your memory disappears!

 

[untethered]

Well, I was struggling to find an example. But basically, the 'master' doesn't need to know how the 'slave' operates his tools, and shouldn't interfere with the parameters of those tools. Objects should aspire to be closed boxes

Not completely closed, because then you can't do anything with it!

The concept is to separate an object's interface to the outside world from the implementation of how it performs the tasks that are requested through its interface.

Ideally the interface (ie. public methods) should stay constant, whereas you can tinker with the internal implementation to your heart's content without affecting any other object's calls.

A good approach is for an object not to expose any public properties/data. If another object needs to examine the state of your object you should create an explicit public method for it.