Page 2 of 2

Posted: Sat Jul 08, 2006 10:08 pm
by Christopher
Yep. Now you have a self contained class that initializes to reasonable defaults. It can also be "generated" one place in your code and passed to the display code that does not need to know the type of thing is is displaying.

I am not sure if you need all of those setter functions. You could set the properties directly if that is your style, or use __call() if you are using PHP5. Individual setters would be good if you want to specific checks to verify that the values are valid.

Two quibbles on naming. Usually the name of the class is not reused in methods, so the methods CreateTextToolTip() and CreateTextToolTip() could just be CreateText() and CreateLink(). And I have found that it is a good practice to standardize the name of your output functions so they can be used polymorphically -- so the method DisplayToolTip() could just be display() or render() or out() or whatever you generally use.

Posted: Sat Jul 08, 2006 10:26 pm
by Benjamin
Ok, so I can just set a property by doing this...

Code: Select all

$ToolTip->TT_BGCOLOR = "#ffffff";
I'm new at coding classes but I spose I should have known that.

As for the rest of what you said, Thank you, I'll adhere more closely to those conventions.

Now I have 2 questions.

1. Why would anyone want to code in 100% oo when there are many situations where a simple function would be easier.
2. Isn't it true that procedural is more efficient and faster than oo?

Posted: Sun Jul 09, 2006 7:43 am
by Nathaniel
Hi astions,

1. I know why, but not well enough to explain it to someone else. I'll defer this one to another.
2. Perhaps so. It's much less true than it used to be, however. A good programmer will program so humans can read it; writing procedural code just because the machine parses it faster is silly. If speed is an issue, you can always implement caching mechanisms and whatnot.

Posted: Sun Jul 09, 2006 8:07 am
by Maugrim_The_Reaper
Both questions are invitiations for a flame war... Comparing Procedural to OO in PHP has that effect unfortunately.
1. Why would anyone want to code in 100% oo when there are many situations where a simple function would be easier.
2. Isn't it true that procedural is more efficient and faster than oo?
Think of it in terms of what you are aiming for in an application. People have many goals. Some want fast execution and a small memory footprint. Some want the app to be testable with the click of a button. Some want the app to produce new code they can re-use in later projects. Some want code that require minimal maintenance. Some want simplicity. Some want readability. The list is endless...

OOP has gained a large following because it covers most of the bases. You can write fast, reuseable, easy to maintain code with OO by following a few key principles and improving your practices. Arguments for Procedural are typically quite valid - but are not necessarily focused on the goals of an OOP programmer. This is what I have always seen when a P vs OOP flame war errupts. Both sides have valid arguments, but they aren't exact opposites.

For number 1, I would add it as a class. Your last creation demonstrated a number of very attractive elements. It would work with defaults, it's re-useable, it's small, lean and focused on a specific task, etc. You yourself just demonstrated the OOP approach very well :). If you see a function as a valid route still (I don't disagree) your OOP class at least packages the logic and task in something you can more easily port to other apps you might work on. Arborint's suggestions refine an already good class.

For number 2, procedural is faster than OO. There is no doubt there. However speed is not the final aim of every OO programmer. Personally I rate the difference as being of little to no concern. Deciding to use procedural instead of OOP before a project is even decided simply to improve speed is a Premature Optimisation. You should examine ALL factors - design time, maintainability, reuseability, testability, memory footprint, benchmark goals, etc. I prefer OOP (not saying everyone will or should) because I rate maintenance time and reuseability very highly. OOP excels at managing those two goals - with procedural it is possible, but requires a great deal of discipline.

Easier is not necessarily better - what's easy now, can make other things very difficult later...;)

I guess the moral of my post is that to consider all effects of a design approach before judging it on one narrow factor, speed.

Posted: Sun Jul 09, 2006 8:26 am
by santosj
Maugrim_The_Reaper wrote:For number 2, procedural is faster than OO. There is no doubt there.
Answer to Question Number 2

The exception would be Java, which has been proven to be just as fast as procedural languages. Yes, I do know that GUI applications in Java tend to be slower at starting up than a C++ application, but that has more to do with the 'programmer' and not the language, except when the GUI API is slow, like in Java. Programming languages can be optimized to speed classes up to the level of procedural counterpart. However, PHP has a long way to go.

Classes carry overhead which isn't found in functions, which will use more memory and slow things down a little bit. Even in C++ using classes is a fraction slower than functions. Even in C++ do you have people arguing the case of procedural vs OO because of speed, among other things. The overhead is worth it when you can have visiblity and constructors and other nice goodies.

Usually good reads, but it does get old. A little off topic, but I agree with everything else, including the bit about choosing classes over functions.

Posted: Sun Jul 09, 2006 12:45 pm
by Benjamin
K Thanks everyone for the excellent answers.

Posted: Sun Jul 09, 2006 5:09 pm
by Christopher
astions wrote:Now I have 2 questions.
And they are two classic questions because they are so commonly asked and really have so little to do with what is important is software development. So I will rant a little ... ;)
astions wrote:1. Why would anyone want to code in 100% oo when there are many situations where a simple function would be easier.
There are so many things wrong in this question. The biggest one is the micro thinking that dominates these debates. You actually compared ALL of the code in an application (code in 100% oo) with ONE function! It is an astonishing comparison! If an application was comprised of ONE function or ONE class I could see how this question might make some sense. And what are these "there are many situations" really? Applications are complex things and good coders makes all sorts of specific implementation decisions. And, I think you are confusing "code in 100% oo" with using the class construct in PHP. They are not the same.

This thread showed a clear example of using the class construct as just a namespace for a bunch of functions. But the real issues with the code had to do with the most common of software design issues -- reducing duplication and dependencies. There was nothing here that even approached the issuse of paradigm choice. However it was shown how the class construct can be easily used to nicely deal with things like code duplication and external dependencies -- no suprise there, that's one of the reasons classes were created.

And since when are programmers who use "OO" prohibited from using function calls!?! Or vice versa. Good choices are what set good coders apart. Knowledge of many possible choices and the ramifications of those choices are at the bottom of those good choices.
astions wrote:2. Isn't it true that procedural is more efficient and faster than oo?
Again micro thinking. And, I am not even sure what "more efficient" means or if is a real goal -- especially since efficiency (e.g .memory usage) is often traded for performance. Sure a single function call is slightly faster than a method call (though the margin has narrowed in recent PHP releases). Applications are complex things and function call speed is only one small part of the whole equation. There may be cases in some PHP apps where using a function call made a necessary difference in perfomance-- I haven't seen it in my own work. Maybe Yahoo on the high end or "15 year old coders" spending their lunch money on cheap virtual servers for their roxxors game on the low end -- but I just haven't seen it. Especially when you can lease additional servers for maybe 2% of the yearly cost of a programmer.

And the performance discussions about functions vs methods ignores the larger fact that performance is really about algorithm choice and subsystem tuning -- again nothing to do with paradigm choice. I won't even get into the tedious discussion of Premature Optimization.

The bottom line is that well designed and well coded applications tend to be not only "more efficient" (whatever that means) and "faster" (because of good algorithm choice and subsystem tuning), but they are also easier to maintain, easier to change, easier to add features to, have fewer bugs, scale better, etc. etc. etc. I find that the whole procedural vs OO debate is more often an excuse for arguing poor design on both ends of the spectrum.

Posted: Sun Jul 09, 2006 10:54 pm
by Benjamin
And answers like yours reaffirm the solid foundation I have commited to build in order to become the best I can be at what I do! :D

Posted: Mon Jul 10, 2006 1:38 am
by Christopher
astions wrote:And answers like yours reaffirm the solid foundation I have commited to build in order to become the best I can be at what I do! :D
I like where you are headed! :)

Keep focused on improving you design skills and it will become self-evident when to use both functions and classes ...