replicable solutions

T.Z. something like the following - you need to have some “quick start” for applications with standard functionality. An additional (and the most “intricate”) condition is that this standard functionality needs to be able to be modified in the most incredible way, up to and including complete shutdown and replacement with its own (application-specific) code.

I will give a vital example: there is a need to make VERY similar applications. For example, online stores that are built on approximately the same data schemes, business processes and so on. Those. The functionality of any of the stores is approximately identical, only the view layer is different.

However, in one of the stores, the price is not formed from the Prices table, but is obtained according to a more complex scheme from a stored procedure.
')
Actually, the task is how to reduce the “repeatability of the code” (ie, move away from monkey-patching) and at the same time not lose full control over the code.


After a brief analysis of the existing solutions, I came to the conclusion that there are three sane approaches to the solution:

RoR-style (aka maven-archetype)

All (practically) application code is created for an application at the beginning of development automatically (by a script, batch file, archetype, and so on) and subsequently changed to fit its needs in each specific project.

An example of this approach is most of the frameworks on dynamic PL: ruby ​​on rails, django, grails, ... In addition, in java there is such a framework as appfuse, using maven for about the same purposes (autogeneration of the initial code).

Pros:

• Very simple code structure. There are no additional descriptions of the modules or their configuration. Often - just the code on the main PL.
• Application speed - see below

Minuses:

• Monkey patching. Changes (for example, bugfix) in the main code will have to be made to all projects manually.

Java style

The code is spread across the libraries and is made very “customizable” (the code in such libraries must be very well tuned and, among other things, it can be replaced with its own code specific to this project).

An example of such an approach is, for example, eclipse ide or nuxeo ecm, which use equinox (OSGI implementation) to reduce code “connectedness” (code decoupling).

Pros:

• the absence of monkey-patching-a (changes that occurred in the base library will automatically appear in all applications that use it).

Minuses:

• speed (when using such a layer as equinox all operations of interaction between application modules will, by definition, be slower than without using such a layer. How difficult it is to slow down the application in practice is difficult to say - testing is necessary).
• additional “formatting” of the code (depending on the framework, the description of a separate module will require at least one “file of description” of this module. So nuxeo is an xml file that describes the module, its dependencies on other modules and methods of its “extension”. .e. how it can be configured or disabled.

Specific manual replication

Probably the well-known separation of code across libraries ... This is when the pens, without any “methods and concepts”, and so - as God will per capita and the architecture will allow ... For Java code, this is using Interfaces and using the plugin pattern, for the view layer it is writing something like customViewHandler, and so on.

Pros:

• No need to learn anything, no need to apply new frameworks. All code is “specific” for this area (be it core or view or something else).

Minuses:

• Non-universality For a particular case, it is difficult to predict in advance whether it will be possible to come up with “bringing the code to the library” or not. And if it will be possible to render the code, then perhaps it will require a non-standard (not usual) style of writing code or an additional description of it.

Conclusion

In conclusion, I would like to ask the audience - who uses which method and how successfully?