Hi Tomas,

I think Singletons are definetly the State of the Art method to implement this functionality.

Improvements compared to inherited methods from "god class":

+ no methods where they shouldn't be ($oOrder->isAdmin() <- makes no sense)
+ free "namespaces" for method names and therefore:
+ intuitive interface $oOrder->getUser() should user which made the order

Could you explain why your decision did go "pro" oxSuperCfg?


Tomas Liubinas wrote:
Hi Christopeher,

This oxSuperCfg() is a result of long internal discussions. Personally I
would agree that the way it is implemented now is not perfect, and
sometimes as you say could be avoided at all. In most cases you could
use singelton getInstance() instead of dynamic (non static?)
->getConfig(). However one could argue should we use singeltons at all?

Regards
Tomas Liubinas

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Christopher Simon
Sent: Friday, August 14, 2009 12:35 PM
To: [email protected]
Subject: [oxid-dev-general] oxSuperCfg

Hi,

nearly every class is a child of oxSuperCfg.

It can be confusing anyway. Here is a example:

<snip>
$oOrder = oxNew('oxorder');

$oOrder->load($oxid); // just for example, imagine that we have
retrieved the orders oxid from somewhere

$orderUser = $oOrder->getUser();
</snip>

What is returned by getUser()?

It's not the user which made the order - like a lot of people would
expect - its the active user.

Which makes no sense on this object.

In general, all methods in oxSuperCfg are completly redundant:

- getConfig(): returns result of singleton oxConfig::getInstance()

- getSession(): returns result of oxSession::getInstance()

- getUser(): returns oxUser::loadActiveUser which could be implemented
as static method on user object

- isAdmin(): the result is defined as global function in oxfunctions,
and it's a config parameter named "blAdmin" anyway.

the unit test functionality of these methods could be implemented in
this singletons or static functions. there is no need to have
oxSuperCfg, also because it's no "cfg" or "config" anyway.

In addition, not every object needs those methods, but every object has
those methods, at the moment.
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

Reply via email to