preface
Componentalization and modularization have been deeply reflected in software development, but also for developers to better solve the software of high coupling, low cohesion, no reuse of the three big code problems. There are a lot of introduction articles on the Internet, and each author has his own ideas or summary, which is quite messy. There are also many doubts in the practice process. In many cases, I don’t know whether to choose components or modules, or sometimes I don’t know whether it is a component or a module. Therefore, I wrote this article to give a detailed explanation of componentization, modularization and plug-in, hoping that all partners can better understand the differences between the three.
Single engineering mode
Before introducing componentization, modularization and plug-in, we have to say the single Project mode. At the beginning of mobile development, we developed mobile projects, and I believe most of them used the single Project and single task development mode. New Project — > subcontract — > Write. You’ve all been through this process, and it’s easy to write, it doesn’t involve messy processing, it’s fast, it’s fast, it’s agile. This is because the Mobile Project is just starting, the projects are small, and some additional business has not been tied to the App. However, with the development of Mobile applications in the later stage, the Project is getting bigger and bigger, with more and more functions, resulting in the concept of componentization and modularization.
After Android Studio came out, a new concept, Project, Module… Module; The common package, which was then separated AS a package, is now Module in AS. As you all know, Module contains two formats: Application and Library. In other words, a Module is a small project and a Module in the concept of AS. So we started designing the common module common_business module and even the DB module. What are the benefits of modules? Compared to packages, modules are more flexible, less coupled, and can be plugged in wherever they want. According to different concerns, the shared parts of a project are extracted to form independent modules, which is modularity. Modularity includes not only common parts, but also business modules.
componentization
Component-based Software Engineering (CBSE), also known as component-based Evolution (CBD), is a branch of software engineering that emphasizes separation of concerns with respect to the broad range of functionality provided in a given software system. It is a reuse-based approach for defining, implementing, and composing loosely coupled independent components into a system. This approach is designed to deliver equally broad short-term and long-term benefits for the software itself and for the organizations that sponsor such software.
To put it simply: componentization is based on the purpose of reuse, a large software system in the form of separation of concerns, the separation of multiple independent components, reduce coupling.
Basis is “library” or “components”, which means the code repeat part of the extract of each component supply function use: Dialog, all kinds of custom UI controls, can repeat application in projects or different code and so on Objective: reuse, decoupling rely on: low dependence between components, relatively independent architectural positioning: Vertical layering (located at the bottom of the architecture and dependent on other layers) features: It is divided from the perspective of THE UI interface, and the front end is componentized to facilitate the reuse of UI components
modular
Modular programming is a software design technique that emphasizes the separation of the functions of a program into independent, interchangeable modules, so that each module contains everything needed to perform only one aspect of the desired function.
To put it simply: Modularity is the breaking up of functionality into independent modules so that each module contains only what is relevant to its own functionality.
Is the framework of “business” or “business module”, can also be understood as a “framework”, which means the function division, will be integrated with the same type of code, so the module function is relatively complex, but all used belongs to a business: according to the functional requirements of project is divided into different types of business framework (such as: Registration, login, sports, mall, etc…..) Objective: to isolate/encapsulation (high cohesion) depends on: a dependent relationship between modules, can undertake the coupling problem between modules through a router architecture positioning: horizontally partitioned (located in the business architecture framework layer) features: from the Angle of the code logic, convenient layer code development, to make sure every single function module of function
pluggable
Plugins are strictly a modular concept. The division of a complete project into different plug-ins by business is an embodiment of divide-and-conquer. Divide the whole into parts and cooperate with each other. The smaller the module is, the easier it is to maintain, and plug-in is considered a kind of modularity, and componentization is not the same concept.
The unit of componentization is module and the unit of plug-in is APK (a complete application)
Componentalization decouples and speeds up compilation, isolation of parts of plug-in that don’t need to be concerned with decouples and speeds up compilation, and hot plug, or hot update
The flexibility of componentization is to switch according to the loading time and separate independent business components. For example, the flexibility of the plug-in of wechat moments of friends can be dynamically downloaded and updated when apK is loaded, which is more flexible than componentization
What componentization can do is, the circle of friends already exists, I want to debug, maintain, and others are not coupled, but the plug-in is related to the whole project. It can be said that the circle of friends is an app, I need to integrate, integrate it into wechat this big APP
Group is originally a system, you divided wechat into circle of friends, chat, address book according to the sense of independent modules, but it is not really independent module plug is different APK, you put wechat circle of friends, chat, address book separate to make a completely independent APP, when you need wechat plug together, For a large app, plug-in loading is dynamic, which is important and the source of flexibility.
conclusion
Componentization is based on reuse and reduces coupling; Modularity is divided according to different functional modules; Plug-in is to divide a complete project into different plug-ins according to the business.
Components are libraries that encapsulate code that can be reused in a project or in different types of projects. The module corresponds to the business logic module, which encapsulates the functional logic in the same type of project.
In fact, the definition of “component” is more concerned with “reuse” of code. “Modules” focus more on the integrity of a piece of business capability.
Components and modules actually divide an app from different perspectives. Components are more about dividing the implementation code from a bottom-up perspective in terms of technical implementation thinking, and assembling that code into an APP. Modules are more of a top-down view, partitioning implementation code along business lines.
The purpose of componentization and modularization is to reduce complexity of complex APP and improve development efficiency and quality. It’s just a slightly different Angle.