Does "dividing more things into separate classes" really means better design in SE?

[larrywang0701]

(If this qustion is irrelvent to the course, please tell me and then I'll close it and leave the forum space to others who need help, thanks)

Hello professors and classmates. From my prior project experiences, I believe that making more classes in my OOP framework will make the overall framework more flexible, modularized and easy to expand, maintaince and use. But one day when I was in high school, my teacher told me that not all programs needs such amount of divided classes and such large framework since designing the framework itself is also time-costly and too-large framework may also be bad. This is totally differ from what I previously believed. So I'm curious about the answer to this question. Does "dividing everything into separate classes" really a good practice in SE? Thanks!

[jianrong7]

Just like everything in software engineering, I believe there are tradeoffs to making your code "more OOP". OOP definitely brings a lot of benefits in terms of modularization and flexibility of your code.

However, I do think it does comes at the expense of moving quickly. You will often find yourself going back to old code that is working but needing to refactor them to make it follow OOP. So, it does come with some overhead.

Nevertheless, I believe as software engineers, our job is to be able to discern that and balance what is the right amount of "division" is needed.

Just my opinion! 😸

[ARPspoofing]

Hello, I think this question is very relevant to the course so please do not worry.

I personally believe any SE project of decent size will need to split them into classes so that different swe can work independently without having conflicts. I guess this module forces us to do have classes for iP because for the tP, the codebase is huge and merging everything into a single file will be almost impractical. Even if we merge everything to a single file, it will be very hard to develop and make changes efficiently.

So, I think for most brownfield projects, splitting into classes is necessary!

[nixonwidjaja]

I think for SE courses where modularization and readability is emphasized, we do need to separate into different classes, especially if the codebase is huge. It branches from one class one responsibility principle.

[woojiahao]

I think the main idea is to have a logical separation of concerns and to not create new classes for the sake of creating a class. This goes back to what the problem is. Let's say you are trying to implement a builder pattern, out of necessity, a secondary (usually nested) Builder class is needed. This is a logical separation of work since you need this Builder class for you to be able to properly implement the pattern. An instance where creating a class for the sake of creating a class is going to be redundant is in cases where you have a single utility method used in a single location but you try abstracting it out into a "utility" class just because you can. In those scenarios, I would just leave the utility method in the class it is used since it's not going to ever be used outside.

Besides the "need" concern, I think a bigger component of modularity is the ability to have finer unit testing. Larger modules/classes imply that you have a lot more surface area to cover for a unit test. This is not a bad thing per-se but being able to modularize the code means that you decouple long dependency chains so that each unit test covers exactly one component and does not have to overextend its testing. One very good example is the Parser class in iP where having a separate class means you can individually test parse() without having to worry about setting up the file storage or making sure the bot is running.

For most web frameworks (think Gin for Go, Spring Boot for Java, Phoenix for Elixir), it is not uncommon to see a high level of modularity when building out a single endpoint. Usually you have a router to handle the web routes, then you have a controller to handle the HTTP request, and then a set of models that the controller uses, and finally a data layer that connects with the database. This modularity, while verbose and tedious at times, gives a very clear flow of what goes where and the roles each class/module plays. Even in desktop applications, you might see architectures like the Model-View-Controller (MVC) where you already have three layers of modularity.

Tl;dr: dividing into multiple classes is a double edged sword, it gives clear visibility and responsibility to each file which makes testing a lot easier but overdoing it because you can is bound to make the code more unreadable and harder to navigate

[KamJiaYue]

It all depends on how flexibility. Creating more classes doesn't imply better OOP, in my humble opinion. But wisely creating classes, then yes, better OOP indeed.