Are these good uses of OOP

[php-phan]

So i have been working with PHP forever (well 2 years or so lol) and i just recently started working with OOP. It isnt to hard but just a little confusing, this is how I have been implementing it..

So i created a class called Brain. It holds the functions used for accessing the database (like select, delete, getNumRows etc..) it also has some functions for changing the dateTime from the database into readable dates (January 1st, 2010). Thats what Brain does.

Then I have another class called conversations which extends brain (almost all my classes extend brain because they all use those basic functions), and it get and displays messages from the database...

So does this seem like i am implementing OOP correctly? Do you have any suggestions

[planetsim]

This is the code critique forum to critique actual code. This is probably better suited in the coding forum. However without code to go off and only your explaination Id say its not a bad attempt.

A few pointers though.

1) Naming convention is pretty poor. If I was a programmer coming to read your code to modify something, Brain wouldn't mean a class for Databases. I suggest give meaningful names to your classes e.g. Database

2) Brain could potentially be split up into creating a Driver class e.g. MySQL than use Brain to reference this class so you could in future add another Driver if need be without much hassle. The idea is basically classes should be small and about a specific Object.

3) Conversations I prefer not to have a plurals for class names, but this is my preference. What does the class do exactly besides get messages. Is it getting it from a particular table e.g. Conversation ?

[Weedpacket]

As planetsim notes, it's hard to do code critique when there is no code to critique.

php-phan wrote:

it also has some functions for...

...suggests that those functions should be in another class.

almost all my classes extend brain because they all use those basic functions

It's not necessary to extend a class to use its methods; and it's typically not even desirable. An alternative is for each class that wants to use a Brain (names are important) store one in a member variable. This makes it easier to mix and match individual components.

[php-phan]

Thanks you guys. Well 'conversation' (not plural) was called inbox but i think it did more than just the display the inbox. So basically conversation right now is getting the messages, displaying the messages, send replies, (eventually it will also create new messages and delete messages). I am just a little worried that maybe there should be a class called inbox that deals with getting the messages and then another class that will deal with sending, deleting, and other stuff. Or should there even be a class that gets and displays messages? Maybe gets the message but does there really need to be a class method that 'displays' (return html).

Oh and sorry this is in the wrong forum...lol I guess its more of a concept issue.

[Weedpacket]

A class should concentrate on doing one thing.

[NogDog]

If you try to break things down into objects from the high-level modeling viewpoint, you might consider that you would have a "message" object for each message, an "inbox" object for each collection of messages received by a given user, an "outbox" object for messages sent by a given user, and then a "message_sender" object for sending messages from one user to another. Since the "inbox" and "outbox" objects probably have a lot of overlap in functionality, they might each extend a "message_box" abstract class.

I'm not necessarily saying that is the way I would do it (though it might well be), but it should give you an idea about thinking "objectively" and trying to narrowly confine the functionality of each class/object. Such decisions made up front can also help you make similar decisions about your database design in order to help implement your application design (and vice versa, too).

[rulian]

IMO OOP does require a bit more extra effort to work with, but that is exactly the point of it, it forces you to examine your organization and logic before you even get down to writing code which in turn makes you produce better quality code faster.

But much like in procedural coding, organizing and planning is what will make or break you program, the code itself is the easy part.

[Bjom]

concept or not....just post your brain class code plus the conversations class code.

You'll get much more out of it that way.