1

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?

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.

  • Correct me if I am wrong, so there is no standard to tell me when classes become modules as mr. @Robert Harvey said, What I understand that this decision is based completely on One's knowledge and software development experience, when to keep working in classes and when to create modules for that purpose. – Talha Aug 24 '16 at 10:15
  • 1
    Classes do not ever become modules, classes may be grouped into modules. If you do not feel the need for modules, don't worry about them. It is easy to split up your project into modules later if the need ever arises. Creating the right classes from the start is important though. This comes down to good system analysis. Choosing a way to chop up your project into modules comes down to context (how responsibilities are distributed in your team, what your clients demand regarding version control, which parts of your system you want to sell separately, deployment scenarios, et cetera). – Martin Maat Aug 24 '16 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.