Why use more than one or a few files for a computer application?

Short answer: separation of concerns.

Suppose you have two applications, one that shows weather information, and another one that shows stock updates. Seemingly, they have nothing to do with one another, so you put them in separate files. After all, you really don’t want weather code in between your stock updates code.

Some of this code can be shared. You could put that code in a shared library. So far, so good.

But what happens if you find that some code from the weather application could actually be used for the stock updates? For example, code to execute a web service client request. You’d have to remove that code from the one weather file, and put it in the library. And that library would become very large as time progresses, with functions that new applications may not need.

If you keep everything in a single file, inevitably these will become unmaintainable balls of yarn, with duplicated code, and other such niceties. They will be difficult to unit test, and you’ll forget what code sits where, and what it all does. You’ll have duplicated code, and a bug fixed in one place, remains unsolved in another.

So that’s why it’s a best practice to organise functionality in a way that similar functions sit together, so that webclient.php deals with web service clients, instead of this being lost somewhere in weather.php.

Leave a Comment