[RESOLVED] Understanding classes, objects, and other OO basics

amnesia623

Hello -

I am reading a book on PHP in the hopes to start to get a grasp on the language.

Right now I'm in the Reusable Code😮bject Oriented Programming section and I want to make sure I understand this section because (obviously) this is a building block to being a good coder.

So I just want to make sure I understand the architecture of this: You have a class that is full of objects (functions) that have attributes (vars). When you want to use the functionality of a class you need to create a new instance of that class, correct?

Methods would be how the functions operate?

I'm a little confused at this, any help with this would be great.

Weedpacket

Not quite. A class defines a type of object. Like "Book" is a class, and the thing you're reading is an object that belongs to that class.

Another way of saying it is that the thing you're reading is an instance of the class "Book". When you say "$foo = new Something()" you create a new object, an instance of "Something", and store it in $foo.

Objects and classes can both have members. A member can be a property - a variable, something it knows; or a method - a function, something it can do.

Attributes are different again. PHP's attributes include "public", "protected", and "private" - which are used to mark which members should be visible to everyone or kept private - and "static" which is used to mark that a member belongs to the class instead of to its instances.

amnesia623

Thanks for the reply.
It's a little clearer now but let me read more to see if I get that 'lightbulb moment.'

shawty

One thing i had taught to me when i was learning the principles of OOP was that classes (Objects) are designed to be like real world object (as Weed describes above by using a book)

My tutor used the analogy of being a restaurant, and the following scenario.

You enter the door and wait, the waiter approaches you and shows you to your table, and then presents you with a menu.

You choose your food from the menu.

The waiter returns, takes your order, takes the menus then leaves.

The waiter takes your order to the chef.

The chef prepares your meal as per your request.

The chef passes the complete meal to the waiter, who then brings the meal to your table.

If you look at the above sequence, you (The customer object) has a wait method, a menu_read method a sit_down method and an order_storage variable.

The waiter (Waiter object) has an order_storage variable, an accept_order method, a deliver_order method, a carry_meal method and a take_menu method.

The Chef (Chef object) has an accept_order method, a cook_meal method and a give_meal method.

Of course this is deliberately very simplified, and in reality i'm sure you could probably add half a dozen more methods/variables and such like if you analysied the sequence further.

The point is however, anything that constitutes some kind of action to take is a method, any data that that action operates on is a variable.

If an action is only performed by that object (Such as the chef cooking the meal) then it's a private method, if it's a method that interfaces to another class (Such as passing the meal to the waiter) then it's a public method.

Most data will by it's nature be private to a class, but there are times when it may need to be public.

In the restaurant example, the order_storage could be public and shared between all objects, or you could make it private and insist that a method be used to manipulate it.

Classes/Objects used in this fashion are used to provide a blackbox programming model. Above... the Customer object does not need to know how the chef object prepares his meal, he just needs to know that it will arrive at his table when it's ready, how it gets there is of no concern. You could replace the chef object with a "french chef" object, and as long as it had the same "public interface" as the original chef then everything would work just the same.

That's the essence of Object orientated programming in a nutshell, and something which has come of age in PHP5.

Cheers

Shawty

NogDog

Read and digest PHP Objects, Patterns, and Practice and there's a good chance the light bulb may start to flicker on a bit more. 🙂 (At least it was one of the main triggers for my "Oh, I get it!" moment in the realm of OOP.)

PS: The author has a couple on-line tutorials that might help, too:
Getting started with objects with PHP V5
Advanced PHP V5 objects

amnesia623

Wow shawty, that actually helps a lot. From that and what Weedpacket has said I think I might be getting it.

So, to repeat what I just read to make sure I get it:

You have the Customer object, Waiter object, and the chef objects.

The customer has their order information stored in the public "order" variable. The waiter object uses it's "take_order" method to pull the information from the customer objects "order" variable and store it in it's own "customer_order" variable. The chef object then uses it's own "retrieve_order" method to get the "customer_order" variable and process the information in the variable via the "cook_order" method. Once the order is finished the chef object then calls the the waiter object's "deliver_food" method to then deliver the food using the waiter object's cook order variable.

The chef's "cook_order" method could be private because, technically, nobody should be cooking food except the chef. The customers method for deciding on the order could be private or public (protected?) because there could be outside variables that effect how the customer object decides it's order.

Is this correct?

So is the term class and object interchangeable? And, to see if I get it further, you can have several instances of waiter, several instances of customer, and several (if desired) instances of chef. Each instance can be controlled differently and have different methods applied to it.

Am I on the right track? OOP has been very intimidating to me, I don't know why...

Again, thanks for taking the time for helping me understand this.

NogDog - I will look into that book, thanks!

NogDog

Just to blow your mind a bit.... 😉

Since the waiter, cook, and customer are all similar objects, you could have a Person super-class from which each of those specialized classes are derived (see "inheritance" and the "extends" keyword).

Also, an Order can be an object. (Objects don't have to be concrete objects, they can also represent processes, concepts, etc.) So a Waiter object may instantiate an Order object as part of its takeOrder() method. Once the Waiter is done interfacing with the Customer object(s) to populate the data for that Order, it then could pass that Order object on to the Cook object for further processing, and so forth, eventually when everything is done having the Waiter or Customer object passing the Order object on to the Cashier object (another sub-class of Person). 🙂

amnesia623

So an object is just a grouping of methods, variables, and (for lack of knowing a better term) code.

I understand inheritance and extends, well at least the concepts.

So, as stated in the chef object example above. You could have a chef superclass that cooks. But have a (child?) class called "french_chef" that inherits all the cooking methods but adds other methods to it.

The "order" class could also process cost of the order including tax and tip.

There could be a "server" super-class that would hold all common properties and attributes for child objects such as waiters, bussers, hostess, etc...

So if I were to inherit attributes and methods (are they the same?) from a super-class and then add to it, would that be extending the class?

Think this is becoming clearer now, thanks for the help!

laserlight

amnesia623 wrote:
So if I were to inherit attributes and methods (are they the same?) from a super-class and then add to it, would that be extending the class?

"Attributes" refer to the member variables, "methods" refer to the member functions. Yes, since inheritance is "extending" the class.

shawty

amnesia623;10906951 wrote:
Wow shawty, that actually helps a lot. From that and what Weedpacket has said I think I might be getting it.

So, to repeat what I just read to make sure I get it:

You have the Customer object, Waiter object, and the chef objects.

The customer has their order information stored in the public "order" variable. The waiter object uses it's "take_order" method to pull the information from the customer objects "order" variable and store it in it's own "customer_order" variable. The chef object then uses it's own "retrieve_order" method to get the "customer_order" variable and process the information in the variable via the "cook_order" method. Once the order is finished the chef object then calls the the waiter object's "deliver_food" method to then deliver the food using the waiter object's cook order variable.

The chef's "cook_order" method could be private because, technically, nobody should be cooking food except the chef. The customers method for deciding on the order could be private or public (protected?) because there could be outside variables that effect how the customer object decides it's order.

Is this correct?

So is the term class and object interchangeable? And, to see if I get it further, you can have several instances of waiter, several instances of customer, and several (if desired) instances of chef. Each instance can be controlled differently and have different methods applied to it.

Am I on the right track? OOP has been very intimidating to me, I don't know why...

Again, thanks for taking the time for helping me understand this.

NogDog - I will look into that book, thanks!

Pretty much.... :-)

To clear up your question on "protected" variables/methods, these are items that are not public but can be accessed by an extension to the original object. as an Example...

your chef object is the base, you then bring in a "french chef" that specializes in french cooking. The French chef still posses all the methods/variables of the chef, but adds his own "French specific" methods.

Because he's an extension of the chef, he knows how to "chop vegetables" and "fry onions", so these methods are public to him, but private to the customer & waiter class. or in OOP speak they are "protected" from an object that does not understand them.

This extension mechanism is called inheritance, and means that you make use of whats already there and expand on it. Which is exactly what NogDog is on about by making a base person and extending.

Interchangability of classes & objects depends on who you talk too, and how they where taught. To me yes they are, to some people an object is a collection of classes, and a class is an individual "black box" in an object.

OOP is intimidating to everyone when they first see it. The one thing i will say... Don't treet OOP like a new way of programming, treat it like a new way of thinking about how you already program.

:-)

Cheers

Shawty

NogDog

laserlight;10906965 wrote:
"Attributes" refer to the member variables, "methods" refer to the member functions. Yes, since inheritance is "extending" the class.

Though just to be confusing, I've seen "attributes" collectively refer to both the "methods" and the "properties" (variables) that constitute a class, so you kind of have to see the context in which any given author uses those terms. :rolleyes:

NogDog

shawty;10906969 wrote:
...
OOP is intimidating to everyone when they first see it. The one thing i will say... Don't treet OOP like a new way of programming, treat it like a new way of thinking about how you already program.

:-)

Cheers

Shawty

And whenever that OOP light bulb flickers on (and it will if you stick with it), you'll never want to go back to plain old procedural code except for the simplest of projects.

shawty

Can't disagree with that NogDog. I think in reality that falls under the same umbrella as the classes v's objects question. It depends on how you where taught in the first place.

It took me well over 3 years to get to grips with OOP , and most of that was spent running round in circles because of the way i was taught, then along came a friend and showed me how it all worked in less than a day.

( That was directed at your attributes post :-) )

As for your most recent.....

I could NEVER go back to non object programming now.

laserlight

amnesia623 wrote:
So, as stated in the chef object example above. You could have a chef superclass that cooks. But have a (child?) class called "french_chef" that inherits all the cooking methods but adds other methods to it.

Now, suppose you want to handle Chinese cuisine as well. You might then create a Chinese Chef class. What happens if you have a chef who can prepare both French and Chinese cuisine?

NogDog has hinted a practical solution to this: instead of using inheritance, use composition. You might say that a chef has one or more cuisine preparation skills. The cuisine preparation skills could be part of a cuisine preparation hierarchy themselves.

shawty wrote:
This extension mechanism is called inheritance, and means that you make use of whats already there and expand on it.

Instead of looking at inheritance as simply a way of reusing existing code, I suggest thinking of inheritance as a way of writing code to be used by existing code. One key idea is that ideally, your code should be open for extension, but closed for modification (the Open-Closed Principle).

Suppose you specify an interface and then write a class that implements this interface. You could then write a script that uses this interface to do something. Later, you write another class that implements the same interface. The script that uses the interface does not need to change except to instantiate an object of the new class accordingly.

A quote sometimes attributed to Dijkstra: "if debugging is the process of removing bugs, then programming must be the process of putting them in". Since you make only limited changes to the script that uses the interface, it follows that you are only introducing a similiarly limited number of bugs, assuming that the new class implementation is bug-free.

Related to this is the Liskov Substitution Principle. The basic idea is to think of subclasses as subtypes. The notion is that if you make a statement, e.g., in code, about the base class with respect to its interface, you should be able to substitute the derived class and yet that statement remains true. For example, if a Chef can accept orders, then a French Chef can accept orders, if a French Chef is-a Chef.

EDIT:

NogDog wrote:
Though just to be confusing, I've seen "attributes" collectively refer to both the "methods" and the "properties" (variables) that constitute a class, so you kind of have to see the context in which any given author uses those terms.

That could just be bad pedagogy where "members" would be more appropriate. As I understand it, "attributes" or "data members" should be paired with "methods", "properties" with "behaviours", "member variables" with "member functions".

EDIT #2:

shawty wrote:
Can't disagree with that NogDog. I think in reality that falls under the same umbrella as the classes v's objects question. It depends on how you where taught in the first place.

I am curious as to what is the "classes v's objects question".

That said, the point about it being "how you were taught" is a good one, since the terms might also depend on their use for a given programming language. In that sense, I am wrong to try and universally impose my notion of how the terms should be divided when they could be interpreted either way.

Weedpacket

laserlight wrote:
That said, the point about it being "how you were taught" is a good one, since the terms might also depend on their use for a given programming language.

Like my original description of "attributes" vs. "members". I think that was the C# talking (which allows developers to create their own attributes). But it has to be said that I don't recall "attribute" being used to mean something else in this context, and it does create a term to describe member modifiers (other than "member modifiers") like "public" and "static": note that the best the PHP manual comes up with is "keyword", which is a bit too general.

laserlight

Weedpacket wrote:
Like my original description of "attributes" vs. "members". I think that was the C# talking (which allows developers to create their own attributes). But it has to be said that I don't recall "attribute" being used to mean something else in this context,

I think that the context where you use "attribute" is different. You are talking about the "attributes" of members (or perhaps of variables in general), but in amnesia623's given context it is about the "attributes" of classes and/or objects in an object oriented sense.

Weedpacket wrote:
it does create a term to describe member modifiers (other than "member modifiers") like "public" and "static": note that the best the PHP manual comes up with is "keyword", which is a bit too general.

I find the terms "access modifier", "accessibility modifier", and "visibility modifier" to be more descriptive where public/protected/private are concerned.

shawty

A lot of people do weedpacket. Persoanlly for me the way i look at things, and the way i've always looked at things are via the blackbox principle, beacuse this the the way that made the most sense to me.

I think i'd agree with you about the C# point of view though, that does tend to be the standard.

Originally Posted by shawty
Can't disagree with that NogDog. I think in reality that falls under the same umbrella as the classes v's objects question. It depends on how you where taught in the first place.

Originally posted by laserlight
I am curious as to what is the "classes v's objects question".

@ : earlier in the thread, amnesia asked this...

Is this correct?

So is the term class and object interchangeable? And, to see if I get it further, you can have several instances of waiter, several instances of customer, and several (if desired) instances of chef. Each instance can be controlled differently and have different methods applied to it.

laserlight

Oh, I see that now, and I also see that this is your answer:

shawty wrote:
Interchangability of classes & objects depends on who you talk too, and how they where taught. To me yes they are, to some people an object is a collection of classes, and a class is an individual "black box" in an object.

I have no qualms about interchanging "class" and "object" where loose usage of the terms will suffice, but I also had the impression that the strict concept of "class" to mean a blueprint of some kind for an object, and "object" to mean an instance of a class, is universal with respect to object oriented programming.

In particular, the concept of 'an object is a collection of classes, and a class is an individual "black box" in an object' contains redundancy: it would suffice to eliminate either "object" or "class", e.g., 'an object is a collection of objects, and is an individual "black box"'.

shawty

I couldn't have put it better myself 😃

amnesia623

I just wanted to say thanks for everyone helping me out with this. I think I understand it as I wrote some extremely basic code and was able to figure the basics out.

I can deffinately see the advantages to working in in the OO approach. Although it's more flexible, it almost seems there would need to be more preplanning done.