program 3.1 vs program 3.2

[jonr]

This is more of a 'theoretical' question....

Both of the these programs dealt with fractions but program 3.2 used classes for illustration purposes.  Both programs yielded the same result but the program 3.2 was longer, contained more code and really used a more roundabout way to perform the same thing.  I realize that the idea behind comparing these two small programs was to start the learning process about classes, etc., and not illustrate doing something using the most efficient method.

So, obviously there has to be some sort of benefit to using an OO approach to something like this for real world problems.  I'm thinking along the lines of scalability and extensibility to offset the explicit situation in these two examples where the OO approach was much longer to perform the exact same simple result.  Can someone give an example (perhaps using these two programs as a starting off point) of how the OO program here can be more scalable and extensible?

I realize that the answer to this may arrive as I get further into the book, but I guess I'm a little impatient....

[rue]

Imagine your program needing to work on hundreds of fraction numbers.

With Prog3.2, you just can easily [Fraction alloc] anytime you need a new fraction object.  You don't even need to know how many Fraction numbers/objects you need in advance. Also, the numerators and denominators stay with the Fraction object all the time. No danger of mixing up the numerator for one fraction with the denominator  of another fraction object.

With Prog3.1, you will need to keep track of hundreds of separate numerator and denominator variables.
Plus, chances are high you could mix the numerator variable of one number with the denominator of another number. i.e.  numerator1/denomator2  ... and you need to know in advance how many numerator and denominator variables you're going to declare.  What if you don't know before hand how many you're going to use?

If you need to do some fraction addition, with Prog3.2, you can just pass the (2) fraction objects to the function that will add both numbers. myFraction1, myFraction2

With Prog3.1, to add 2 fractions, your add function will need to accept (4) variables, num1,den1,num2,den2.

I'm still a newb to ObjC but that's how I understand it.

[jonr]

Thanks for the reply; I've been away from the forum for awhile.

I see your point and I was thinking along those lines too.  However with regards to the benefits of the OOP approach here relating to examples 3.1 and 3.2, let me rephrase the question.  Let's say that the non-OOP example (3.1) was written using a function (I'm using C terminology here) each time a fraction was needed to be created.  The function could simply be written in a way where all you'd have to do is throw it two arguments (one for the denominator, one for the numerator), and voila, a fraction.  This certainly makes example 3.1 more useable, and seems to mimic some of the extended functionality that example 3.3 has.  With this being the case, citing this type of potential change to example 3.1, it makes the benefits of an OOP approach more murky.  This probably is case (for the most part) of this simply being an example that is not sophisticated enough to really see the benefits of an OOP approach...or just my myopia...

[SignalStream]

When I first looked at those two examples, I also thought the same thing.  One benefit that I see regarding OO is that a developer usually does not have to deal with programming a class from scratch, since many exist.  So the @interface, and @implementation sections would not have to be programmed.  In this case I would just have to work with the pre-built methods in the main program.