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?

Talha
  • 153
  • 7
  • 1
    [Class vs package vs module vs component vs container vs service vs platform in Java world](http://stackoverflow.com/q/13157377/102937) – Robert Harvey Aug 23 '16 at 06:12
  • Possible duplicate of [How should one modularly implement related objects?](http://programmers.stackexchange.com/questions/287655/how-should-one-modularly-implement-related-objects) – gnat Aug 23 '16 at 06:14
  • @RobertHarvey It **defines** what classes and modules are, my question is about _on what fact we design modules instead of classes_. – Talha Aug 23 '16 at 06:29
  • @gnat Apologies, cant find my answer there, hardly the title only matches with this post, whereas if you read the answer, the discussion is in completely different perspective - game programming, which is bound to be as complex as it can be. – Talha Aug 23 '16 at 08:51
  • Kindly read this question, then read whole discussion which you are planning to mark duplicate. It is not relevant, nor has same scope or answers. – Talha Aug 23 '16 at 08:55
  • `It defines what classes and modules are, my question is about on what fact we design modules instead of classes.` -- Actually, that's exactly what is asked at the question I linked. When this happens, it means that you either don't need it yet (modules), or you need to go learn something else for awhile. There's no standard, governing body or authority that's going to tell you when it is time to put your classes into a module; when your applications get big enough where you will need them, you will know. – Robert Harvey Aug 23 '16 at 14:33
  • `There's no standard, governing body or authority that's going to tell you when it is time to put your classes into a module.` , this is what I was looking for. – Talha Aug 24 '16 at 10:09

1 Answers1

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.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • 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