Is it a bad idea to put each class method in its own file? [closed]

Question

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?

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."