A big Utility or separate into different pieces?
I am writing an application, which will a few programmers involve in. We come up with some problems when managing source code. We usually have a Utility.php, which share among different users. So, we make a big utility.php , and everyone is calling this...
But we find a problem...When we want to separate the project, for example, we have font end of CMS, and back end. When we want to separate the existing project, we need to separate the big utility.php into places, or copy once or sync between others. So, we are considering, use different small utilities, which only use in the related class. Any suggestions??
Current: FontEnd.php is calling --> Utility.php BackEnd.php is calling ---> Utility.php
Considering: FontEnd.php is calling --> StyleUtility.php, ClientUtility.php, bababa BackEnd.php is calling ---> DBUtility.php, M开发者_C百科aintainUtility.php , ababba
You should never put yourself in a situation where you have GOD classes or modules (those that do every job under the sun).
They should do one thing and one thing well - this is the single responsibility principle. If you have a single module that does database calls and user interface layouts, you've done it wrong.
The rule you should follow is to maximise cohesion and minimise coupling.
Maximum cohesion means that everything in a single module should be heavily related to each other (such as all database interfacing in a single module, all file I/O in another and all statistical function in yet another).
Minimal coupling means there should be no unnecessary dependencies between classes. There should be a very well defined API for the database module and there should be no way of doing database stuff that bypasses that API.
In other words (for example), lumping together compression and window management functions in a single module is a bad idea. By all means have a compression utility module and an window management module but don't put them together.
精彩评论