In order to better organize my code in a PHP project (a simple CMS) I’m considering moving most of my System functions to an abstract class as static members. Aside from the organizational and syntactical benefit from it, the only other reason would be to store references to datasource objects, etc., as static members also.
Rules are made to be broken when necessary, but I want to solidify my understanding of better (read best) patterns and practices.
I suppose this question is open ended, but I was wondering if anyone had suggestions, or could perhaps suggest some reading material, so I could explore my options and what would be considered ‘best practices’.
An example of this in my code would be functions for managing permissions. For any given request, permission checks may be necessary to ensure the requesting user has sufficient privileges for the operation. So functions such as getAllPermissions(), getGroupPermissions(), addGroupPermissions(), etc., are floating around. Should these be encapsulated within a PermissionsManager class, necessary to instantiate, and if so, where do I stop? Am I on the right track moving them to a pseudo-global space within an abstract class as static methods? Should I just leave the declarations in global scope? Where do appropriate class responsibilities end and ‘god-class’ takeovers begin? What color socks should I wear?
I just can’t seem to wrap my head around this, and it’s slowing my productivity. I don’t want to idle any longer on modeling, because despite it’s obvious benefits, I’ve certainly destroyed a few trees sketching out object-interaction diagrams. And my wastebasket is full.
Have a look at SOLID and GRASP and this answer of mine: Php design patterns
Yes. If these functions are related, group them. Also have a look at this Wikipedia Article about Role-Based Access Control Lists and have a look at the various questions about ACLs in PHP on StackOverflow.
No, you should avoid static if possible. Statics lead to tight coupling and introduce dependencies on the global scope leading to less maintainable applications which leads to a longer time to deliver (e.g. bugfixes and new features) which leads to higher overall cost and less return of investment.
If you do changes to your application, you should be able to explain the benefit. If you think your application can benefit from refactoring this code, then refactor it. You should stop when there is no return of investment.
Since you should stick to the single responsibility principle, any responsibility beyond one is a code smell (though sometimes it may make sense to have more than one). I found this description of a GodClass easy to comprehend.
That depends on the shoes you intend to wear with them. In general, I find dark socks to be the best choice for most occasions and shoes, while white socks are a No-Go most of time.
Some thinking before you start is good. Understanding the problem and the domain you want to solve, is necessary to make decisions. But you should start with solving the problem eventually. Only working code (even poorly designed one) yields business value. Pristine up-front designs wont survive the reality of a project anyway.