Page 1 of 1

Polymorphism and Coupling

Posted: Thu May 31, 2007 12:45 pm
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?

Posted: Thu May 31, 2007 1:00 pm
by Ollie Saunders
Yes you can and yes you should.
Back after dinner.

Posted: Thu May 31, 2007 1:11 pm
by TheMoose
ole wrote:Yes you can and yes you should.
Back after dinner.
Ok good, I'm on the right track then :)

Posted: Thu May 31, 2007 1:36 pm
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).

Posted: Thu May 31, 2007 2:24 pm
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 ;)

Posted: Thu May 31, 2007 4:31 pm
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 ;)