We have an existing project that has grown very messy and confusing; our classes are huge and difficult to read.

Our boss wants us to break all of our methods out of the classes and into separate files (for maintainability), so that it would be something like this.

class Foo {

    public function bar()
        include 'Foo/Bar.php';

    public function baz()
        include 'Foo/Baz.php';
class Bar {

    public function foo()
        include 'Bar/Foo.php';

We have about 1000 methods that will be broken out into separate files and then included into their respective classes; so basically 1000 additional included files.

Breaking apart classes and putting their methods into separate files is not something that I would do, and I've looked around to see if anyone else is doing this but I'm not getting good search results, which makes me think this is not something many people are doing. But I could be wrong!

I've done some testing and of course this many includes will affect I/O, but how badly? Especially if using a cache?

Using this approach, what are your thoughts and concerns? Do you foresee any problems happening in regards to using $this?

  • 3
    This is positively insane. I... I just... really? That's the proposed solution? May 25, 2021 at 21:59
  • Which version of PHP are you using? May 25, 2021 at 22:03
  • Not an exact duplicate, but fixing this the right way would be covered in this question: I've inherited 200K lines of spaghetti code — what now?. May 25, 2021 at 22:10
  • @GregBurghardt I think it's 7.4 but I'm not sure. Haven't been able to look at the server yet.
    – Tim
    May 25, 2021 at 22:31
  • You're basically fixing the problem that the classes are huge and difficult to read by making them huge and impossible to read because all the important stuff is splattered around a gazillion files. The fix is not to hide the code away but to … you know … fix the code. May 25, 2021 at 22:52

1 Answer 1


It seems like a super bad idea, but include does do this exact thing.

I would say its a very "procedural" way of thinking, you're assembling code like it's a single page which is going to run from top to bottom. Perhaps that kind of approach is how you ended up with your current problem?

Obviously its impossible to know without seeing the actual codebase, but maybe a middle ground approach might be acceptable.

Split the classes up, but group several related methods rather than putting each in its own file. That way you are working towards new smaller classes rather than towards what would seem to amount to many functions with global state, almost the definition of "spaghetti code."


Not the answer you're looking for? Browse other questions tagged or ask your own question.