Page 3 of 3
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 5:34 pm
by Christopher
yh.h wrote:You're putting words in my mouth. I was comparing both snippets of code and showing the unnecessary complexity of the OOP version.
So you were using two tiny snippets of code to make sweeping generalizations about methodologies?
yh.h wrote:Well, hey... you were writing a rolodex program. Why did that change all of a sudden?
It did't. I just happend to have a Person class from one of the many other OO programs that also involve people...
yh.h wrote:That's very true, but in the case of making a rolodex program, the degree of complexity you suggested surpasses (by far) what is needed.
The problem with this argument is that your "rolodex program" would quickly grow to hundreds, if not thousands, of lines of application code. The structural code of function and classes would end up as a small percentage of the total code. In the real world, OO simply provides some advanced constructs to organize and implement your code.
yh.h wrote:I want to make it clear that I'm not bashing OOP. OOP is very useful but is *often* misused. And I would really like to see more non-trivial examples of where OOP makes sense and should be used, especially in introductory programming classes.
I think your example was actually a very good one. As I said, it would quickly grow to hundreds of lines of application code. The OO version would be more self documenting, have fewer side effects, probably more reuse, etc.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 9:30 pm
by allspiritseve
yh.h wrote:I have to weigh in on this. I think it is a huge leap you're making. You can't just assume OOP is always better than procedural because it seems like it makes your life simpler. In this case, it clearly does not. Too much simplicity for the sake of simplicity becomes overkill.
OOP making life simpler is the effect, not the cause. The cause is reducing what will probably end up being a rather large function or group of functions into simple component parts, grouped logically into sets of behavior and data (i.e. objects...).
If you'll notice in the first example posted by nor0101, the OOP version had methods for searching and sorting. These were not represented in the prodedural version. That means we need at least three functions for a comparable procedural example that work on the same global variable. Now, your argument was that a comment would fix things... one for each function? In every place that function is used? I'd much rather pass around and work with an explicit $rolodex object than use functions that modify an implicit global variable.
You also mentioned changes.. what if I want more user information stored in the rolodex? Say, a contact address and a billing address (pretty common requirement). That would require either adding more parameters on your function (yuck) or adding a new function. Now, that search function probably needs to get a little more complex. Are you gonna modify that too, or write another function? Either you're going to use search and replace for a week trying to replace all instances of all functions, or you're going to end up with sets of functions that vary slightly and duplicate functionality all across the board. OR... you could have that handy person object implement an interface and code another object that contains addresses.
I think you're arguing from the standpoint that more lines, more objects, and more methods make things more complex. They don't. Splitting a single complex function into simple parts is not making things more complex, nor is it simplicity for simplicity's sake... it's functional, and allows you to group code into reusable portions and localize changes. Those are pretty useful benefits, and far outweigh the argument that more lines of code = more complexity.
Re: Why and When to use OOP?
Posted: Sat May 02, 2009 12:00 am
by yh.h
Alright, I'll stop quoting and replying to each point 'cause I don't think you get what I'm saying and I'm wasting my time.
My point is: I'm sick of seeing code that uses OOP when it shouldn't because it tries to take into account all possible features the system will have in the future. Yes, it makes the code look simpler. Sure, it separates code into components. However, using abstractions everywhere and taking into account all possible ways of making the program flexible is a recipe for extremely complex code and is not what OOP is about.
And yes, I favor less lines of code when more are not useful. Why do so many of you find it hard to believe?
Re: Why and When to use OOP?
Posted: Sat May 02, 2009 12:14 am
by allspiritseve
yh.h wrote:My point is: I'm sick of seeing code that uses OOP when it shouldn't because it tries to take into account all possible features the system will have in the future. Yes, it makes the code look simpler. Sure, it separates code into components. However, using abstractions everywhere and taking into account all possible ways of making the program flexible is a recipe for extremely complex code and is not what OOP is about.
And yes, I favor less lines of code when more are not useful. Why do so many of you find it hard to believe?
You haven't given any good reasons as to why OOP isn't useful in this particular scenario, and we've given you many reasons why it is. Accounting for the fact that things
will change is hardly taking into account "all possible features the system will have in the future". Turning one function into two classes is also hardly "using abstractions everywhere" or "taking into account all possible ways of making the program flexible". If you have the luxury of writing code that will never change, whose requirements will never change, then I envy you. Though, I guess I don't really envy you, because I enjoy the challenge of making my code flexible for the future.
Re: Why and When to use OOP?
Posted: Sat May 02, 2009 12:20 am
by Benjamin
yh.h wrote:I'm sick of seeing code that uses OOP when it shouldn't because it tries to take into account all possible features the system will have in the future.
That's not the point of OOP. The point is decomposition. Each object is a class. The class breaks down the object into individual pieces. This is called decomposition and it's just how things are done in Top Down Design. Each class method performs a single task and should be named accordingly. Yes there is more code, yes their are numerous benefits and yes the benefits outweigh any drawbacks you can possibly imagine.
Please review the following page because it explains this in more detail:
http://www.cs.usfca.edu/~parrt/course/6 ... esign.html
I have not read this thread. I am only replying to the quoted comment.
Re: Why and When to use OOP?
Posted: Sun May 03, 2009 9:24 am
by mickd
yh.h
The reason why you keep seeing code that is so simple that the OOP solution seems overly complicated is because the practical benefits of OOP isn't something that can easily be demonstrated by a 10 line script. Where OOP becomes superior is when you design and create enterprise applications (and not just a hello world script, etc). However, it will be far too much for the sake of the people learning OOP to be given a 10k line script as proof (and too complex to absorb). So instead, the concepts where everything is made so much easier by OOP in enterprise applications are demonstrated using simple scripts (such as the rolodex), which of course can be written just as simply (if not simpler) using procedural methods.
Keep in mind a lot of the people replying here have dealt with creating these types of enterprise applications, and its through those experiences they are commenting from.
Yes for a 10 line script procedural is probably just as good. No for a 20k line application, procedural wouldn't. Even a script hitting 1k lines, you should have probably considered using OOP instead.
Re: Why and When to use OOP?
Posted: Sun May 03, 2009 9:06 pm
by josh
yh.h wrote:hey... you were writing a rolodex program. Why did that change all of a sudden?
How come the same stocks that were hot 10yrs ago aren't the same ones that are doing good? Do you mean to tell me over time human needs change?
