next »

[kurdt]

I have interesting pickle. Everybody is saying that you have to design your classes correctly. But the problem is that nobody actually tells you how to do it and I found very little usable information with some basic google searches. So what are the questions and things to keep in mind when designing your classes? What I have done before is to layout the class as functions (I refuse to call them methods) and then start coding the individual functions like:

Code:

class penis {       
        function execute() {
             $this->initiate();
             while($this->stamina()) {
                  $this->in_out($device);
             }
             $this->spruit();
             $face = new expression();
             $face->relief();
             $this->go_to_sleep();
}

But that approach usually fails because I realize that I still take traditional event based approach when designing classes. And by failing I mean that I usually have to redesign the whole crap when I have coded long enough and realize that this isn't independent because this and that. Like in this example I'm using business login right in the execute() function with $face. Shouldn't that be done outside class in optimal OOP?

So any advices, tips, hints or other helpers?

[isthisthingon]

This is pretty generic but here's what I look for.  Although a class ultimately implements functionality (unless it's a base class), it should ideally be an inheritable concept.  So...

Class: Paint
Class Brown:Paint
Class Metal:Brown:Paint
Class Car:Metal:Brown:Paint
etc. etc.

Granted, that was totally lame and leaning towards wrong.  I have no time and just wanted to quickly share the essence of what I believe truly good OOP consists of.  A class is nothing but potential.  An instance of that class (an object) is a thing.  C-style functions are also "things."  But well designed classes respect their purpose and allow the combining of themselves with others or instantiating code to actually become a thing.

Therefore, paying attention to the realistic limits of what brown paint really is should be a guidepost to correct class design.  Classes mirror specific dimensions of reality.  When a design is well thought out these classes will behave like their physical counterparts.

Nebulous and unhelpful I'm sure!  But at least I'd avoiding class design as a mere code execution point for end-user functionality 

[kurdt]

So, lemme spar here a little. I have come to these conclusions:

- When you design a class, the main importance is to provide a clear cluster for methods/functions related to that topic (a.k.a dog class has eat(), poop(), isAlive() etc.)
- Important realization: With OOP data does things instead of things are done to data

How to know what kind of functions to write so it will be truly OOP instead of getting trapped in the old procedural ways? Answer is rather easy, make clear patterns how you write methods/functions inside a class. These patterns will make it really easy to think in a way that it's as independent as possible and doesn't rely too much on other functions inside the class.

Here's my function types:
- Questions :: isImage();
- Answers :: countRows(); a.k.a getters
- Morphs :: sortAsc();
- Actions :: executeRequest(); in curl

Everything else is pure independent object accessing & modifying except Actions which are basically quick usage functions for the class. Actions are procedural and event based but they are really not necessary for the class but more of an usage scenarios for your certain program.

Anybody feel like contributing?

[nop_90]

Ussually I get a piece of paper or pieces of paper
Then I write down what do I want to achieve as in what will this program do.

Then I like break it down into "parts" with each part as independant as possible.
Then I basically fill in the blanks

I do this all on paper. Like one sheet of paper per class.
I just make the class methods/properties but do not actually write the functions.

And by failing I mean that I usually have to redesign the whole crap.

That is normal.
Basically when u start out despite how hard you try you can not think of all the possibilites.
So eventually it becomes easier to rewrite everything from scratch instead of trying to fix your crappy design
Basically you learn from what does not work lol.

Prime example is any widget set (GUI are perfect for the class design).
QT for example has gone thru 4 major revisions / rewrites.

[kurdt]

QT for example has gone thru 4 major revisions / rewrites.

Yeah and with Quicktime X they removed the one feature that made Quicktime really excellent: Speed control with automated pitch control. I watch all lectures & courses with at least 2.5x speed and now that option is gone from Quicktime X. I read somewhere that they kept the old Quicktime in SL so maybe I'll dig it up and use that instead X.

*edit* or did you mean Nokia's QT?

[perkiset]

Kurdt -

You'd hit upon some of the troubles with OO programming in that it is fairly cerebral and not hard and fast. The best I can tell you is that I look for "encapsulatable jobs" - in other words, things that make good little stand alone nuggets that can be recombined with other things to do other things.

Although some libraries like Borland's makes it so that EVERYTHING is an object, this is overkill. It is extremely easy to go overboard. OO is not the end of procedural programming, but a great tool to augment or replace components of it.

Classes that I create have a tendency to be fundamental tools rather than final execution. Things like: PDF creator (of which I will step down into Report Writer, LetterHead which will step down into Thank You Letter and such), DB Connection, RemoteRequest (which translates down into Web Request, Secure Web Request, Merchant Processing Request which will step into Linkpoint Request and such), Shopping Cart, Shipping Management, Translation Manager (for multilingual websites), Fulfillment Record, List Manager (which has connections to listRules and such) Menu Manager, Custom Translation (for URL translation) ... as you can see, nothing here called, "A Web Site."

I will, however, use classes and objects if the operational structure of the program requires it - my email blaster and spider are both almost completely classes and objects, because their intention is more like the Missile Command example I gave you than a straight up serialized program.

I see no benefit in making EVERYTHING an object in PHP. I see LOTS of benefit making some things an object. In the case of compiled languages there *may* be benefit to making everything an object, but that also depends on the implementation of OO - is there a notion of "friends" - is there a "published" exposure level? These sorts of topics are much deeper than PHP can go, so they don't belong here. But they are worthwhile to learn if you want to know OO from the top to bottom.

[nop_90]

*edit* or did you mean Nokia's QT?

Trolltech's Nokia's QT
Probably one of the best designed GUI's out there.

I think one of the reason's compiled languages push OO is because it is easier to create a compiler.
Speed wise functional language can beat procedural languages, but creating a compiler for functional languages is much more difficult.

Basically practice

[arms]

in python my oop is very lazy.
i basically only use classes when i want to represent something that maintains a state throughout more than one operation. for example:

Code:

class DiggAccountManager(object):

    def __init__(self, username, password):
        self.username = username
        self.password = password
        self.logged_in = False

    def login(self):
        # do some stuff then...
        self.logged_in = True

    def submit_link(self, url, title, description):
        if not self.logged_in:
            self.login()
        # continue with posting link....

otherwise i just write a function.
unless i am using threads, then i will use instances of objects to prevent weird thread shit. i don't even really know if i need to do that and i don't use threading that often.

[isthisthingon]

Although some libraries like Borland's makes it so that EVERYTHING is an object, this is overkill. It is extremely easy to go overboard. OO is not the end of procedural programming, but a great tool to augment or replace components of it.

Totally agree.  Ruby is also completely made up of objects, though semantically it appears free-form scripting.  I liked what vs said the other day about it.  Something like "Ruby allows curly braces... I'm using them!"  Personally I think that by forcing everything into classes/objects people learn how to program with the wrong mindset; if you need something quick and dirty, write a class then instance up an object and use its method(s).  Unlike spontaneity, there's a very appropriate time and place for procedural code.

Here's two terms I live by in class design.  By class design I'm strictly referring to the Crayola IDE 

--- Has a ---
--- Is a ----

Some refer to "Has a" as "Uses" but the point is the same.  So IS this car born of metal?  Although required, the car is not made of air, gas, oil, etc.  Therefore it uses or "has a" gas, air, oil, etc.

From there executable functionality makes more sense.  If the car "has a" stereo then it makes sense for the stereo to expose tuning and volume functionality to the car.  Moped|home|pogo-stick code doesn't change when accessing

Code:

myRadio.volumeAdjust(10);

However, when the new internal radio amps start shipping with the latest radio offering, the code still works but has additional functionality:

Code:

myRadio.volumeAdjust(11);
myRadio.playSatellite('Shark Sandwich');

That's just what I do kurdt.  Not sure if that's what you were asking for but let me know if not.


Oh yeah, relocated to San Jose bitches!!  Best move I've ever had in my life.  Nothing like having a girlfriend that gently reminds me to frag-off and start packing before the day of the move

[nop_90]

Totally agree.  Ruby is also completely made up of objects, though semantically it appears free-form scripting.  I liked what vs said the other day about it.  Something like "Ruby allows curly braces... I'm using them!"  Personally I think that by forcing everything into classes/objects people learn how to program with the wrong mindset; if you need something quick and dirty, write a class then instance up an object and use its method(s).  Unlike spontaneity, there's a very appropriate time and place for procedural code.

Ruby has closures which are more of a "functional" thing then OO.
wierd animal ruby