OO and Writing Drupal Modules

Preface: Yes, I've read: http://drupal.org/node/547518

I am writing 'foo' module for Drupal6, where I am organizing the code in an OO fashion.

There's a class called Foo that has a bunch of setters and accessors, and it is working quite well at abstracting some pretty nasty code and SQL.

The question is is it 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 the module's docs, should I tell people to do this:

$foo = new Foo();
$something = $foo->get_something();

or tell them to call:

foo_get_something();

which under the hood does:

function foo_get_something() {
  $foo =开发者_运维百科 new Foo();
  return $foo->get_something();
}

Difficult to say, and I don't think there is something like a 'common practice' for this. Taking the ubiquitous views module as an example hints on wrapping common API calls in 'standard' functions, and leaving the usage of the object(s) for advanced stuff only.

Personally I'd base the decision on the intended API audience. If you're addressing the 'broad' Drupal user base, forcing them to use Classes is probably (unfortunately/annoyingly) still a bit stretching, as many part time PHP users will have no proper concept of OOP (heck, even 'professional' PHP devs often don't have it).

If on the other side your intended audience consists of developers only, providing a proper OO layer 'as is' should be ok, and probably less confusing than the mixture that results otherwise (using views as an example again, I often started using one of the convenience wrapper functions, and found myself rewriting quite some code later on just because I needed this tiny little change that required direct object usage - better to be consistent and use objects from the beginning).