OOP clarification

[Dormilich]

Although you can't really talk about abstractation without inheritance, can you...

as long as we're not discussing class based (PHP) and prototype based (JavaScript) inheritance… just had a look at OOP @ wikipedia

[Atli]

I mean encapsulation and abstraction. I use the term 'OOP' too loosely.

Mark (also still a newbie(ish) at OOP).

Well, PHP is a loosely typed language.
Maybe I just need to loosen up a bit :)

But, yea.
Encapsulation and abstractation / interfaces are very important OOP concepts.
This thread covers the first one. Next thread: Abstractation :)

Inheritance and polymorphism should also make that list.
Although you can't really talk about abstractation without inheritance, can you...

[Markus]

Can't really agree with you on that one.
Models, and the concept of separating data-interaction from the business logic, belong to the MVC and tier-3 design patterns, not OOP.
(Although, OOP designs tend to end up in that territory.)

OOP is just the tool used to implement these patterns.
You don't have to know how to read a blueprint to operate a hammer :P

I do agree tho that once you start building OOP applications, using these design patterns is a very very good idea. The separation of the data, business and presentation layers is essential in any large application.

I mean encapsulation and abstraction. I use the term 'OOP' too loosely.

Mark (also still a newbie(ish) at OOP).

[Atli]

Think like the manufacture of the object. Would one design a microwave that /only/ reheated pizzas?

My microwave only makes popcorn... probably not by design tho :P

But yea, that's exactly the point I am trying to make.

Classes are more like function libraries than single functions.
They should provide the option of performing tasks, but not simply perform a single task on creation.

[Atli]

Also, you will do your best to separate any data stuff (SQL, file reading, etc) out of your classes into models. This is a key concept in OOP, and very helpful.

Can't really agree with you on that one.
Models, and the concept of separating data-interaction from the business logic, belong to the MVC and tier-3 design patterns, not OOP.
(Although, OOP designs tend to end up in that territory.)

OOP is just the tool used to implement these patterns.
You don't have to know how to read a blueprint to operate a hammer :P

I do agree tho that once you start building OOP applications, using these design patterns is a very very good idea. The separation of the data, business and presentation layers is essential in any large application.

[dlite922]

frank,

Like you said, you seem to gravitate towards a single-function class. If me and you were to design a CAR class:

testDrive.php // uses car class
car.class.php // the car class

you'd be more likely to create one that would start, drive forward, turn left, turn right, reverse and stop all with one call to the class.

If I designed it, I would do it so that it can do it in that same order you did AND most importantly in /any/ other combination possible. For example I could make it start, make 4 left turns and stop WITHOUT even changing my class file, i'd make another file that uses it and call it testDriveTwo.ph p.

My point demonstrates two important benefits of OOP: Extensibility and Reuse.

Think like the manufacture of the object. Would one design a microwave that /only/ reheated pizzas?

Hope that clarifies that subject of Reuse.




Dan

[Markus]

How do I have to imagine that? simply by making another class?

Yes. A model is a data class (think MVC).

class UserInfoModel extends DatabaseAbstraction {

    public function userIDByName(string $name);
    public function nameByUserID(int $id);

}

[Dormilich]

Also, you will do your best to separate any data stuff (SQL, file reading, etc) out of your classes into models.

How do I have to imagine that? simply by making another class?

[Markus]

Atli, I forgot to ask in my last post but in your upload class, I see that you have multiple getters and setters but that only 2 of them are actually being called. Am I reading this right? If I am, I am wondering why you have them in there?

For example.. You have the following that are not being used, or called:
getUploadDir()
getMaxFileSize( )
getAllowedExten sions()

Was this intentional?

Just because they aren't called in his example, doesn't mean they won't be called in others. You've got to think about the long-term, and what users will need from the class.

Also, you will do your best to separate any data stuff (SQL, file reading, etc) out of your classes into models. This is a key concept in OOP, and very helpful.

[fjm]

Atli, I forgot to ask in my last post but in your upload class, I see that you have multiple getters and setters but that only 2 of them are actually being called. Am I reading this right? If I am, I am wondering why you have them in there?

For example.. You have the following that are not being used, or called:
getUploadDir()
getMaxFileSize( )
getAllowedExten sions()

Was this intentional?

[fjm]

Heya Atli,

I totally understand where you are coming from with your example. For some reason... My mind wants to gravitate toward making a class for each function to be performed. In your example, instead of making a music playback class, I would have wanted to make a play class, a pause class, a stop class, etc. To me, it just seems cleaner to do it like that. In fact, I went back through a program I made where I had originally designed 5 classes about 500 lines each so not very big. I went back and seperated out all of my sql and made them their own classes. There were methods in these larger files that had nothing to do with the database so I figured it would be cleaner to seperate these database methods into its own class.

Do you see any problem in creating db models like I am suggesting? For example, a customer class that handles only the CRUD, etc.

Of course, I'm certain that I'm wrong but that's why I'm here. :)

[Atli]

You should never assign classes a single job. They are supposed to provide functionality for some specific area, providing methods to do specific tasks.

It this case, the class provides methods to control file uploads.
The class itself, however, is not confined to just moving a single file.

This specific class might not be the best example of this.

But picture a MusicPlayback class.
It would provide methods to control the playback of music files.
Including methods to: play, pause, stop, rewind, etc...

The class itself is not tied to a single task, and therefore must provide publicly declared methods to trigger the tasks.

That's why I declare the moveFile method public; because that is the way the outside triggers that particular task.

[fjm]

Atli, I have been looking over your upload class and I am curious as to why you allow the moveFile method to be accessible from the outside? I'm not disagreeing with you but only looking to understand your logic.

To me, the moveFile method should probably be made part of the internal class itself away from the outside, because the whole job of a file upload class is to move and upload a file anyway, right?

Why would you tell a file upload class to upload the file from the outside? It just doesn't make sense to me. Could you please explain?

Thanks. :)

[fjm]

Thanks for the replies guys. I think I will re-read this entire post and see if I can rework this example class trying to correct the mistakes and repost it. Thanks for helping me out on this. :)

[dlite922]

Glancing over the discussions since my last post i'd like to add a couple of comments:

1. Frank, I think you're treating a class like it's a script. Two things lead me to this; one is the quote:

The main goal of the class is to take a file from a user, clean the filename and upload it to the server.

. And second is how your constructor is sort of like a trigger and creates a domino affect. A class is used BY another program or another class. This I think is explained well in Atli's "Third" point several posts back.

2. I do not use getters and setters if all they do is directly alter the private member. Might as well make it public anyway. You should have functions that are like "verbs" or actions to the class. For example if the class was a car, accelerate(valu e) , turnOnHeadlight s() etc. while gas-pedal, headlight, wheel where private members. Say to yourself if this was a real life object what would it "do".

Those are the two points I had. See you guys later,




Dan