Why componentize?

  • Application volume is getting bigger and bigger
  • Business code is increasingly coupled
  • Code increase
  • Not easy to reuse functions

Advantages and disadvantages of componentization

advantages

  1. Business is layered, decoupled and easy to maintain code
  2. It is easy to split and extract each service function, realizing the real function reuse
  3. Business isolation facilitates implementation of code control and version risk control across teams
  4. Componentization has certain requirements for code encapsulation and rationality, which improves the design ability of developers

disadvantages

  1. Increased learning costs for developers
  2. Increased code redundancy, the finer the granularity of componentization, the more intermediate code
  3. Increased project complexity

What are the componentization schemes? What are the pros and cons?

  • Target – Action: CTMediator

    Target-action is an approach to dynamically fetching modules based on ObjC’s Runtime and category features, such as fetching classes from String and creating instances. Call the method dynamically via performSelector + NSInvocation.

    First, each module needs to configure Target and Category. Target is one or more targets corresponding to each component, and Category is the classification of mediators at the middle layer. The purpose of using classification is to separate the business codes of Mediators. Thus reducing the dependency and coupling of mediators.

    Mediators use the Reflection mechanism of the Runtime to find the corresponding Target and Action in the Category to call the component

    advantages

    • Decoupled, with only a component dependency middle layer (one-way dependency)
    • Compile checking takes advantage of interfaces that categories can explicitly declare
    • Unified processing of all components call entry, easy management

    disadvantages

    • Each component has a corresponding Category middleware, increasing the amount of code
    • There are hard coding problems with defining strings

  • URL Scheme: JLRoutes and MGJRouter

    JLRoutes globally stores a Map with Scheme as the Key and JLRoutes as the Value. So each scheme is unique in routeControllerMap.

    An array is stored in each JLRoutes. This array holds each routing rule. JLRRouteDefinition holds block closures passed in from the outside, pattern, and the pattern after splitting.

    advantages

    • The server can dynamically control page redirects, process errors after page faults, and unify the request modes of the iOS, Android, and H5 terminals

    disadvantages

    • URL short link distribution registration, navigation more hard coding
    • The load method of Class is used to register the App. Too much will affect the main thread when starting the App
    • All urls, classes, instances, and blocks must be registered in advance

  • Protocol:BeeHive

    Instead of directly calling the corresponding module, each module calls the corresponding module in the form of Service, avoiding direct dependence. The distribution of the App lifecycle splits the logic coupled in the AppDelegate, with each module living independently as a microapplication.

    advantages

    • Protocol interface specification, following the dependency inversion principle
    • No hard coded

    disadvantages

    • Lack of unified scheduling layer, component method calls scattered, difficult to centralized management
    • The architecture is not flexible enough

Componentization in a project

The Foundation of the Framework – Five Principles

  1. Rule of single functionality: Object functionality should be single, do not add a lot of functionality to an object
  2. Open closed principle: Extension is open, modification is closed
  3. Richter’s substitution rule: Subclass objects can replace base objects
  4. Interface isolation principle: An interface must be used for a single purpose. Do not implement multiple functions on an interface based on different input parameters
  5. The dependency inversion principle: Methods should rely on abstractions, not instances. IOS development is a high-level business approach that relies on protocols.

How to divide the relationship between upper and lower components?

  • Basic components that are not business related, such as network requests, image loading, and so on
  • Common functional components, such as accounts, statistical buried points, payments, sharing, etc
  • Business components for daily iteration

Components are designed in strict accordance with five principles.