Classes without instances

[Thomas Mlynarczyk]

Hi,

In many cases, one needs only a single instance of a class in a script.
Since PHP5 offers class variables like MyClass::$myVar and even class
constants, it seems to me that an instantiation is not needed. Is it
therefore okay and good practise to use a class without instantiation? In
that case I could regard such a class as a collection of functions and
variables that belong together in a way and the prefixed class name could
serve as a kind of namespace identifier:

include "myLib.php"
myLib::$somevar = 'some value';
myLib::somefunc( myLib::MY_CONSTANT );

Another question: In PHP4 I can have

class myLib { function myFunc() { /* do stuff */ } }
myLib::myFunc();

In PHP5, there is the "static" keyword. What exactly is the difference
between

class myLib { public static function myFunc() { /* do stuff */ } }
class myLib { public function myFunc() { /* do stuff */ } }

Greetings,
Thomas

[Meião]

> In PHP5, there is the "static" keyword. What exactly is the difference

between

class myLib { public static function myFunc() { /* do stuff */ } }
class myLib { public function myFunc() { /* do stuff */ } }

in this first case the function myFunc() will be available without
instantiation.
then you can call
myLib::myFunc()
second case you can't

In PHP 4 it didn't matter, you could always (?) call a function
staticly
which may lead to strange results (maybe the function used a variable
which hasn't been initialized).
Now in PHP 5 we have static

Meião

[Dikkie Dik]

Thomas Mlynarczyk wrote:

Hi,

In many cases, one needs only a single instance of a class in a script.
Since PHP5 offers class variables like MyClass::$myVar and even class
constants, it seems to me that an instantiation is not needed. Is it
therefore okay and good practise to use a class without instantiation? In
that case I could regard such a class as a collection of functions and
variables that belong together in a way and the prefixed class name could
serve as a kind of namespace identifier

It is good practice if the instance would have no state. You'd only have
functions then. The standard example is the Math class in Java and
JavaScript, which is a collection of mathematical functions.

If the object has a state, it is better to use an instance of a class.
Lots of classes have one instance or almost-always one instance. The
backend database, for example. Although I did change database types in
the past and was glad that I could use more than one instance of a
database. There is nothing wrong with classes that are instantiated only
once. There is even nothing wrong with a class that only has an instance
for a really short time.

I don't like it, but if you want to _enforce_ the fact that there is
only one instance, google for "singleton pattern".

Best regards

[Thomas Mlynarczyk]

Also sprach Dikkie Dik:

[Using a class without instantiation]

It is good practice if the instance would have no state. You'd only
have functions then. The standard example is the Math class in Java
and JavaScript, which is a collection of mathematical functions.
If the object has a state, it is better to use an instance of a class.
Why would it be bad practise with a state? I mean, data structure,
encapsulation etc. is done as well as with an instance. Where's the drawback
then? Certainly, one may argue that in the future the need for having
several instances may arise, but assuming that I can definitely exclude such
a possibility in a given situation?
I don't like it, but if you want to _enforce_ the fact that there is
only one instance, google for "singleton pattern".

I've read about it in the PHP manual. But if the class itself is able to
provide the same functionality that an instance would, why bother with even
one single instance?

Greetings,
Thomas

[Thomas Mlynarczyk]

Also sprach Meião:

class myLib { public static function myFunc() { /* do stuff */ } }
class myLib { public function myFunc() { /* do stuff */ } }

in this first case the function myFunc() will be available without
instantiation. then you can call myLib::myFunc()
second case you can't
In PHP 4 it didn't matter, you could always (?) call a function
staticly

So it's just that PHP5 is more strict about certain things.

Thanks,
Thomas

[Weird-beard]

Thomas,

In object oriented programming, everything should be an object.
Therefore, you may need classes that only has functions that just do
the job and does not need an instance. Therefore, only static
functioned classes could be used to do that. In oop, you do not just
print_r() or smth on its own. It should be an object's method, an
object responsible for that kind of job. So, you need the static
functions when you code such a class. The class can be abstract,
meaning that it cannot be used to create an instance, ou can just use
the abstract functions or of course inherit from it.

Furthermore, the class need not to be all static functioned, just a few
of the functions could be static. For example, you are going to create
an instance but that object needs to know, at creation time, some
attribute or smth. in that case, for good oop practice, you should not
use an external function, and if just the mentioned class is going to
use the static function, you should preserve the code in the mentioned
class.

Such discussions are into oop and once you begin to go completely OOP,
you will see the advantages, though it may be seeming ridiculous now.

Php4 was not OO, and being able to use a function as you mentioned may
not seem like a problem in the beginning, but once you begin using
other people's classes or using your classes a while later, you may not
be able to determine if a function was designed to run without
instantiation or not. Thats a problem for oop, as you have to know alot
about the class you are about to use, that harms the encapsulation.

So, it is of great importance for the class to use the function as it
was designed to be used like, as the reverse would steal your precious
time, making you try to understand what is going on by looking at the
code.

[Weird-beard]

there are situations that you must have an instance, an instance in
which you can fiddle with class variables. In static functions, you
cannot change the class variables, as the variables are kept inside the
instance but you dont have one. And the reason for using singleton is,
if you need the variable setting but you do not need the object more
than once and/or the class is expensive to maintain in terms of memory.
Singleton helps here. (See factory pattern, for example. Factories can
be driven by static methods too, if you do not need any variable
settings inside the class.)

[Thomas Mlynarczyk]

Also sprach Weird-beard:

there are situations that you must have an instance, an instance in
which you can fiddle with class variables. In static functions, you
cannot change the class variables,

But in PHP5 I can have static class variables and I can access those with
static functions - or have I misunderstood the manual?

[Thomas Mlynarczyk]

Also sprach Weird-beard:

In object oriented programming, everything should be an object.
So the "perfect" OO-Script would consist on the global level of only class
definitions, maybe some constant definitions or global configuration
variables and one simple instantiation statement at the end which would (via
the constructor function) start the actual processing?

Might I not encounter a situation where a function is of a "global" nature,
meaning that it is needed by several objects and cannot really be associated
with any existing class? Should I create a new class with a single element -
that function - then?
Such discussions are into oop and once you begin to go completely OOP,
you will see the advantages, though it may be seeming ridiculous now.
I'm all in favor of OOP, but IMHO there *are* situations where a non-OOP
approach is more appropriate.
Php4 was not OO, and being able to use a function as you mentioned may
not seem like a problem in the beginning, but once you begin using
other people's classes or using your classes a while later, you may
not be able to determine if a function was designed to run without
instantiation or not.

As there would/should have to be some documentation about the code, this
detail ought to be mentioned there or could be communicated by typographical
conventions like

Class to be instantiated: name starts with a capital letter
Class not to be instantiated: name starts with a lowercase letter

By the way: are there some good articles on the net which discuss such
issues in more detail? Detailed advice on good coding practise is not
available in the manual.

Greetings,
Thomas

[Oli Filth]

Thomas Mlynarczyk said the following on 20/11/2005 10:53:

Also sprach Weird-beard:

there are situations that you must have an instance, an instance in
which you can fiddle with class variables. In static functions, you
cannot change the class variables,

But in PHP5 I can have static class variables and I can access those with
static functions - or have I misunderstood the manual?

There are indeed static class variables.

However, semantically, static variables imply variables that represent
the state of the class as a whole, not one particular instance of it.

An example of a good use of static variables might be instance counting;
i.e. every time an instance of a class is constructed, the constructor
increments a static variable. Every time an instance is destructed, the
destructor decrements the static variable. If the count reaches zero,
some other processing might occur, e.g. close a shared DB connection.

So yes, static variables and functions will do the same job as a single
instantiation, but it would really be using the wrong tool for the job.
Part of the paradigm of good OOP is making your code a semantic
representation of your data structure (that's the whole reason behind
public, protected, private, for example).

Another problem is that whilst you can pass a class instance around
(i.e. function arguments, return variables, and serialisation), you
cannot "pass" a class. You can fudge it by passing the class name as a
string and using eval() or some-such silliness, but then your code
really starts looking messy and hacky.
--
Oli

[Weird-beard]

So the "perfect" OO-Script would consist on the global level of only
class
definitions, maybe some constant definitions or global configuration
variables and one simple instantiation statement at the end which would
(via
the constructor function) start the actual processing?

- The appropriate word is could consist on. Depending on your
requirements. You dont always need such stuff.

Might I not encounter a situation where a function is of a "global"
nature,
meaning that it is needed by several objects and cannot really be
associated
with any existing class? Should I create a new class with a single
element -
that function - then?

- You wont need a global natured function, think about it. All you need
is global classes, residing on your toolbox. String is an object on
full oo languages.
By the way: are there some good articles on the net which discuss such
issues in more detail? Detailed advice on good coding practise is not
available in the manual.

- OO php is getting better. But, I dont think it is currently geared
towards people developing only php, as you will not be able to find
many references on oo php. Oo is not a new concept, nor it is just an
issue of php. Php started to use it, for users who had already been
developing oo programs, as the software developers needed it. If you
would like to learn more about oop, you can look at any language.
dotnet, c++, java (especially java). The concepts are the same,
sometimes the names differ. (Although I would not recommend getting
into Microsoft references, as most of them are a waste of time, as they
are geared towards only dotnet architecture and usage). Good coding
practice is not the word, the word is good object oriented design or
architecture. Good coding practice is naming functions passing
parameters etc. OOdesign is more.