PHP5 Singlton vs. Abstract Classes

[Daedalus.OS]

Ok first I'm pretty new to OOP, so my question may sound stupid to some of
you. If the only answer you can provide is "get a book about OOP" then don't
loose your time and mine cause it's already ordered. I'm just too curious
about this one to wait for the book.

I would like to know is if it's good php programming practice to use
abstract classes instead of singleton classes. For exemple a login class.
I've made one as an abstract class and now I'm wondering if it's a good
idea. Technically there would be only one login object so I thought having
this object was pointless and I use an abstract class with everything in it
static. Is it a good or a bad idea and why? In what situation the difference
between having only one object and no object at all with only static
functions and variables would lead to use one more the other? Or why in a
PHP context would I prefer to have a single object rather than what I would
call a "static virtual object".


Thanks,
Dae

[Dikkie Dik]

Re: PHP5 Singlton vs. Abstract Classes

Daedalus.OS wrote:[color=blue]
> Ok first I'm pretty new to OOP, so my question may sound stupid to some of
> you. If the only answer you can provide is "get a book about OOP" then don't
> loose your time and mine cause it's already ordered. I'm just too curious
> about this one to wait for the book.
>
> I would like to know is if it's good php programming practice to use
> abstract classes instead of singleton classes.[/color]

Abstract classes are classes of which no object can be instantiated.
Normally, this is because there is some method left undefined
(abstract). The meaning of an abstract class is to be a superclass, so a
class extending from the abstract class can implement what was left
undefined. This probably sounds very vague, so let me give you an example.
Suppose you wantr to support more than one database. You could define an
abstract class called AbstractQuery with a SqlToArray method, that takes
a string and returns the result of the query as an array. SQL _can_ be
database independent and arrays are database independent as well, so
this class could be useful. You could define the method SqlToArray as
abstract, and create a few more classes: MysqlQuery, OdbcQuery,
FirefoxQuery, or whatever database you want to support. These classes
all extends from the AbstractQuery and implement the database-dependent
stuff. You could have done this also with an interface, as an interface
is a purely abstract class.

A static class is a class with only static methods. The best example
from it is the Math class in java. Static classes are stateless: they
have no data that can distinguish one instance from the other. You login
class probably _will_ have a state (LoginSucceeded , for instance), so
this is not a very good option.

Singletons are the global variables of OO programming. I don't like
them. There is nothing wrong with a class that happens to be the
definition of just one object.

Gotta go now, more later.
[color=blue]
>... For exemple a login class.
> I've made one as an abstract class and now I'm wondering if it's a good
> idea. Technically there would be only one login object so I thought having
> this object was pointless and I use an abstract class with everything in it
> static. Is it a good or a bad idea and why? In what situation the difference
> between having only one object and no object at all with only static
> functions and variables would lead to use one more the other? Or why in a
> PHP context would I prefer to have a single object rather than what I would
> call a "static virtual object".
>
>
> Thanks,
> Dae
>
>[/color]

[Mark Twain]

Re: PHP5 Singlton vs. Abstract Classes

In article <uM_7f.48280$yS 6.27532@clgrps1 2>,
"Daedalus.O S" <ng@nxstream.ne t> wrote:
[color=blue]
> Ok first I'm pretty new to OOP, so my question may sound stupid to some of
> you. If the only answer you can provide is "get a book about OOP" then don't
> loose your time and mine cause it's already ordered. I'm just too curious
> about this one to wait for the book.
>
> I would like to know is if it's good php programming practice to use
> abstract classes instead of singleton classes. For exemple a login class.
> I've made one as an abstract class and now I'm wondering if it's a good
> idea. Technically there would be only one login object so I thought having
> this object was pointless and I use an abstract class with everything in it
> static. Is it a good or a bad idea and why? In what situation the difference
> between having only one object and no object at all with only static
> functions and variables would lead to use one more the other? Or why in a
> PHP context would I prefer to have a single object rather than what I would
> call a "static virtual object".
>
>
> Thanks,
> Dae[/color]

Part of the point of creating an abstract class is so that you can use
it in other projects. So while you may only have one login object, you
might wind up down the road (if you are lucky) with a hundred clients
who all need projects with one login object.

And then comes a day when you get a project where you need five login
objects, and you suddenly become glad you wrote the class.

It's a cost-benefit thing: you have to weigh the time you spend on
overhead against the projected savings in the future, which can
sometimes be a bit difficult.

mt

[Dikkie Dik]

Re: PHP5 Singlton vs. Abstract Classes

More about singletons:

A singleton is a static class that has an accessor for exactly one
instance of the class. This is then the only instance that can be
created. There are a few drawbacks to this:
- If you ever need more than one object of that kind, you have a
problem. And if you write unit tests, you do have to create another
instance just for the test. Singletons are a real pain to test and don't
scale at all.
- The instance is not passed via the interface (= the publicly available
methods) of the class. Effectively, a singleton is a global read-only
variable that is set automatically. If you want to replace it (for
testing, for instance), you again have a problem.
The fact that the singleton is not passed through the interface
"hardwires" it to any place in the code where it is used. This obscures
the class dependencies in the code.

So where would I put the instance if I don't want a singleton? On a
small php page I could just use a plain non-object oriented variable. On
more complex applications, I have an object structure with some root
object that contains the data that is accessible within that section.
This root object is responsible for this data (either by checking the
input parameters of its constructor or by creating the necessary
instances itself).

Best regards

Daedalus.OS wrote:[color=blue]
> Ok first I'm pretty new to OOP, so my question may sound stupid to some of
> you. If the only answer you can provide is "get a book about OOP" then don't
> loose your time and mine cause it's already ordered. I'm just too curious
> about this one to wait for the book.
>
> I would like to know is if it's good php programming practice to use
> abstract classes instead of singleton classes. For exemple a login class.
> I've made one as an abstract class and now I'm wondering if it's a good
> idea. Technically there would be only one login object so I thought having
> this object was pointless and I use an abstract class with everything in it
> static. Is it a good or a bad idea and why? In what situation the difference
> between having only one object and no object at all with only static
> functions and variables would lead to use one more the other? Or why in a
> PHP context would I prefer to have a single object rather than what I would
> call a "static virtual object".
>
>
> Thanks,
> Dae
>
>[/color]

[steve]

Re: PHP5 Singlton vs. Abstract Classes

ok...two thumbs down so far for singletons...on ly one citing specifics.
singletons are *great* in my opinion. you just know how, when, and where to
use them.

the example of using a global variable/function/class to achieve a
work-in-place-of a singleton is a false notion. while you may achieve the
same or desired effect(s), you cannot enforce the same scope as a singleton
without a lot of programming (and praying that another developer on your
team doesn't much things up...and understands what you're doing...to which
end he'd simply say "shit, why didn't this idiot just create a singleton and
be done with it!").

and the notion of being pigeon-holed into not scaling is, likewise, a farse.
singletons do what they are designed to do. if you had other intentions from
the beginning, then design you system differently...e lse if the requirements
change, exactly how much work does it take to convert a singleton into a
multi-instancing class?

you may want to wait for your book to arrive before assuming either of the
above reasons make singletons "bad".

[steve]

Re: PHP5 Singlton vs. Abstract Classes

oh, and one example...singl etons that simply hold constants...lea ving a
clean name-spaced definition of what they are associated with.


"steve" <a@bc.com> wrote in message news:LI98f.2033 6$RG4.7109@fe05 .lga...
| ok...two thumbs down so far for singletons...on ly one citing specifics.
| singletons are *great* in my opinion. you just know how, when, and where
to
| use them.
|
| the example of using a global variable/function/class to achieve a
| work-in-place-of a singleton is a false notion. while you may achieve the
| same or desired effect(s), you cannot enforce the same scope as a
singleton
| without a lot of programming (and praying that another developer on your
| team doesn't much things up...and understands what you're doing...to which
| end he'd simply say "shit, why didn't this idiot just create a singleton
and
| be done with it!").
|
| and the notion of being pigeon-holed into not scaling is, likewise, a
farse.
| singletons do what they are designed to do. if you had other intentions
from
| the beginning, then design you system differently...e lse if the
requirements
| change, exactly how much work does it take to convert a singleton into a
| multi-instancing class?
|
| you may want to wait for your book to arrive before assuming either of the
| above reasons make singletons "bad".
|
|

[Daedalus.OS]

Re: PHP5 Singlton vs. Abstract Classes

And even with, for example, the Math class (static class), would the right
way to go would be to create a normal class with static funtions and a
private constructor (since there can be no instance of that class) rather
than using an abstract class with static functions ?

If I get things right, abstract classes are pretty much like interfaces (at
least in PHP). The difference being that interfaces only declare functions
that need to be defined in the "child" classes and abstract classes can
declare functions (abstract functions) and/or define functions. It probably
not represents the whole picture but am I heading in the right direction ?

Thanks Dae
[color=blue]
> Abstract classes are classes of which no object can be instantiated.
> Normally, this is because there is some method left undefined (abstract).
> The meaning of an abstract class is to be a superclass, so a class
> extending from the abstract class can implement what was left undefined.
> This probably sounds very vague, so let me give you an example.
> Suppose you wantr to support more than one database. You could define an
> abstract class called AbstractQuery with a SqlToArray method, that takes a
> string and returns the result of the query as an array. SQL _can_ be
> database independent and arrays are database independent as well, so this
> class could be useful. You could define the method SqlToArray as abstract,
> and create a few more classes: MysqlQuery, OdbcQuery, FirefoxQuery, or
> whatever database you want to support. These classes all extends from the
> AbstractQuery and implement the database-dependent stuff. You could have
> done this also with an interface, as an interface is a purely abstract
> class.
>
> A static class is a class with only static methods. The best example from
> it is the Math class in java. Static classes are stateless: they have no
> data that can distinguish one instance from the other. You login class
> probably _will_ have a state (LoginSucceeded , for instance), so this is
> not a very good option.
>
> Singletons are the global variables of OO programming. I don't like them.
> There is nothing wrong with a class that happens to be the definition of
> just one object.
>
> Gotta go now, more later.
>[color=green]
>>... For exemple a login class. I've made one as an abstract class and now
>>I'm wondering if it's a good idea. Technically there would be only one
>>login object so I thought having this object was pointless and I use an
>>abstract class with everything in it static. Is it a good or a bad idea
>>and why? In what situation the difference between having only one object
>>and no object at all with only static functions and variables would lead
>>to use one more the other? Or why in a PHP context would I prefer to have
>>a single object rather than what I would call a "static virtual object".
>>
>>
>> Thanks,
>> Dae[/color][/color]

[Dikkie Dik]

Re: PHP5 Singlton vs. Abstract Classes

Daedalus.OS wrote:[color=blue]
> And even with, for example, the Math class (static class), would the right
> way to go would be to create a normal class with static funtions and a
> private constructor (since there can be no instance of that class) rather
> than using an abstract class with static functions ?[/color]

The PHP help does not say anything about private constructors. I guess
it is a java thing to make them private to disallow instantiation. If
you think about it, it is quite odd. The constructor is never called
directly, but it is a language construction. You give a "new" keyword,
some space in memory is reserved, the class name is attached to it as a
type, and its constructor is called. By whom? By the virtual machine
itself, basically. Making it private is _really_ odd. As the object is
still unreferenced, _no_ object can call it (the reference is only
returned when the constructor has finished). Even the object itself
cannot call it, as it is still in the process of coming to existence.
It is not very consequent either. "private" in java means "visible only
within the same instance". Only for constructors it suddenly means
"visible within the same class".
Declaring it abstract will certainly stop instantiation. However,
"abstract", communicates that it is meant as a superclass. I would not
create a constructor at all and not declare it abstract either. As the
static operator differs from the normal method calling, it is clear
enough that instantiation is pointless. Any instance does not have
properties or methods that can be called on it.
[color=blue]
>
> If I get things right, abstract classes are pretty much like interfaces (at
> least in PHP). The difference being that interfaces only declare functions
> that need to be defined in the "child" classes and abstract classes can
> declare functions (abstract functions) and/or define functions. It probably
> not represents the whole picture but am I heading in the right direction ?[/color]

Yes you are. An abstract class can have some implementation, for
instance as a default implementation for its subclasses. Often, abstract
classes are more general and its subclasses more specific. If the
general stuff is defined in the abstract superclass, the subclasses only
have to fill in the details.
The "problem" with abstract classes is that you can extend only one
abstract class, whereas you can implement more than one interface.

[Oli Filth]

Re: PHP5 Singlton vs. Abstract Classes

Dikkie Dik said the following on 27/10/2005 23:20:[color=blue]
> Daedalus.OS wrote:
>[color=green]
>> And even with, for example, the Math class (static class), would the
>> right way to go would be to create a normal class with static
>> funtions and a private constructor (since there can be no instance of
>> that class) rather than using an abstract class with static functions ?[/color]
>
>
> The PHP help does not say anything about private constructors. I guess
> it is a java thing to make them private to disallow instantiation.[/color]

Not just a Java thing.

[color=blue]
> If you think about it, it is quite odd. The constructor is never called
> directly, but it is a language construction. You give a "new" keyword,
> some space in memory is reserved, the class name is attached to it as a
> type, and its constructor is called. By whom? By the virtual machine
> itself, basically.[/color]
[color=blue]
> Making it private is _really_ odd.[/color]

Actually, it's a *very* common design pattern in many OO languages.

[color=blue]
> It is not very consequent either. "private" in java means "visible only
> within the same instance". Only for constructors it suddenly means
> "visible within the same class".[/color]

Not true. "Private" means visible within the same class, e.g.:

class Foo
{
private $v;

function bar($theFoo)
{
echo $theFoo->$v;
}
}

$a = new Foo;
$b = new Foo;
$b->bar($a);

The equivalent works in Java, C++ and C#.

[color=blue]
> Declaring it abstract will certainly stop instantiation. However,
> "abstract", communicates that it is meant as a superclass. I would not
> create a constructor at all and not declare it abstract either. As the
> static operator differs from the normal method calling, it is clear
> enough that instantiation is pointless. Any instance does not have
> properties or methods that can be called on it.[/color]

One of the ideas of writing good OO code is to explicitly enforce a
well-defined interface on your classes' users, i.e. what they can and
can't do with it. If you don't want them to be able to instantiate a
Foo, enforce it with a private constructor, don't leave it to chance.

Another example would be, if it makes no semantic sense for a Foo to
ever be extended, explicitly say so with the "final" keyword.



--
Oli

[www.douglassdavis.com]

Re: PHP5 Singlton vs. Abstract Classes


Daedalus.OS wrote:[color=blue]
> Ok first I'm pretty new to OOP, so my question may sound stupid to some of
> you. If the only answer you can provide is "get a book about OOP" then don't
> loose your time and mine cause it's already ordered. I'm just too curious
> about this one to wait for the book.
>
> I would like to know is if it's good php programming practice to use
> abstract classes instead of singleton classes. For exemple a login class.
> I've made one as an abstract class and now I'm wondering if it's a good
> idea. Technically there would be only one login object so I thought having
> this object was pointless and I use an abstract class with everything in it
> static. Is it a good or a bad idea and why? In what situation the difference
> between having only one object and no object at all with only static
> functions and variables would lead to use one more the other? Or why in a
> PHP context would I prefer to have a single object rather than what I would
> call a "static virtual object".[/color]

some very general hints about OO:

abstract classes and singleton classes are for totally different
reasons.

if you want to create a class where you can't create a new object
(instantiate), make it final and make the constructor private. usually
this is with classes that have all static members. If you just make it
abstract, some one could extend it, then still instantiate one.

if you want to create a partial class, that can be extended to do many
different things, make an abstract class.

if you want to create something similar to functions, with no objects
attached use static methods.

if you want to create a variable similar to a non OO variable , or one
that is global in scope, use a static variable.

if you are sure you only need something like old-style functions:

login(name, password)
logout();

go with all static methods, make impossible to instantiate (as i
mentioned above). nothing really wrong with that.

if you want to have more OO functionality (inheritance, passing object
into a function, methods having some shared data (instance vars), go
with the singleton. Or if you think you will have more OO
functionality in the future, go with the singleton, because it will be
hard to recode once you make everything all static.

don't create a class with a bunch of static vars that are changed by
and used by static methods. it is misleading. people will think of
those methods more just like regular non OO functions (like cos() or
sqr() ). when actually, you are treating them as an object

[Oli Filth]

Re: PHP5 Singlton vs. Abstract Classes

Oli Filth said the following on 28/10/2005 01:26:[color=blue]
>
> class Foo
> {
> private $v;
>
> function bar($theFoo)
> {
> echo $theFoo->$v;[/color]
^
Oops. "$v" should be "v" here.[color=blue]
> }
> }
>
> $a = new Foo;
> $b = new Foo;
> $b->bar($a);
>[/color]


--
Oli

[Jerry Stuckle]

Re: PHP5 Singlton vs. Abstract Classes

Dikkie Dik wrote:[color=blue]
> Daedalus.OS wrote:
>
>
>
> The PHP help does not say anything about private constructors. I guess
> it is a java thing to make them private to disallow instantiation. If
> you think about it, it is quite odd. The constructor is never called
> directly, but it is a language construction. You give a "new" keyword,
> some space in memory is reserved, the class name is attached to it as a
> type, and its constructor is called. By whom? By the virtual machine
> itself, basically. Making it private is _really_ odd. As the object is
> still unreferenced, _no_ object can call it (the reference is only
> returned when the constructor has finished). Even the object itself
> cannot call it, as it is still in the process of coming to existence.
> It is not very consequent either. "private" in java means "visible only
> within the same instance". Only for constructors it suddenly means
> "visible within the same class".
> Declaring it abstract will certainly stop instantiation. However,
> "abstract", communicates that it is meant as a superclass. I would not
> create a constructor at all and not declare it abstract either. As the
> static operator differs from the normal method calling, it is clear
> enough that instantiation is pointless. Any instance does not have
> properties or methods that can be called on it.
>[/color]

Actually, it's not uncommon to have *some* constructors be private. If
all of them are private, you can only instantiate the class through a
static function.

But for instance - it's not unusual in C++ to have a copy constructor be
private. It means the following code will fail:

MyClass a; // Default constructor
MyClass b = a; // Copy constructor - fails if it is private



--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Daedalus.OS]

Re: PHP5 Singlton vs. Abstract Classes

Well that's exactly where I took this idea from, some article about Design
Patterns.

I got really interesting answers and it help me a lot... I got my books now
but I will certainly have some questions about OOP in the future.

Thanks to all of you.

Dae

[color=blue][color=green]
>> If you think about it, it is quite odd. The constructor is never called
>> directly, but it is a language construction. You give a "new" keyword,
>> some space in memory is reserved, the class name is attached to it as a
>> type, and its constructor is called. By whom? By the virtual machine
>> itself, basically.[/color]
>[color=green]
>> Making it private is _really_ odd.[/color]
>
> Actually, it's a *very* common design pattern in many OO languages.
>[color=green]
>> It is not very consequent either. "private" in java means "visible only
>> within the same instance". Only for constructors it suddenly means
>> "visible within the same class".[/color]
>
> Not true. "Private" means visible within the same class, e.g.:
>
> class Foo
> {
> private $v;
>
> function bar($theFoo)
> {
> echo $theFoo->$v;
> }
> }
>
> $a = new Foo;
> $b = new Foo;
> $b->bar($a);
>
> The equivalent works in Java, C++ and C#.
>
>[color=green]
>> Declaring it abstract will certainly stop instantiation. However,
>> "abstract", communicates that it is meant as a superclass. I would not
>> create a constructor at all and not declare it abstract either. As the
>> static operator differs from the normal method calling, it is clear
>> enough that instantiation is pointless. Any instance does not have
>> properties or methods that can be called on it.[/color]
>
> One of the ideas of writing good OO code is to explicitly enforce a
> well-defined interface on your classes' users, i.e. what they can and
> can't do with it. If you don't want them to be able to instantiate a Foo,
> enforce it with a private constructor, don't leave it to chance.
>
> Another example would be, if it makes no semantic sense for a Foo to ever
> be extended, explicitly say so with the "final" keyword.
>
>
>
> --
> Oli[/color]