OO and writing Drupal modules
Foreword: Yes, I read: http://drupal.org/node/547518
I am writing a module "foo" for Drupal6 where I organize OO style code.
There is a class called Foo that has a bunch of setters and accessories, and it works great when abstracting out some pretty nasty code and SQL.
The question is, is it a common practice to expose a class for other modules, or is it better to wrap things in the more typical foo_myfnname ()?
For example, if I am writing module docs, I have to tell people:
$foo = new Foo();
$something = $foo->get_something();
or ask them to call:
foo_get_something();
which is under the hood:
function foo_get_something() {
$foo = new Foo();
return $foo->get_something();
}
a source to share
It's hard to say and I don't think there is anything like "common practice" for that. Taking the ubiquitous views module as an example, hover over the wrapper of common API calls in "standard" functions, and leave the use of object (s) only for advanced stuff.
Personally, I would base the solution on the intended audience of the API. If you are reaching out to the "wide" Drupal user base, getting them to use Classes is probably (unfortunately / annoyingly) still a bit stretched out as many PHP users will often lack the correct OOP concept (heck, even "professional", PHP - developers often don't have it).
If, on the other hand, your target audience is only developers, then providing an appropriate level of OO "as is" should be okay and probably less confusing than the mix that otherwise leads (using views as an example, I often started out using one of the convenience wrapper functions, and found that I later rewrote quite some code just because I needed this little change that required using the object directly - it's better to be consistent and use objects from the beginning).
a source to share