How to create a modular application

I have an application that contains about 10 different components (chat, channel, profile, settings, etc.).

I need the ability to create multiple applications, each of which will have multiple components.

Example:

  • app1 - will have chat settings and a profile.
  • app2 - will have feed and settings.

How do I approach this?

I thought about creating each component as a library, and then for each application I need to build, just put the pieces together like puzzles.

Will it be right? Or does anyone have better suggestions?

thank

+3


source to share


2 answers


You can develop an "SDK" project (such as the Facebook SDK) that includes all the components (chat, channels, profiles, users, etc.) and you can use this "SDK" as a library in other projects ... Use whatever components you want for this particular application.



This approach will make the SDK project user-friendly and easily upgradeable. When you add a new feature (say, albums), you can integrate it into the SDK project and use it with your existing applications.

+4


source


This kind of extensible modular design is often quite useful for building larger software or software designed to address a wide range of unanticipated future needs, especially if you mix bottom-up approaches.

However, effective ways to approach this vary somewhat depending on the language and tools you use.

The awkward part is how to make the modules available to communicate with each other when needed, so that you can effectively bundle them together like lego blocks. This often becomes a practical need as the complexity of your software grows to the point where it is often not enough to simply have modules completely separated from each other like stuck islands and only one "master" module to communicate with all of them. Often times, your needs will grow to get them talking to each other.



For example, if you're using a dynamic scripting language like Python, then it's easy for each module to publish its own public interface, and you can start building modules by talking to each other with almost no effort.

If you are using a compiler and a statically typed language such as C or C ++, then it becomes much more difficult to make each module publish its own unique interface that is directly imported and used by others. There you are faced with the need to make the headers available to all modules, worry about preserving the ABI when making changes, etc. More changes will lose ABI and break other modules depending on the specific interface, so we tend to design the bit differently.

In such cases, you almost always want the software development kit to contain all the abstract interfaces. Then your modules implement those interfaces and still communicate with each other, albeit indirectly (plugin A talks to an SDK interface that communicates indirectly with another plugin, B). The SDK sets up a central communications headquarters, passing messages from one module to another.

0


source







All Articles