Polymorphism and Coupling

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
User avatar
TheMoose
Forum Contributor
Posts: 351
Joined: Tue May 23, 2006 10:42 am

Polymorphism and Coupling

Post by TheMoose »

Not sure how to word the title, mainly because I don't know what to call this other than loose coupling and trying to polymorph something.

I have a DB interface as well as a wrapper (for specific Db engines), let's start with MySQL.

First off is a code question: can I return an "interface" as an object and within the specific DB result wrapper, as long as it implements the functions still use that result?
IE, does the following work:

Code: Select all

public class MySQL implements DBConnection
	public function query($sql) {
		return new DBResult(mysql_query($sql));
	}
}
.....
public interface DBResult {
	public function __construct($queryResource);
}
public class MySQL_DBResult implements DBResult {
}
Second is a theory question: Do I need to? Since I'm already in the MySQL wrapper, can I just hard couple the Connection to the Result class since they use the same protocol and engine to handle the work? Should I just couple it to MySQL_DBResult instead of the generic DBResult?
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Yes you can and yes you should.
Back after dinner.
User avatar
TheMoose
Forum Contributor
Posts: 351
Joined: Tue May 23, 2006 10:42 am

Post by TheMoose »

ole wrote:Yes you can and yes you should.
Back after dinner.
Ok good, I'm on the right track then :)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

OK presumably you are making the main database API object polymorphic so you can change your database without having to change the API calls as well. This makes sense. I've done similar. With a concrete result object you are only getting half the benefit (assuming you use result objects as much as the main API object).
User avatar
TheMoose
Forum Contributor
Posts: 351
Joined: Tue May 23, 2006 10:42 am

Post by TheMoose »

ole wrote:OK presumably you are making the main database API object polymorphic so you can change your database without having to change the API calls as well. This makes sense. I've done similar. With a concrete result object you are only getting half the benefit (assuming you use result objects as much as the main API object).
Yes. I have a DB interface and then specific DB server implementations (ie MySQL, Postgre, etc). Then I have a result interface, and db specific result implementations. I only partially understand your last comment of the benefits. I understand why it would be better to have a single result object to handle all the DB results, but I don't understand how I could go about implementing that in an efficient manner without checking the DB type each time and basing actions off of it. It seems more logical to wrap those into separate pieces so that the MySQL portion handles MySQL results, while Postgre portion handles Postgre results, and so on and so forth.

This is my first large project that I'm trying to use patterns for, instead of my typical OO hard couple style, so go easy ;)
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Post by Mordred »

Code: Select all

return new DBResult(mysql_query($sql));
should be

Code: Select all

return new MySQL_DBResult(mysql_query($sql));

Each specific DBConnection returns its specific kind of DBResult. You may think of the DBConnection as a factory for DBResult-s.

I dunno what you intend to do with this, but I hope you know what you're doing ;)
Post Reply