I started to record some ideas when I was designing and developing UNCERTAIN frames.
I do this framework for trying some potential, more reasonable programming possibilities. Over the years I have been analyzing / designing the object-oriented ideas, I am more and more, I have some problems that are unable to solve it in an existing object-oriented approach.
For example, any graphical application, whether it is a word processing, spreadsheet, picture processing, or sound editing, there is a basic
Features: If the user turns off the entire program, and there are some open files that are not saved, then the user needs to be prompted. All such applications have similar code:
For Each (Document M in OpenNed_DOCS) {
IF (m.issaved ()) {
Result = messagebox (....);
IF (result == yes) OpensaveasDialog;
Else if (result == no) EXITAPPLICATION;
Else if (result == cancel) return;
}
}
We know that prompting users to save unsaved files when the user exits the program, which is an abstract
Features, it is independent of the specific application, regardless of the future program is used to edit what type of file, this feature always exists; however, we can create an object (for example, called confirmsave), to achieve this feature, so as not to Write similar code when writing different applications? It is difficult to do it. First, as shown in front of the code, we need to traverse all current users to open documents to find unsaved files, but this time we cannot determine what objects will be used to save these documents. It may be a collection or may be a list, or a custom non-container class object. Second, we can't determine how to use a general way to judge whether a file is not saved. According to object-oriented ideas, we should define an interface similar to IDocument and give it a method similar to boolean issaved (). However, when we implement this feature, we only pay attention to this characteristic of IDocument: can determine whether to save, we have other possible basic features of IDocument, such as saving to disk, reading from disk, do not care, and It is not determined at this time. So how can we guarantee that the IDocument written can abstract the basic characteristics of all documents, and will not give up in the future because it is not enough to think about it? Can not guarantee. Even if we only define this method of iSSaved, or turn a simpler interface isavecapable to support us to continue, we will still touch the third question: How to call a dialog box to prompt whether the user is Need to save? There are countless GUI libraries / frameworks for C , WXWINDOWS, QT, for Java has AWT, SWING, SWT, and we need to create features unrelated to specific applications, do not depend on the actual GUI framework Therefore, we can't determine how to call dialogs this should be what should be done. If we continue to abstract, define an interface to iMessageBox, or IguifraMework, give it a method such as ShowMessageBox, and create a class in the specific GUI framework to implement these interfaces, and the problem is still not resolved. At this point, we can determine that this dialog should have three buttons, which are representative, no, and cancellation, we can also determine that this dialog is modal (MODAL), but we can't determine how to get on the dialog. prompt. Applications may get a string from the registry, ini / print, user settings, string resource table, or source program, who knows? There is also an international problem. Will your program support multi-language display? From this point of view, our confirmsave is temporarily uncomfortable. Before completing it, we need at least one application's document model, a GUI framework, a configuration information access scheme. Throw away these to achieve a separate confirmsave, seems to be a very boring thing. However, we know exactly that when the user exits the program, it prompts the user to save unsaved files. It is important to be an objective feature and is not very related to the specific application. Why can't we do it separately? The complex system is divided into simple, functional single modules, reducing the coupling between each module, isn't it one of the original intentions of the object-oriented design method?
It seems that we seem to have encountered an object-oriented bottleneck: there are some things, we can't make simple use of objects, or, even if it is implemented, it is too high depending on other object dependence, but can be reused value . In the object-oriented philosophy, we have encountered a difficult problem: if the particle size of the object is reduced, the function is as single as possible (i.e., improved the internal level of the object), can cause many hypothetical assumptions to other objects. Introduce too much interface (or abstract class), resulting in an increase in inter-object apocpression; if the particle size of the object is increased, the object is made to complete enough, which will make the object be large and difficult to maintain, and apply The range will also be limited. There are currently some technical / patterns to try to solve such problems. E.g
AOP, for example
IOC. I also have some ideas for this, I am trying to explore the feasibility of these ideas through the framework of Uncertain. Today, it is limited, first written here.
