[Thinking] plug-in processing thinking based on Golang interface characteristic derivation

This is a creation in Article, where the information may have evolved or changed.

In many of the application scenarios of the design program we encounter task flows that are broadly divided into three phases.

First, entrance

One or more entrances, waiting for blocking, or unsolicited requests.

==============================

For example, the task flow needs to accept application requests from HTTP and FTP, and subsequent requests for acceptance may be added in other ways.

Second, processing

Multiple portals can correspond to one handler or multiple handlers.

==================================

For example, HTTP and FTP Multiple entry procedures need to correspond to one or more processing logic, also faced with the increase of the processing program extensibility.

Third, export

Multiple handlers or one handler for multiple exits or one exit.

==================================

such as alarm mode has mail alarm, alarm and so on, the following may increase SMS alarm and so on.

In fact, the vast majority of demand can be abstracted into the above thinking.

So the extensibility requirement for this kind of problem is to change a small amount of the original code or simply not change the original code when expanding the function. Regardless of the software refactoring level, when the new recruits take over the boss's code, I think the most headache is to increase demand, because you do not know what to change the code to bring a hidden BUG.

We always ideal can use the "plug-in" thinking to adapt to demand, write a good framework, and then classify, each of the abstract role is a large container, and then each time to the container plug into a plug-in, to a demand, do a plug-in. To two needs, do two plug-ins to plug in a pair.

More "excessive" requirements are inserted into the plug-in must have a button to control whether to enable the plug-in, the reason is to plug the plug-in too time-consuming (corresponding code in the comments N multiple lines).

In short, everything we want the effect is that each plug-in independent work, non-corresponding, increase the scalability. The disadvantage is that there may be a part of the redundant code, but this is more than the handover to work so that people every day behind the black you have to be strong.

First we use the Golang to create a demand container.

/** Requirements Container * **/Package Needimport ("FMT")//I am a container for storage pluginsvarPlugins map[string]need//code executed each time the container is importedfunc init () {/*set the capacity of the container*/Plugins= Make (map[string]need)}//set the plug-in in this container to look likeType needInterface {    /*it must tell the container whether it is sick*/Flag ()BOOL    /*it has to have a starting method.*/Start ()}//start all the plugins in this containerfunc Start () { forName, plugin: =Range Plugins {/*To see if the plug-in is enabled*/        ifplugin. Flag () {Go plugin. Start () fmt. Printf ("Launch plugin%s\n", Name)} Else{fmt. Printf ("%s plugin is sick. \ n", Name)} }}//The plugin must be inserted into the container after it is done.Func regist (namestring, plugin need) {Plugins[name]=Plugin}

This requirement container is required to insert your own plugin!

1. Must tell the container that the plug-in itself is not normal
2. Must provide the content of your plugin's work
3. Must be connected to the container

If 1 is missing, you can't implement plugins sick and leave sick.

If the missing 2, you say you do not say what you are the container how dare to accept you, in case of drug trafficking to do ~

If 3 is missing, the contract with the container, binding labor relations.

In accordance with the above requirements, we will implement a plug-in number.

/** Plugin number **/Package Plugin_1import ("FMT"    "need") Func init () {p_1:=plugin_1{}/*connect to the container*/need. Regist ("plugin_1", P_1)} Type plugin_1struct {}//Tell the plugin I'm not sick .Func ( Thisplugin_1) Flag ()BOOL {    return true}//tell the plugin what I'm doing.Func ( Thisplugin_1) Start () {fmt. Println ("I'm the soy sauce one number ~")}

Now is the container also has, plug-ins also have, but no electricity to run up ah ... , we now use Golang to provide him with a power supply.

Package Mainimport (
    " need " "Need/plugin_1" ) func main () {      
    /* The power supply only cares about the container's start-up, not the container's plug-in */    need. Start ()}

Run the power supply.

$ go Run main.go I'm a soy sauce . -Start plugin plugin_1

Now that we have two more needs, we're adding two plugins in the same scenario.

Plug-in number second.

/** Plug-in no. second **/Package Plugin_2import ("FMT"    "need") Func init () {p_2:=plugin_2{}/*connect to the container*/need. Regist ("plugin_2", P_2)} Type plugin_2struct {}//Tell the plugin I'm not sick .Func ( Thisplugin_2) Flag ()BOOL {    return true}//tell the plugin what I'm doing.Func ( Thisplugin_2) Start () {fmt. Println ("I'm soy sauce # second ~")}

Plug-in number third.

/** Plug-in no. third **/Package Plugin_3import ("FMT"    "need") Func init () {p_3:=plugin_3{}/*connect to the container*/need. Regist ("Plugin_3", P_3)} Type Plugin_3struct {}//Tell the plugin I'm not sick .Func ( ThisPlugin_3) Flag ()BOOL {    return true}//tell the plugin what I'm doing.Func ( Thisplugin_3) Start () {fmt. Println ("I'm soy sauce # third ~")}

Power Up:

# Go Run main.go I'm soy sauce # third ~ Start plugin plugin_3 I'm soy sauce # second ~ start plug-in plugin_2 I'm a soy sauce . -Start plug-in plugin_1 

We can simulate the plug-in number second is sick. Change the true of plug-in number second to false to start the power again.

$ go Run main.go    I'm soy sauce # third ~ start plug-in plugin_3plugin_2 plug-in sick I'm soy sauce one ~ start plug-in plugin_1

The whole program looks like this.

You can also make it this way, no more than worry about the power load too high.

Reasonable use can increase the good extensibility, but will add a lot of redundant code (do not care about those details ~).