Alternative usages of string-resident pools

Cause

The cause of the matter is this.

Based on certain unavoidable factors.

I have 2 DLLs called A.dll and B.dll.

There are some identical code in these 2 class libraries (called code Cbelow)-Traversing all class library files under the current application and injecting plugins (yes, IOC)

When a developer references only a.dll or b.dll, there is no problem

But if a project needs to cite A.dll and B.dll at the same time, that's the trouble.

That part of exactly the same code will be executed 2 times, all plugins will be loaded 2 times

After

The simplest solution, of course, is to extract the same code from A.dll and B.dll into C.dll

Then refer to A.dll and C.dll as needed before referencing A.dll

Although it can be very simple to solve the problem, but also his cost of modification and user experience is the worst (software design also to user experience),

This scheme is reserved for scenarios in which no problem can be solved in any way.

Because A.dll and b.dll do not know each other's existence, so can not directly notify the other party I have executed code C.

Think of the medium mUtex, also want to use reflection, because there are various side effects and give up

The rest of the process of trying out a variety of programs is not said ...

Results

Finally, a flash, suddenly thought of the string pool (do not know their own Baidu, or search blog Park related articles)

String. Intern putting strings into a resident pool

String. Isinterned returns a reference to a string that resides in the pool if NULL is returned, indicating that the string is not in the resident pool

Suddenly there is an idea: convention a string, when any code C is executed, the first to determine whether the string is in the pool, if not the execution of code, after the completion of the string into the resident pool

There is, of course, a place to be aware that if the string is directly fixed in the write-in code, it will be placed in the resident pool during compilation

Pest, XXX is hard coded in the code can be seen in the resident pool, while the NewGuid string is not in the resident pool

All hard-coded strings are compiled into constants , and the constant string is also in the resident pool.

Plus the string is a reference type, but there is the concept of constant, so the global lock is also done, lock a constant string directly on the line

So the code in the actual project is as follows:

Alternative usages of string-resident pools