When to split a class [closed]

Question

Well i have the following class called "Architecture", this class have many methods (around 50 i think) the problem is code readability and many of those methods seems to belong on a different class.

So i created a "ArchitectureProcessor" class that include those methods and its a composition of "Architecture". Is this a good practice?

I mean i don`t want to have like 50 methods on a single class, it looks very messy, so i try to split every class the most i can and i often find this problem.

Answer 1

Your 50 method class is probably doing too much.

As has already been referred to in a comment, you should try to follow Single Responsibility Principle, which means that a class should only have one responsibility. If it has more than one responsibility, try breaking the class out into multiple classes based on their different responsibilities.

Single Responsibility Principle is part of a larger group of principles coined SOLID:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

All of these principles will help you stray away from similar code, and are a good guide for object oriented programming.

Answer 2

In my opinion it's not about the size of the class but rather the functionality you're grouping inside of it. In theory, a class of any size can still be a proper class.