Class vs Module - When classes are needed to be in module?

Question

I am developing an application that has a lot of options like local database CRUD operations, file IO, web APIs calling, notifications, user preference settings, services, widgets etc.

At start it seemed no problem to work with classes, now reaching 50% app completion, I see 20+ classes in my app (all code documented/formatted). I tend to make classes where necessary, using my OO knowledge to full extent. I create classes where I need a template, helper class or utility class etc. I saw someone talking about creating modules in Android app, where functionality is divided and other modules are consumed in app module making code more managed and readable.

My question is, on what facts or basis should I consider moving to modules instead of keep making classes?

One answer would be "where functionality differs", but yes it is obvious. Are there any sdlc practices or coding patterns that provides us a methodology that when to break code in classes and when to move the set of classes (or set of functionality) to an entire new module?

Answer 1

Classes and modules are not trade-offs, you do not choose one over the other, they serve different purposes. A class helps you model your application logically and serves you while you are developing. A module is an output file of your build, used to "physically" split up your system into separate parts. It serves deployment and life cycle management.

If you are the only developer doing a desktop application, their is no need to use modules. If your design is distributed by nature (say, a service serving a number of users using client applications), there is no way around modules. If you are big on testing, it may be convenient to create modules you can test separately.

Modules typically serve a practical purpose after you deliver. Classes serve no one but you, the developer. They help you map the world into software.

Edit: A common reason for isolating classes in a module is a many-to-one dependency relationship. If general purpose code is isolated in a module, the module may be shared by an array of higher level modules (like different applications). Apart from saving a few bytes, this helps in keeping dependencies straight. It also allows you to fix or break multiple applications at once.