Under what circumstances does Eclipse plug-in development create an extension point

I think most of the eclipse plug-in developers are familiar with the concept of extension points, so when do you decide to create your own extension points? Simple to say my opinion, wrong not to joke.

Why are you talking about this problem? See some of the plug-in development of the first person, do not understand the extension point of the relevant things, also not to understand the extension point mechanism, so this time never define the new extension point; After a while, feel a little bit of experience using Eclipse extension points (especially Workbench related extension points must be used frequently), begin to define their own extension points, ..., disaster occurred, chaos Definition extension point, all kinds of ideas extension points are out ...

Background: The extension point mechanism in Eclipse plug-in development eclipse is justified

Under what circumstances would you create your own extension points? In one word: Allow extensions, and invite external extensions actively.

Before you define an extension point, you can try asking yourself the following two questions:

1, from the demand point of view, to this demand exist?

2, from a technical perspective, you want to use the extension point description is not the implementation of the internal module?

3, from a technical perspective, even if the need to expand, really need to dynamically hang? Java default static injection not allowed?

4, from the technical point of view, you are the module is a high-level function module?

On the 1th, take a look at the requirements document, the corresponding function point requirements description. This time from the customer's point of view, the customer will be for your module two times open, if development, need to register to expand to your module?

On the 2nd, if you want to use the extension point to describe something that is not visible to the outside of the module, it belongs to the internal implementation within your module, the extension point must not be used.

On the 3rd, many new people are very easy to make mistakes, the language features and platform mechanism mixed together. For example, suppose you define a policy interface Ipolicy, have a corresponding manager-type role in managing Ipolicy instances, existing implementations Policya, POLICYB,

1 public class PolicyManager {
2 private static PolicyManager manager;
3
4 private List<IPolicy> policyList = new ArrayList<IPolicy>(5);
5
6 /**
7 * sinleton
8 */
9 private PolicyManager() {
10 policyList.add(new PolicyA());
11 policyList.add(new PolicyB());
12 }
13
14 public static PolicyManager getInstance() {
15 if (manager == null)
16 manager = new PolicyManager();
17
18 return manager;
19 }
20
21 public static IPolicy [] getPolicys() {
22 //TODO:
23 }
24 }

And you feel like there's going to be policyc to join. Then join the good, I hope your manager inside the code to sign up on it.　That might ask, is this not a modification of the code, and if you use extension points, then you don't have to change the manager's code? Keep in mind that the extension point is a platform mechanism that is a level higher than the language feature. In this scenario, unless you really need external involvement to provide a new Ipolicy implementation (dynamically hooking up with extension points), then be honest with the Java language support.

On the 4th, take a look at the extension points provided by eclipse itself. Most of the extension points in Eclipse are basically provided in two types of modules: the first is the underlying modules, such as runtime, resource management, Workbench, and two modules that may require two of custom development, such as JDT, 　Because in many scenarios, users will expand their development based on JDT to provide their own extensions to the JDT. If your module is an upper-level functional module, and you can be sure that no other module will depend on it, how can there be extension points??? If you're working with an IDE and you've created your own project type, the existing file types are likely to expand. You are now designing a project builder, and the normal design logic is of course to invoke the corresponding compiler for different file types, and the compiler needs to be dynamically hooked up. For example, your file-oriented compiler interface is Imodelcompiler, so you create a compiler extension point, and your existing compiler implementations are dynamically hooked up to the extension point, the fair rule.

A few comprehensive considerations