Posted by 4sak3n 0ne on 09/04/07 21:28

On Sep 4, 2:14 pm, Marijn <marijn.huizendv...@gmail.com> wrote:
> On Sep 4, 4:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
>
>
> > ELINTPimp wrote:
> > > On Sep 4, 2:40 am, Marijn <marijn.huizendv...@gmail.com> wrote:
> > >> Hi there,
>
> > >> Again a question with no simple yes or no answer at least, opinions
> > >> will probably be scattered so no unanimous yes or no answer ;)
>
> > >> What would you think is the best of the following to options given
> > >> that it is more likely that the databaseConnection is set?
>
> > >> SomeClass {
>
> > >> [.............]
>
> > >> /**
> > >> * Sets the connection to the database in use.
> > >> *
> > >> * @return DatabaseFactory
> > >> */
> > >> private function __getDatabaseConnection(){
> > >> if (isset($this->__databaseConnection)) {
> > >> return($this->__databaseConnection);
> > >> } else {
> > >> $this->__databaseConnection = new DatabaseFactory();
> > >> $this->__databaseConnection->create();
> > >> return($this->__databaseConnection);
> > >> };
> > >> }
>
> > >> }
>
> > >> Or
>
> > >> SomeClass {
>
> > >> [.............]
>
> > >> /**
> > >> * Sets the connection to the database in use.
> > >> *
> > >> * @return DatabaseFactory
> > >> */
> > >> private function __getDatabaseConnection(){
> > >> if (!$this->__databaseConnection) {
> > >> $this->__databaseConnection = new DatabaseFactory();
> > >> };
> > >> return($this->__databaseConnection);
> > >> }
>
> > >> }
>
> > >> The second option definitely has less repetitive code but does that
> > >> really make it the better option given the fact that the
> > >> databaseConnection property is probably set?
>
> > >> By the way, another small convention question: Should you terminate
> > >> control structures with a semicolon?
>
> > >> Thanks
>
> > >> Marijn
>
> > >>From looking at your code, it looks like you intend to put this
> > > connection function in all of your classes that need to talk to the
> > > database. Your code looks like it wants a singleton pattern.
>
> > > You're on the right path with your code, but why not abstract that
> > > logic to a class of its own (I assume mysql):
>
> > > class db {
> > > static private $_instance;
> > > public $connection;
>
> > > private __construct () {
> > > //do database initiation, such as loading config data and the like
> > > $this->connection = mysql_connect(...);
> > > //exception handling
> > > mysql_select_db($schema, $this->connection);
> > > //exception handling
> > > }
>
> > > public static function getInstance() {
> > > if (is_null(self::$_instance)) {
> > > self::$_instance = new db();
> > > }
> > > return self::$_instance;
> > > }
> > > } // end db class
>
> > > now, in your other classes, you simply type:
>
> > > class someClass {
>
> > > public function someMethod() {
> > > //just putting this in a generic method, but you could put it in
> > > the constructor, if you wish
> > > $db = db::getInstance();
> > > //and you connection handle is $db->connection
> > > }
>
> > > A lot less code in your classes, and a bit easier to understand in my
> > > opinion. Also has the advantages of encapsulation to the db
> > > connection so you can do fun things like centralizing exception
> > > handling and/or create some generic functions to handle your query
> > > formats, etc.
>
> > I do something very similar in my classes, and find it easier to use.
>
> > However, there is a whole design concept around the Factory class, and
> > some people prefer it. It helps when you need to pass parameters to the
> > Factory, for instance, before actually creating the object.
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================
>
> Just returned from the office, boy did this get of topic ;)
>
> First My DatabaseFactory returns a singleton of a MySQL class (later
> on i can easily support other databases if i would prefer). I am
> thinking of making the DatabaseFactory itself a Singleton so that the
> Singleton logic does not need to be repeated in every database
> implementation.
>
> The reason why i have this function is that it is used in an abstract
> class for implementation of database objects in php. By extending the
> abstract class i easily can create a implementation of the database
> data with it's own methods. But i don't want to create the database
> connection before actualy using it.
>
> To solve the problem I will move my connection of the database from
> the database constructor to another function. The database resource
> can be created and only if a query method is called it will check if
> it is connected. If not connected connect else connect and query.
>
> Still i feel like people misunderstood my first question: What is
> better:
>
> if ($mostLikelyValue) {
> break;
> } else {
> performSomeAction();
> }
> theRequiredAction();
>
> OR
>
> if (!mostLikelyValue) {
> performSomeAction();
> }
> theRequiredAction();
>
> Where in my opinion the second one is more readable and the first one
> probably faster (?)
>
> On the naming conventions regarding access types:
>
> OK say i will go for my own path of naming variables, properties and
> parameters and there access type. Is that really more straightforward?
> I would rather have seen reserved normal function names for methods
> like __call() and __get and the
> no underscore for public, one underscore for protected and two
> underscores for private (or some other distinguishing character).
>
> Is there really no commonly used way (accept for the one that bluntly
> ignores protected)
>
> I really do like the way everybody mixes in and gets involved in a
> good way in these types of discussions. Thanks for that, love to hear
> more from you guys.

I don't think that there is a performance increase one way or
another. In this case, I would say shorter is better.

[Back to original message]