“CoderboyPB” m.stoepke@gmx.de schrieb:
Hallo!
Aua! Das ist ja Körperverletzung!
Wahrscheinlich hast Du das irgendwo abgeschrieben, sieht so nach typischem
eGroupWare Code aus.
1.) Problem
Wenn Du was neu machst, dann mach es doch gleich in PHP5. Das sind nur
minimale Änderungen und macht das Programmieren für Dich langfristig
einfacher.
class.bo_foomodul.inc.php:
<?php
include_once(EGW_INCLUDE_ROOT .
'/etemplate/inc/class.so_sql.inc.php');
class bo_foomodul extends so_sql
{
public function __constructor()
{
// calling the constructor of the extended bo object
// PHP4 => böse!!
$this->so_sql('foomodul','egw_foomodul');
$this->empty_on_write = "''";
}
}
?>
class.ui_foomodul.inc.php:
<?php
include_once(EGW_INCLUDE_ROOT .
'/foomodul/inc/class.bo_foomodul.inc.php');
class ui_foomodul extends bo_foomodul
{
public function __constructor()
{
// calling the constructor of the extended bo object
// PHP5 => gut!!
parent::__constructor();
}
public function show()
{
echo "foo";
}
}
?>
- Problem
Um es mal extrem zu verdeutlichen. Du könntest auch folgendes schreiben:
class ui_foomodul extends so_sql
Da die “bo” Klasse eh die “so” Klasse extended und die “ui” Klasse die "bo"
Klasse, kannst Du auf die “bo” Klasse einfach verzichten.
Die ui_foomodul::show Funktion macht es sehr deutlich. Nur um "foo"
auszugeben brauchst Du keine “bo” Klasse und erst recht keine “so” Klasse.
Außerdem kannst Du so aus der “ui” Klasse direkt auf protected Funktionen
der “so” Klasse zugreifen. Das ist nun wirklich extrem böse.
So werden die Schmerzen langsam weniger.
class.bo_foomodul.inc.php:
<?php
include_once(EGW_INCLUDE_ROOT .
'/etemplate/inc/class.so_sql.inc.php');
class bo_foomodul
{
protected $_soSql;
public function __constructor()
{
$this->_soSql = new
so_sql('foomodul','egw_foomodul');
$this->_soSql->empty_on_write = "''";
}
}
?>
class.ui_foomodul.inc.php:
<?php
include_once(EGW_INCLUDE_ROOT .
'/foomodul/inc/class.bo_foomodul.inc.php');
class ui_foomodul
{
protected $_boFoModul;
public function __constructor()
{
$this->_boFoModul = new bo_foomodul();
}
public function show()
{
echo "foo";
}
}
?>
Jetzt hast Du eine wirkliche Trennung der verschiedenen Funktionen(ui, bo
und so). Als nächstes sollte man sich überlegen, ob man die anderen Klassen
wirklich im Konstruktor instanzieren muss. Das hängt natürlich von der
Anwendung ab. Am besten ist es aber die Klassen erst dann zu instanzieren,
wenn man sie wirklich braucht.
Viel Spaß beim Programmieren!
–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg
eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our ideas for eGroupWare: http://www.tine20.org
E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324
Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german
