Static Classes

[Acs]

Is there any problem with using static classes? I am trying to create a simple CMS and I use static classes extensively.

I use autoload so it's easy to call immediately a class method without having to create an instance of a class!

 

Is there any benefits in having instances of classes over having them all just being static??

 

[dbo]

I can't speak directly for static class in PHP as I've never created them, but if it's anything like static classes in other languages, it's a lot like a global variable. My understanding is that globals and statics are initialized before rendering the page where as your typical variable is not instantiated until it is needed or declared. Inherently having a lot of globals and statics can potentially create a lot of overhead, it's also can be a real pain to debug issues related to statics/globals because of their wholelistic scope.

[Acs]

Well since I use the autoload function it only get's included when I call a method of a static class.

[dbo]

I'm not sure that that's how it works. If it's not yet included (autoload function) you may be right, but in other languages it reserves that memory regardless if it is used.

[Acs]

Ok.. Anyone know about this issue?

[rhodesa]

Are you talking about classes with all static methods? As far as I know, there is no such thing as a 'static class'. I don't see any harm in it, as it is just a way of having organized functions. Just be wary of the auto-loading as it is not on by default for most servers. If you want to keep your code portable, you may want to avoid the auto-loading.

[Acs]

Yes yes I mean a class with all it's methods static!

What do you mean by "auto-loading is not own by default" ???? Isn't this just a function called __autoload that we just have to include in the script and that function will be called every time I try to call a class that has not been loaded??

[trq]

Just be wary of the auto-loading as it is not on by default for most servers. If you want to keep your code portable, you may want to avoid the auto-loading.

 

What exactly do you mean? __autoload is avaliable in php5, which is the current version.

[rhodesa]

Sorry, I was thinking of something else....

[448191]

<Picks up rake and lights torch>

 

Yeah! Autoload rules!

[Acs]

Indeed it does, and that's why I am using class's with just static methods. But someone in a php channel said that I shouldn't do that and just use singleton classes! I asked him why and he didn't respond.

 

Can anyone tell me it in fact I should use singleton classes?

[448191]

The thing is, you rarely need classes with only static methods, if ever. Basically a class with only static methods is more procedural than it is object orientated. Not necessarily at fault, and still better than using just functions, but rarely really that useful.

 

Of the estimated 80 or so classes in my own framework, only one is fully static, and I haven't used it in months. To be honest, I even forgot is was there, and I'll do away with it after I decide where the behaviour belongs.

 

However, I don't see how a Singleton would be the answer to your problems (whatever they are). Singletons seem really cool, especially when you're relatively new to OOP, but in the end they tend to cause more more problems than they solve, especially when overused.

[Acs]

Maybe it my fault for not really understanding OOP but I just don't see how these class's would be better if they were not static.

Sometimes I just need some methods of some classes and so it's better if I don't have to do something like:

 

$bla = new bla();

$bla->method();

 

It's alot simpler to just do bla::method();

 

 

[448191]

I try not to use the word 'better', let's say 'preferred' instead (same thing, really).

 

A fully static class, with static class members and all, has a number of disadvantages, most of which are directly related to design. First off, encapsulation goes pretty much down the drain. If you have a stateful class, clients need a reference to the instance to have access to the data it contains. Dependencies on the data are thus transparent and easier to reduce, making it easier to debug, maintain, extend and understand your application. This has it's root in the same issues as the general heuristic that 'global data is bad'. A Singleton does not negate this, since the data (and behaviour) is still globally accessible.

 

Secondly, the behaviour of an object can be easily changed at runtime. To achieve a similar effect with a fully static or procedural example (same thing, really) would require coding every possible combination of behaviour. Many base (GoF) patterns are about this changing of behaviour at runtime and reducing repeated logic. This makes it possible to easily encapsulate specific behaviour and make one part of your application dependant only on the interface of another. Changes to one part do not necessarily ripple into other parts, as long as the interface stays the same.

 

This really roots in the core of object orientated programming and design, covering subjects like 'coding to interface', polymorphism, and 'favor composition (or aggregation) over inheritance'. Hence I only touched the surface in this post and I'm out of time.

[Acs]

So you are talking about the magic method and overloading. Indeed this is a good thing but in most cases I just don't need this, except maybe in my database class. But it's hard to implement this I would have to create an instance of the class and when I wanted to use it I would have to make something like Global $sqlClass;

[448191]

You missed my point completely. I don't have allusions being able to explain it to you either.

[Acs]

Wow... thanks a lot for this reply

[448191]

Thanks for being sarcastic.

 

You didn't really read the explanation I gave you in the first place. If you did, you wouldn't suggest making global instances.

 

If you're not interested in the answer, don't ask the question.

 

No hard feelings though.

[Acs]

Maybe if you would give some links where they didn't just "touched the surface" I might have understood better your post.

 

I did read the answer and maybe I just didn't understand it fully, there is no reason for you to say: "I don't have allusions being able to explain it to you either."

 

I don't appreciate being called stupid, don't want to help or don't know how to explain in a manner that someone else understands, please just don't say anything

 

Thanks

[dbo]

I have to agree with 448191 on this one. I believe I made a comment about global variables and what not yesterday as well. I pretty much decided that you had it in your head what you wanted to do and were looking for validation more than wanting any real feedback.

 

To me it comes down to doing things in a way that is generally understood and accepted. If you want to write your code this way and you're the only one maintaining it, more power to you. But if you want to do it in a way that is easier to understand (readable), and maintainable then you should follow best practices.

[448191]

I am not calling you stupid, I'm saying you didn't read. If you don't read, I can't explain, simple as that.

 

If you need clarification, ask for it. If you think I'm wrong, say so. Hell, if you just want to call me an ass for posting what you believe to be crap, your loss.

 

There is no way I could ever fully explain OO to anyone in a single post. Properly explaining it takes a whole bookshelf worth of books written by real guru's, I'm only a novice by those standards.

 

As for the links you want, there are quite a number on this topic in the sticky in this board. Which also happens to have a link in my signature. Though to really understand you need to read some books, starting with the one I mentioned in my post - the GoF book.

 

 

 

[Xeoncross]

 

lol

 

page[1] was useful.

page[2] sucks.