1

I need to develop a small CMS using PHP, and right now I'm trying to figure out the structure.

The CMS will be generated using a set of functions. Things like database functions, caching thingies, internationalization and stuff like this.

I was thinking to do it like this:

  • make the functions non-static methods part of a big "site" class; that way I could run multiple instances of that class. Not sure I would need to do that though..

  • or split the functions into separate classes with static methods

The main problem here is that the CMS should be able to manage multiple small sites, not just one. So either I make all methods static and add a "site switch" function, or make them normal objects which I instantiate based on the site which I want to manage

Which of these would be the best option?

ellabeauty
  • 2,529
  • 3
  • 21
  • 25
  • Never make a monolithic "all in one" class. It's bad practice for various reasons. Have a look at [this question of mine](http://stackoverflow.com/questions/9556899/database-class-design) for more regarding the implementation of classes. – Bojangles Mar 05 '12 at 01:09
  • 1
    Is it a brand new project? If so, why do not use some kind of MVC framework, the most of them works just well as you before mentioned in your question. – devasia2112 Mar 05 '12 at 01:13
  • 1
    *"Which of these would be the best option?"* is difficult to answer without a full-blown discussion of software engineering. However, I'd say this: often, **static is evil**. [Here's a PHP-based explanation of why](http://kore-nordmann.de/blog/0103_static_considered_harmful.html) and here's [another with a terrific metaphor that isn't targeted towards PHP development](http://www.daedtech.com/static-methods-time-to-hit-rock-bottom). I would strongly recommend avoiding static in favor of dependency injection. If you want to upgrade yourself, work through it on your own. If not, try a framework. –  Mar 05 '12 at 02:01

2 Answers2

10

Static methods are generally bad practice. They introduce a lot of potential issues.

1) They introduce hidden dependencies. Code which arbitrarily calls foo::bar() has a dependency on foo and cannot run without foo being defined. The object using foo::bar() will construct correctly but won't be usable if foo is not defined.

2) Statics are globals. Global state is very bad, anything can change the code and its state is unknown. You sacrifice the power and control achieved by OOP encapsulation by using static methods.

3) It's impossible to substitute the functions for a different version

4) It makes unit testing impossible.

For more detailed information and code examples, see this article and this article

Tom B
  • 2,735
  • 2
  • 24
  • 30
  • Since `foo::bar()` is a global state, and its almost as `foo_bar()`...Then its impossible to avoid global state? Take for example built-in procedural functions - `array_push()`, `array_rand()` etc. So if I use `array_push()` somewhere in a method, then it introduces global state too? – Yang Jul 23 '13 at 22:29
  • Those are technically static leaf methods, which are addressed by Misko Hevery in the second link: "a static leaf method is a slippery slope which is waiting to grow and become a problem. Static methods are procedural! ... And as far as Math.abs(-5) goes, ... I really want to write -5.abs()". Inbuilt functions are less problematic because they cannot change over time and they don't suffer the issue of hidden dependencies (they will always be available) although they're all impossible to substitute during testing-you must test the static method along with the method you are trying to test. – Tom B Jul 24 '13 at 22:54
1

I'd definitely suggest using static classes for this job. Going this route will create a pseudo namespace for all of your functions so you don't have to worry about conflicting function names, etc, and it also prevents you from having to pass around an instance of your helper class just to call one of your helper functions.

Jeff
  • 6,643
  • 3
  • 25
  • 35