Taking OOP to far?

[Cardale]

I'm trying to create a OOP website, but I wanted to see if I was taking it to far.  I want to keep my core design the reusable code with very little actual data and then my functional side still using all of my classes that uses most of the data but doesn't actually display the data thats for the template class and basically the presentation.

 

So I'm thinking  classes or base functionality |  extended functionality or exact functions  |  display

 

Is this to much?  This is my first try and creating a class system. 

 

I've been reading this "book" http://hudzilla.org/phpwiki/index.php?title=Main_Page and its been helpful anyone recommend something else.

[Jenk]

It is impossible to go too far with OOP. Seriously, impossible.

 

Other languages are nothing but objects. No such thing as a function or primitive variable.

[Liquid Fire]

It is impossible to go too far with OOP. Seriously, impossible.

 

Other languages are nothing but objects. No such thing as a function or primitive variable.

 

I think that is taking OOP to far.  simple variables and function are still very useful.

[448191]

I have to agree with Jenk. There's no such thing as taking OOP too far. The definition of 'too far' is of course completely subjective. So this discussion is probably going nowhere.

[s0c0]

You take OOP too far when it makes it difficult for another programmer to jump in and start modifying your code.  I've seen developers try and turn PHP in Java.  PHP is far from Java and at some point you have to stop.  There is no need for gets and sets in PHP (okay I do use sets in objects), but there is absolutely no need for gets to simply get object data members.  Just instantiate the object and grab the data member for crying out loud. We use this method for designing OOP at my work.

 

Core object interacts with the database.  For instance we would have an object called C_User that interacts with the user table.  This objects job is to run queries and set object variables that is it.  So it's constructor would look like this:

function __construct($user_id='')
{
 	$dbConn = new C_DatabaseConnection();
	$this->db = $dbConn->music();

	if($user_id!='')
	{
		$sql = "SELECT * FROM users WHERE id='$user_id'";
		$result = mysqli_query($this->db, $sql);
		while($row = mysqli_fetch_array($result))
		{
			$this->username = $row[username];
			$this->email = $row[email];
			$this->status = $row[status];
			$this->directory = $row[directory];
			$this->traffic = $row[traffic];
			$this->user_id = $user_id;
		}
	}
}

 

The class might also contain a query like this:

 

	
public function getMusic()
{
	$sql = "SELECT * FROM mp3 WHERE users_id='$this->user_id'";
	return mysqli_query($this->db, $sql);
}

 

Notice I just return the query result.  Now I can just call this method, get the query result and do whatever I want with that in other objects and methods.

 

We then would have a T_User object which is used for displaying text to the screen.  So in a very ugly and simplistic form it would look something like this:

 

function __construct($user_id='')
{
	$this->user = new C_User($user_id);
}

public function returnMusic()
{
	$resultArr = $this->user->getMusic();
	while($row = mysqli_fetch_array($resultArr, MYSQL_ASSOC))
	{
		$retVal .= $row[song];
	}
	return $retVal;
}

 

We also have H objects (ie. H_User) which are used for one-off tasks that don't fit into the core object or the text object.  So you might have some number crunching functions in here or form validation in an H object.

This is the sanest way I've found of implementing OOP in PHP.

[448191]

There is no need for gets and sets in PHP (okay I do use sets in objects), but there is absolutely no need for gets to simply get object data members.  Just instantiate the object and grab the data member for crying out loud.

 

That is ludicrous.

 

Getters and setters are as needed in OOP PHP (5) as in any other language. You make getters and setters so an object's environment can still access and manipulate members, but under the conditions that you set (for example by use of type hinting). Declaring members public removes that control.

[dbo]

Yup. The reason for get and set methods is so that you can control (or at least suggest) best methods for using your objects. It is done to maintain the integrity of the object. You have to be very careful about giving direct access to your variables. I'd go as far as saying that even if you don't use type hinting and are using the limited OOP ability in PHP 4 you should use get/set methods.

[s0c0]

hmmm....

 

The rest of what I said is valid?

[Daniel0]

I agree with 448191 and Jenk as well.

 

It is impossible to go too far with OOP. Seriously, impossible.

 

Other languages are nothing but objects. No such thing as a function or primitive variable.

 

I think that is taking OOP to far.  simple variables and function are still very useful.

I take it you don't know Python or Ruby then? It is indeed very useful that everything is an object.

[dbo]

I don't necessarily even agree that "wrappering" simple functions in a class is even that bad. In some ways it can be redundant but consider this:

 

If you wrapper a mysql class around the mysql extensions and then your server upgrades and requires mysqli functions, you make the changes in a single location (the class) instead of 8000 instances inside of all your code. Some of it is about maintainability too.

[448191]

hmmm....

 

The rest of what I said is valid?

 

You mean the part where you said PHP is not Java and at some part you have to stop? Probably. I've been tempted to make classes for primitive types in PHP, but I'm thinking it's a little too expensive performance-wise. My definition of 'going too far' would be when the drawbacks start outweighing the benefits.

 

Anyone want to debate this, please do.

[Jenk]

Making objects from primitive types would probably be too far, yes. But when the rest of your application is well structured objects, you'll never need to actually use a primitive.

 

And the comment regarding OO making it difficult for other developers to jump in is not a valid point. Any OO experienced developer will tell you that jumping into legacy code (i.e. procedural) is a LOT more difficult.

[Liquid Fire]

Making objects from primitive types would probably be too far, yes. But when the rest of your application is well structured objects, you'll never need to actually use a primitive.

 

And the comment regarding OO making it difficult for other developers to jump in is not a valid point. Any OO experienced developer will tell you that jumping into legacy code (i.e. procedural) is a LOT more difficult.

On the first part, that is what i mean.

 

On the second part i kinda agree.  I was brought into a system written about 3 years ago the code was part perl and part php and just a mess all around.  We resting just had a company design a new system and they used a custom built API and in all honestly, the 3 year old code is a little bit easier to understand.  I mean that have done some stuff that just makes no sense like rewrite how the session works.  The rewrote the exception class(so that you can't use the default class).  I have no problem is writing your own stuff but the rewrite it so you can't use default php stuff is very bad.  They have somethings stored in the session that make no sense and that can't be changed.  For instance if there was an error, that error will stay in the session used it is manually cleared.  They also have a Item class that everything data object(object that gets data from the database) That has a store function that saves the object in the database but they don't declare it in the actually object class so i had to put user specific code inside the item class which is just poor. 

 

I think that OOP is a lot cleaner to read if it is properly written and has very good docs, else it can be just as hard as much older code.