Code Review 13 PrivateClass for Splitting up Large Classes - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki

I have a (C#) 1000-line class called CustomComponent in 1 file and I would like to split the code into multiple files (not using partial classes).

Here is an approach I've been thinking of.

1. Extract all private fields into a class called PrivateCustomComponent and have the CustomComponent class use it with the _private field.
2. Replace all instances of those private _field usages with _private.Field.
3. Categorize each class method, and put them in separate files (e.g. render-related methods goes in a PrivateCustomComponentRender class with constructor PrivateCustomComponentRender(customComponent, privateCustomComponent)).
4. In the PrivateCustomComponent constructor, build all of these "sub-classes".

You’re still keeping:

• One giant state object
• Full cross-access between everything
• Implicit coupling between sub-classes

This leads to:

A distributed god object.

You didn't reduce responsibility — you just moved it.

Instead of:

1 god class

You now have:

1 god state object
+ 5 god method buckets

Everything still depends on everything.

The real question isn’t:

“How do I split this into files?”

It’s:

“How do I split responsibilities?”

That’s a design problem, not a file problem.

Instead of grouping by method type, group by responsibility.

Example responsibilities:

• Rendering
• State management
• Event handling
• Validation
• Data transformation
• DOM interaction
• API communication

Each one becomes a real object.

Before (God Class)

class CustomComponent
{
    private List<Item> _items;
    private bool _isLoading;

    public void Render() { }
    public void AttachEvents() { }
    public void Validate() { }
    public void LoadData() { }
}

class CustomComponent
{
    private readonly ComponentState _state;
    private readonly ComponentRenderer _renderer;
    private readonly ComponentEvents _events;

    public CustomComponent()
    {
        _state = new ComponentState();
        _renderer = new ComponentRenderer(_state);
        _events = new ComponentEvents(_state, _renderer);
    }

    public void Init()
    {
        _renderer.Render();
        _events.Attach();
    }
}

Each class:

• Has a focused job
• Has limited dependencies
• Can be tested in isolation

State is explicit. Dependencies are explicit. No hidden god container.

This pattern maps 1:1 to JS:

class CustomComponent {
    constructor() {
        this.state = new ComponentState();
        this.renderer = new ComponentRenderer(this.state);
        this.events = new ComponentEvents(this.state, this.renderer);
    }
}

Your approach works if:

• You're just organizing files
• The class already has a clear single responsibility
• You're mainly trying to reduce file size

But if the class is large because it does too much, that approach won't fix the architecture.