Page 2 of 2

Posted: Wed Jul 26, 2006 11:01 am
by Benjamin
Pimptastic wrote: Whoa man, what were you thinking...all that in one class :lol: Nice effort.
I just sat down and wrote it lol. I did have to download ZEND studio halfway through it though as I could tell it was going to get hard to keep track of things after a while. I just figured that's what a class was supposed to be. I'm using an __autoload which is the coolest function in the manual I think.

Should it be a module instead, with a folder full of classes or something?

Posted: Wed Jul 26, 2006 11:01 am
by Luke
yea... you posted 7 different things that it does, so right there is 7 classes (and probably more)

Posted: Wed Jul 26, 2006 11:02 am
by Benjamin
Christ

Posted: Wed Jul 26, 2006 11:15 am
by Jenk
Don't be afraid :p

Concise classes are good.

Infact some would possibly argue that the more minimalistic a class is, the better.

Posted: Wed Jul 26, 2006 11:34 am
by Christopher
Jenk wrote:Infact some would possibly argue that the more minimalistic a class is, the better.
This is considered the current Best Practice. Of course it is within reason because sometimes classes can be large -- but in general small is a sign of good design.
The Ninja Space Goat wrote:yea... you posted 7 different things that it does, so right there is 7 classes (and probably more)
Actually there is a good chance that your list is not exactly the class breakdown. You have "Displays", "Validates", "Determines" and "Saves" for actions, and "Form", "Question", and implicitly Test. And we'll need a round of Whisky shots if your "Admin Panel" is in the same class!

You can refactor your way out of this mess, but you will need to decide what the "parts" are and clearly identify what external calls are made to these "parts" and what internal calls are made across "part" boundries.

Posted: Wed Jul 26, 2006 11:39 am
by Benjamin
Ha..

Admin panel is another thousand lines. It modifies database tables when you add/remove questions.

Still have to write code to create dynamic search forms too 8O

I'm almost thinking that my client and I should get this patented.

Posted: Wed Jul 26, 2006 11:54 am
by daedalus__
I've done that a time or two myself Astions, but definately not on this scale. :)

Posted: Wed Jul 26, 2006 12:35 pm
by feyd
I'd say the first round of refactoring breaks it down into the basic superstructure arborint talked about. The next round could easily break it down into twice that many or more.

As an example, in some works I've had several hundred classes involved in pages or interaction instances, with several thousand instances. Now, this will generally only happen on rather large applications. A simple page can easily have a few dozen classes involved.

Posted: Wed Jul 26, 2006 1:03 pm
by Christopher
feyd wrote:A simple page can easily have a few dozen classes involved.
It is interesting that you have the same general metric as I have. It always feels better when someone you respect comes up with the same general answer as you. :)

I don't think that most PHP programmers realize that "a few dozen classes" is fairly normal per page for a modest size site based on some kind of basic framework (i.e. standard code reuse).

Posted: Wed Jul 26, 2006 1:09 pm
by daedalus__
I figure that my tiny framework will be no less than 14 classes when it is finished.

Posted: Wed Jul 26, 2006 5:51 pm
by Ambush Commander
While refactoring will solve lots of problems, there will always be typos or things that are simply implemented wrong.

Unit Tests will tell you when something has gone wrong. Use them.

var_dump (and friends) are good for running data consistency checks. Something not working right, you dig into the internals a bit and try to figure out where things aren't working the way they should be. Sometimes, backtraces and scoping the outputs (if the code is run frequently) can help build a debugging class, but they're optional.