4

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.

ffenix
  • 543
  • 1
  • 5
  • 22
  • 3
    There are alot of things that are "good practices" that could help you decide when you should separate classes. You could start with the Single Responsibility Principle (see this [Stack Overflow Question](http://stackoverflow.com/questions/7542051/learning-single-responsibility-principle-with-c-sharp)) – Simon Belanger Jun 30 '13 at 01:10
  • 1
    "Architecture" doesn't tell much about what the class is *doing*. Break it down by functionality, should help. Can you provide some code? – Mathieu Guindon Jun 30 '13 at 01:14

4 Answers4

10

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.

Community
  • 1
  • 1
Dan Teesdale
  • 1,823
  • 15
  • 26
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.

aw04
  • 10,857
  • 10
  • 56
  • 89
2

Don't split for the sake of splitting. You are only making the interface awkward - instead of architecture.Foo() you'll have to write architecture.Process.Foo() - it's not natural to stuff the Process identifier there...

If you have too many methods, maybe your class is trying to represent an whole hierarchy by itself? Assuming Architecture is about buildings, maybe it also tries to represent the floors of the building, so you have methods like RoomCountInFloor(int floorNumber). In that case, you should have a Floor class, and Architecture should contain a collection of floors, so you can write architecture.Floors[5].RoomCount - much better than architecture.Process.RoomCountInFloor(5), right?

Another possibility is that you are using too much service methods - and in that case you might want to put those service methods into service classes. In a Java project I did once, I had to use many service methods to manage all the temp files that one of my classes was using. Instead of adding those service methods to that class, I created a TempFileManager class to do that. That splitting forced me to add some more methods(encapsulation and all), but it's much more organized that way, and now if I ever need a similar temp file management in another project I can simply copy that class.

It is also possible that you do need 50 methods to handle whatever Architecture represents directly, but having all those methods in one big file is too messy. In that case, you should consider using C#'s partial class feature.

Idan Arye
  • 12,402
  • 5
  • 49
  • 68
0

It is time to split a class as soon as it has more than one responsibility.

  • Your reading class starts to write, split.
  • Your logic class starts to update user interface, split.
WhoaItsAFactorial
  • 3,538
  • 4
  • 28
  • 45