About Eclipse's use of "layering laws"

Contributing to eclipse, a co-author of Erich Gamma and Kent Beck, mentions some of the principles of Eclipse. In the extender-related law, a "hierarchy of rules" is generally defined as follows: "The development of language-independent functions and language-specific features, separating core functionality from UI functionality".

Personally feel that although called "layered law", in fact, reflects the rational division of the idea of the module.

Now focus on the "core functions and UI features separate," say your own experience, only for your reference. As a rule of thumb, the layering principle needs to be introduced and strictly adhered to when the outline design module is divided.

1. According to the requirement, the module is divided. The typical output is: The bottom module and the Build function module, the schematic diagram is as follows:

Description: For example, in the Integrated development environment (IDE) products, the underlying base module includes resource management (including compilation processing), Run-time model, and other types of modules, of course, may also be workbench similar modules (although the UI, but also the underlying basic module), which Some of the underlying modules provide services to the upper modules. The upper functional module is similar to creating a module of your own based on the GEF editor.

2, each module carries on the core function and the UI to divide separately. This includes both splitting the UI and core functionality of the upper functional module model, as well as splitting the underlying modules. The schematic diagram is as follows:

Description: Here, our specific functional modules are divided into the following:

Com.myproduct.myeditor.ui plug-in (UI section, for example, contains code that creates a process editor using GEF)

Com.myproduct.myeditor.core plug-in (model part, for example, contains the EMF to create an editor corresponding to the model code)

We have also divided the underlying modules:

Com.myproduct.resource Plug-ins (for example, include logical code such as builder)

Com.myproduct.refactoring.ui Plug-ins (refactoring features such as UI code that includes a series of refactoring needs)

Com.myproduct.refactoring.core Plug-ins (refactoring features, such as model code that contains some refactoring needs, etc.)