Tips on choosing PHP Classes

Tom_Tees

How do you decide what makes a good class in PHP?

I am building an e-commerce site and have my use-cases/workflow all done.

I also have most of the backend database design done.

So how do I know what to make a class?

Being new to OOP, I am really stuck on this point... 😕

TomTees

NogDog

I don't have any simple answers for you, other than to make sure that each class is (reasonably) narrowly focused and does not try to be to many things. A couple books that have helped me think objectively are PHP 5 Objects, Patterns, and Practice by Zandstra and Head First Object-Oriented Analysis and Design by McLauhglin, Police, and West.

Res

I've found reading up on Object Relational Mapping to be extremely helpful when trying to conceptualize how classes come together. Most of the stuff is geared towards Java and other languages, but the majority of it translates just fine.

This is a link I sent to a friend on the same subject a few weeks ago
http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html

A google search will turn up a wealth of information.

As NogDog said though, there is no easy answer. Most of the learning I've done has been doing it wrong and learning how badly I screwed myself and why. Spending some time in something like Java, where everything is OOP, might help gain some perspective.

sneakyimp

This is perhaps one of the hardest-won pieces of PHP wisdom and really good practice is generally learned through mistakes that you make -- such as when you are asked to go update a website with some new functionality and you realize how hard it's going to be due to poor decisions before.

I've found that one of the most useful things that OOP provides is protection from name collisions. For example, if you choose a to name a global variable that holds your database connection something like $db, there's a very good chance that you'll have a name collision if you try to get your code to play nice with code written by someone else. Classes let you define variables that are internal to the class so they don't pollute the global namespace.

Same basic idea applies to functions and constants. In OOP, they tend to be internal to or attached to a class.

But what is a GOOD class? I would say that you'd say this about it:
1) It doesn't refer internally to any global variables of functions. All global information should be passed into it through a constructor or by some method. This is not always possible or convenient, but usually is a good idea.

2) It cleans up your code so that it's easier to see what is going on. This usually means that method names clearly indicate what they do. In practice there is usually a tradeoff here. You use a class to accomplish something and, unless you actually locate the class source file and read its contents, you don't really know how any given chore is accomplished.

3) The most useful class I've seen tend to let you write simple code at the top level of your application without worrying about the specifics of how something is accomplished while at the same time giving you the power to completely alter how the class works without having to rewrite tons of code. Some pretty good examples that come to mind are classes to handle mail or database interaction. If I just use $mailer->mail at the top level, the top-level code doesn't mind if I alter the mail class to use GMAIL instead of yahoo mail or sendmail or whatever.

Tom_Tees

NogDog;10954727 wrote:
I don't have any simple answers for you, other than to make sure that each class is (reasonably) narrowly focused and does not try to be to many things. A couple books that have helped me think objectively are PHP 5 Objects, Patterns, and Practice by Zandstra and Head First Object-Oriented Analysis and Design by McLauhglin, Police, and West.

Since I am unemployed currently, do you know of any similar sources online?

(I've wanted to buy and read that first book, but it will have to wait a bit.)

TomTees

Tom_Tees

sneakyimp;10954749 wrote:
This is perhaps one of the hardest-won pieces of PHP wisdom and really good practice is generally learned through mistakes that you make -- such as when you are asked to go update a website with some new functionality and you realize how hard it's going to be due to poor decisions before.

Should classes be Nouns or Verbs?

Should classes represent Database Constructs (e.g. tables)?

Should classes represent Business Things (e.g. Customer) or Business Processes (e.g. Register New Customer)?

I've found that one of the most useful things that OOP provides is protection from name collisions. For example, if you choose a to name a global variable that holds your database connection something like $db, there's a very good chance that you'll have a name collision if you try to get your code to play nice with code written by someone else. Classes let you define variables that are internal to the class so they don't pollute the global namespace.

Yah, I've been told to avoid global variables and finding the object that has what you want versus transferring what you want from class A to class B.

Same basic idea applies to functions and constants. In OOP, they tend to be internal to or attached to a class.

But what is a GOOD class? I would say that you'd say this about it:
1) It doesn't refer internally to any global variables of functions. All global information should be passed into it through a constructor or by some method. This is not always possible or convenient, but usually is a good idea.

2) It cleans up your code so that it's easier to see what is going on. This usually means that method names clearly indicate what they do. In practice there is usually a tradeoff here. You use a class to accomplish something and, unless you actually locate the class source file and read its contents, you don't really know how any given chore is accomplished.

3) The most useful class I've seen tend to let you write simple code at the top level of your application without worrying about the specifics of how something is accomplished while at the same time giving you the power to completely alter how the class works without having to rewrite tons of code. Some pretty good examples that come to mind are classes to handle mail or database interaction. If I just use $mailer->mail at the top level, the top-level code doesn't mind if I alter the mail class to use GMAIL instead of yahoo mail or sendmail or whatever.

Okay.

TomTees

sneakyimp

Classes are nouns.

Properties of classes (i.e., 'class variables' and 'class constants') are nouns.

Methods of classes are typically verbs.

Having a class represent a DB table is a reasonable use of a class, but there are some more compelling ways to use a class for database work.

A class should represent a Business Thing and the class methods (i.e., class functions) should represent actions associated with that object -- i.e., 'Business Processes' should be implemented by methods.

Or that's my take anyway.

Nog linked some pretty interesting-looking aritcles in this thread.

NogDog

Should classes represent Business Things (e.g. Customer) or Business Processes (e.g. Register New Customer)?

You might have a Customer class which extends a User class (which could also be extended for Admin, Salesperson, etc. as needed). In an MVC pattern, you might have a CustomerRegistration class that extends your Controller class and uses the Customer class, with the CustomerRegistration class controlling the process while the Customer class would provide the methods it uses to search/add/update/delete customer users in the database.

Tom_Tees

NogDog;10954766 wrote:
You might have a Customer class which extends a User class (which could also be extended for Admin, Salesperson, etc. as needed). In an MVC pattern, you might have a CustomerRegistration class that extends your Controller class and uses the Customer class, with the CustomerRegistration class controlling the process while the Customer class would provide the methods it uses to search/add/update/delete customer users in the database.

Okay, so classes can be both "Things" and "Processes" - which are both technically "nouns"?!

I remember reading somewhere that you (typcially) do not want your classes to exactly mirror back-end tables, because databases are in charge of efficiently storing data while your application is in charge of efficiently using/processing your data.

TomTees

Res

This link may help. I read it years ago and found their description of a bicycle as a collection of objects really helpful in understanding how it all comes together.

http://java.sun.com/docs/books/tutorial/java/concepts/object.html

This is also very very good in explain things to those less familiar
http://www.phpfreaks.com/tutorial/oo-php-part-1-oop-in-full-effect

NogDog

The noun/verb thing is, at best, a guideline. Sure, you could put all sorts of stuff inside your user class to deal with user registration, but then it may become bloated with lots of tangentially related things. The goal is to keep each class focused on doing one thing well (for some value of "one" 😉 ). I might want my User class to simply provide means to read/write user-specific data. I can then extend that with a Customer class to deal with things that make a Customer different from a generic user (hinting that perhaps the User class should be an abstract class?)

Now when you get to registering a user, you may have to deal with things that are not really aspects of a user, but aspects of the registration process: validating email, ensuring the password is strong enough, processing CAPTHCA validation, and so forth; none of which has anything to do with what defines a customer. So I'd rather pull those out into another class -- or maybe into multiple classes if more logical -- which can be used by a Registration class.

Tom_Tees

Last night over supper and my computer (less the wife) I flipped threw the sketches that I did of our site, and wrote down "things" and "processes" that might be classes.

Here is my crude list... (certainly not every possible class)
- ProductSearch
- SignIn
- ShoppingCart
- WishList
- Categories
- Gallery
- PageNavigation
- ProductDetails
- PictureRotator
- Registration
- CheckOut
- BillingAddress
- ShippingAddress
- SelectShippingOption
- PaymentInfo
- CreditCardValidator
- ReviewFinalOrder
- PlaceOrder

To me, obviously "things" (e.g. Customer, Product, Order) would make good classes.

But I also see "processes" (e.g. SignIn, Registration, SelectShippingOption) as good classes too, because they data and functions and combine them into some resulting end state.

TomTees

Tom_Tees

NogDog;10954777 wrote:
The noun/verb thing is, at best, a guideline. Sure, you could put all sorts of stuff inside your user class to deal with user registration, but then it may become bloated with lots of tangentially related things.

But that is exactly what I am trying to avoid. And it is my undestanding of the power of OOP ---> break things up into specialized classes/objects that communicate to form a larger whole. (Just like in real life.)

The goal is to keep each class focused on doing one thing well (for some value of "one" 😉 ).

Didn't I just say that?! 🙂

I might want my User class to simply provide means to read/write user-specific data. I can then extend that with a Customer class to deal with things that make a Customer different from a generic user (hinting that perhaps the User class should be an abstract class?)

Well, yesterday I was wondering if I should have...

class User{
}

class Visitor extends User{
- not sure why we need a visitor, but hey!
}

class Customer extends User{
- id
- first_name
- last_name
}

Now when you get to registering a user, you may have to deal with things that are not really aspects of a user, but aspects of the registration process: validating email, ensuring the password is strong enough, processing CAPTHCA validation, and so forth; none of which has anything to do with what defines a customer. So I'd rather pull those out into another class -- or maybe into multiple classes if more logical -- which can be used by a Registration class.

This is exactly where I was going with things...

Here is the alternative flow in my use-case...

[B][U]Create New Customer Account[/U][/B]	
	At {Authenticate Customer}, if the User has not registered...
	The System instructs the User to create a Customer Account.
	The System switches to a Secure Connection to protect the User's personal information.
	The System displays text explaining the need to create a Customer Account.
	The System prompts the User to enter a Username.
	The System prompts the User to re-enter the Username.
	The System prompts the User to enter a Password.
	The System prompts the User to re-enter the Password.
	The System prompts the User to accept OURSTORE's User Agreement and Privacy Policy.
	The User enters a Username.
	The User re-enters the Username.
	The System validates the format of the Usernames.
	The System validates that both Usernames match.
	The System ensures the Username is unique and does not already exist in the Customers List.
	The User enters a Password.
	The User re-enters a Password.
	The System validates the format of the Passwords.
	The System validates that both Passwords match.
	The User accepts the User Agreement and Privacy Policy.
	The System send an Activation E-mail to the Primary E-mail (i.e. Username).
	The System displays instructions on how to “activate” the Username/Account.
	The Customer is required to click on a link in the Activation E-mail's body to validate the Primary E-mail.
	The Customer clicks on the link.
	An e-mail is sent back to the System.
	The System confirms that new Customer's Username/Primary E-mail address is valid.
	The System “activates” the Customer's Account.
	The System logs out the Customer.
	The System sends an e-mail notifying the Customer that his/her Customer Account has been activated.
	The System instructs the Customer - in the e-mail - to return to the website and log in.
	The Customer returns to OURSTORE's website.
	The Customer logs in to his/her account.
	The use-case continues at the next step...

So I figured that is an entirely different creature than a "Customer" and so it should be its own class.

TomTees

NogDog

FWIW, I'd probably start with an existing framework such as CodeIgniter (since it's the one I know pretty well), use a 3rd party library for it such as DB_Auth to handle user registration and validation, and then get down to the particulars of what additional data I need in the user table for my customers, and then on to the other details specific to the site. 🙂

Tom_Tees

NogDog;10954780 wrote:
FWIW, I'd probably start with an existing framework such as CodeIgniter (since it's the one I know pretty well), use a 3rd party library for it such as DB_Auth to handle user registration and validation, and then get down to the particulars of what additional data I need in the user table for my customers, and then on to the other details specific to the site. 🙂

Okay, but do you agree or disagree with what I just posted?

TomTees

sana

Hi,

Check out symfony 1.4 with Doctrine ORM.

Regards

Sana

Weedpacket

Tom Tees wrote:
Okay, but do you agree or disagree with what I just posted?

It's that noun/verb thing, again; but now it's whether something is a noun or a verb. In this instance the verb is "register", but there is also the corresponding noun of "registration". That suggests having some sort of Registration object to capture your use case, navigating the process and also representing the "protouser" (a "Registrant"?) - more than a generic Visitor, but not yet a User.

Ultimately it's possible to treat any concept as something that can be objectified (look up the word "reify"). In a way this is the conceptual principle behind a lot of software design.

The question is how far to take it.

What I tend to do is start with the "obvious" top-level classes - the nouns representing the concrete entities that the application exists for (e.g., users, products). At first they're empty do-nothing things; then I go through each use case as it comes up and look at adding just enough functionality to the classes responsible to satisfy the case. I also find that each use case in itself gives suggestions about the class structure: by definition, the steps in a use case describe how various elements interact with and relate to each other.

If I find that there is a tendency for the instances of two classes to rely on each other then it suggests that there should be a new class representing the relationship and the code that relates them should be moved there. If there are a bunch of methods that have a lot to do with each other but little to do with the rest of the class then perhaps they should take on a life (and instance) of their own - either as a property of the object that gave parthenogenetic birth to it or vice versa.

One thing I find is that I don't use object inheritance all that much! Instead I end up grouping together related classes with interfaces. When two classes share a lot of functionality, then instead of one subclassing the other I end up with a helper class that implements that functionality; instances of the two original classes get access to that functionality by keeping an instance of the helper class.

Similarly, two objects might end up communicating by keeping references to and conversing via a shared "conversation" object (and once its formalised I write an interface describing the protocol).

Tom_Tees

Weedpacket;10954986 wrote:
It's that noun/verb thing, again; but now it's whether something is a noun or a verb. In this instance the verb is "register", but there is also the corresponding noun of "registration".

Or a gerund (e.g. "Registering") which is a noun.

That suggests having some sort of Registration object to capture your use case, navigating the process and also representing the "protouser" (a "Registrant"?) - more than a generic Visitor, but not yet a User.

That was my larger point... In addition to physical things (e.g. Custoemrs, Products, Orders), that "processes" (e.g. Signing-In, Registering, Checking-Out) also seem to be good candidates for classes.

In this thread, there seemed to be too many people that were thinking, "But registering is an action and therefore it should be a method."

I think that is too simple of a view of the real world.

"resetPassword()" is an action and would make a good method, however, "Register a New Customer" (i.e. "Registration") is a process that entails many things work better together in aggregation as one logical construct (i.e. a class).

And, by the way, "registration" is a noun and so would be a great candidate to be a class/object.

Ultimately it's possible to treat any concept as something that can be objectified (look up the word "reify"). In a way this is the conceptual principle behind a lot of software design.

Agreed.

The question is how far to take it.

What I tend to do is start with the "obvious" top-level classes - the nouns representing the concrete entities that the application exists for (e.g., users, products). At first they're empty do-nothing things; then I go through each use case as it comes up and look at adding just enough functionality to the classes responsible to satisfy the case.

So you take a "proper" use-case, and you find objects that can act out that use-case, i.e. you start to functionally decompose a use-case into one of more objects?

I also find that each use case in itself gives suggestions about the class structure: by definition, the steps in a use case describe how various elements interact with and relate to each other.

Agreed.

If I find that there is a tendency for the instances of two classes to rely on each other then it suggests that there should be a new class representing the relationship and the code that relates them should be moved there.

Almost like a "junction table" in a many-to-many relationship in a database?

If there are a bunch of methods that have a lot to do with each other but little to do with the rest of the class then perhaps they should take on a life (and instance) of their own - either as a property of the object that gave parthenogenetic birth to it or vice versa.

Can you provide some real-world examples of this?

One thing I find is that I don't use object inheritance all that much! Instead I end up grouping together related classes with interfaces. When two classes share a lot of functionality, then instead of one subclassing the other I end up with a helper class that implements that functionality; instances of the two original classes get access to that functionality by keeping an instance of the helper class.

You lost me there. I'm still weak with more advanced concepts like interfaces.

Similarly, two objects might end up communicating by keeping references to and conversing via a shared "conversation" object (and once its formalised I write an interface describing the protocol).

So this sounds like what you were talking about earlier?

Thanks for the thought-provoking post!!

TomTees

NogDog

It's worth looking at some of the more common OOP design patterns out there, in particular to get a feel how objects can use other objects to achieve different design goals.

http://www.ibm.com/developerworks/library/os-php-designptrns/
http://www.fluffycat.com/PHP-Design-Patterns/

Weedpacket

Tom Tees wrote:
And, by the way, "registration" is a noun and so would be a great candidate to be a class/object.

Yes, I could have written my first sentence a bit better; it was afterwards I noticed that "register" could be a noun as well, and I risked going off on a tangent about the orthogonality of natural languages and parts of speech....

So you take a "proper" use-case, and you find objects that can act out that use-case, i.e. you start to functionally decompose a use-case into one of more objects?

Effectively, yes; something I don't do enough of, but which fits in well with the idea is that of Behaviour-driven development: fleshed out with example hard data they can be formalised in code and serve as programs that test the system under construction.

Can you provide some real-world examples of this?

You lost me there. I'm still weak with more advanced concepts like interfaces.

As far as "real-world" goes, the more popular and robust frameworks such as Zend's - the sort that have been out in the real world enough to have been well-refined.

For my own example is a class library I'm just starting, for manipulating graphs. Algorithmic Graph Theory is a whole branch of mathematics, and there is a huge array of different attributes that a graph may or may not have: a graph might be connected, a tree, bipartite - or any combination. There is no consistent class hierarchy that can be imposed, so there's no help in making, say, BipartiteGraph and TreeGraph as subclasses of Graph, because what if I want a bipartite tree? One of them would have to subclass the other, and then I would either have "all bipartite graphs are trees" or "all trees are bipartite" - which is bogus.

So instead they're declared as interfaces. A class is free to implement IBipartiteGraph regardless of its pedigree. Then all that's required of the class is that it implement (somehow) all the methods the interface lists (e.g., the defining characteristic of a bipartite graph is that its vertices can be grouped into two sets, with all of the neighbours of any vertex in either set being in the other set, so there would be a method that returns the two sets of vertices).

Interfaces can have their own hierarchy. ITreeGraph and IBipartiteGraph both extend IGraph, and there would also be an IRootedTreeGraph (I've got to work on those names, I think; namespaces?), which does everything a tree (and therefore graph) does, plus distinguishes one vertex as special.

Now the other part:

Weedpacket wrote:
If there are a bunch of methods that have a lot to do with each other but little to do with the rest of the class then perhaps they should take on a life (and instance) of their own

One example is from your use case: there are a whole slew of steps involved in registration, and a whole slew of methods to go with it. They're going to be passing all sorts of stuff about and calling each other, but they're not going to be having much to do with, say, the methods for tweaking a user's profile preferences. That suggests that registering and tweaking belong in separate classes.

From my graph library, a lot of algorithms involve searching for paths with various properties. A lot of the time the search itself is the same, with only the property being checked differing.

I could lump all of the algorithms into whatever class they're appropriate to, but there are major problems.

Most of the time I don't have classes, I have interfaces. I might provide basic implementations so that library's users don't have to build the whole library again from scratch, but I can't put the algorithms there or the users won't be able to use them for their own implementations.

Every time I add a new method, I end up changing its interface, and then every other implementation of that interface has to be updated - and not just mine, but everyone's.

A given algorithm often isn't just one method: there's initialisation and clean-up, adjusting parameters, intermediate results, and on and on. Each algorithm therefore introduces a cluster of methods and properties that relate tightly to each other, but only generally with the class as a whole, and hardly ever with other algorithms.

The solution is not to think of the Graph as something that does what the algorithm specifies, but instead think of the algorithm as a machine that works on graphs. Make the algorithm a class, instantiate it while passing the graph in via its constructor, adjust its settings, and start it running.

As long as the supplied graph implements the interface(s) the algorithm expects it to, all should be happy.