Component Technology (I)

What is component technology? What is the role of component technology? Why apply component technologies? How to Apply component technology? What do we know now? What should we do now? What can we do?When these problems are entangled in your mind, you may also admit that you have to learn component technology. The code must be familiar with component technology (this article will be replaced by components later ). Now, I want to ask myself, how do you think about components? What does your component look like? I feel very good to say, maybe every programmer has a concept of a contour for components. Yes, the Windows platform has been in use for more than a decade. How can I not hear about components? In the big aspect, when MS applies OLE, components are gradually developing, from OLE to COM to CMO + and even to the present. net, there is nowhere to see the existence of components, but this is only a profile of the impact, I think, when learning components, we should first understand some basic concepts. The final purpose of writing this article is to answer several questions raised at the beginning and teach you how to write components (this article will end with writing an ocx component, applying MTS component, and COM + component, some Ambiguity in COM + is the updated version of MTS will also be explained ). What is component technology?The concept of concrete rigidity has many definitions in various books. component technology is to use some programming means to put some people's concerns, however, it is not easy for end users to encapsulate the details of operations directly, and various business logic rules are implemented to process the user's internal operation details, the security mechanism and the thing mechanism can be fully embodied. This encapsulation body is often called a component. This definition may be a bit stubborn, but this explanation is helpful to you now. In this encapsulation process, the programming tool only acts as a simple tool, there is no practical significance. That is to say, to encapsulate a rule, you can use any tool that supports component writing, the final component does not have any relationship with the language itself, and can even be implemented across platforms. For us, it is a black box that implements some functions and has an input/output interface. What is the role of a component?This question seems to be a little general. Try to think about how windwos achieves such powerful productivity? What is behind it? One sentence: components are the soul of windows. Without components, the Windows system will no longer be like today, such as today, windows, and Unix. As an operating system, all of its functions are provided by component services. A copy-Paster can be easily supported by DDE, which is a component service object, what does a large ERP rely on? What does a multi-layer system rely on? Component! Components encapsulate various rules or even runtime environments that run the system. How can components complete so many services? The component object has to be mentioned here. The so-called component object is a set of components, and this set is not a random combination. The coordination function of each component in the component object must be taken into account, although, in theory, each component in a component object should not interfere with each other or affect each other, it does not mean that the component object is a set of uncoordinated components, we must understand that by accessing a component in a component object, it is possible to access another component in this component object in this loop. who manages all of this? It must be a component object. It can be understood as follows: a component has its own rule implementation, and the Rule implementation is reflected in the interface implementation, but the component object itself is also a component, it also has business logic rules to be processed, and it also needs to coordinate the components in the collection. In this way, you can coordinate and implement some part of the business logic rules through a certain component object! For the application, it is completely unnecessary to know, or even meaningless. Why apply component technologies?You may say that we can also process some simple or slightly complex business rules through programming. Indeed, we do not deny it, through programming, we can implement rule processing that is generally implemented by component objects. However, if we say that the component object or component is consistent with our usual encoding, we can tell you clearly that this is a bad idea. The purpose of using the component technology is to implement various rules {the rules you want to implement}, and the component object will also be considered from a broader perspective, it can centrally plan a large distributed system, handle redundancy, ensure security, and balance loads ...... This is a very important reason for us to apply components. Furthermore, the component object is not a common executable file, nor is it intended to fix various rules inside it. It can smoothly implement its own upgrades and extensions (premise: for example, when we find that a business logic rule is outdated, We have to replace it with a new business logic rule, this replacement process will indicate that the components are common. DLL file or. there is a big difference between the EXE executable files. When we need to update the component object, in the ideal situation, the user can apply the component object while unconsciously accepting the new component technology, but can a DLL file or an executable file achieve this? The answer is no. If these reasons are not enough, I can cite a lot of applications to illustrate the necessity of component applications. However, there are too many reasons, and there is no need to list them one by one, you can refer to other technical materials or find them in normal operations. How to Apply components?At this point, we may be more concerned about how we implement components by means of programming. we mentioned at the beginning that components are to encapsulate business rules by some programming means, it also emphasizes that language is just a tool here. However, when you can write a complete component, your application will be clearer and you will be amazed at the efficiency it brings to your work. So how to apply the component technology? The component technology is part of the application of the high group. It can start from the underlying system to the encapsulation of obvious functions that we can feel. In this process, we need to use tools we are familiar with to write a good component object or component. What do we know now?Although the component technology belongs to the category of advanced programming, as long as it can be programmed and implemented {What kind of technology is not feasible ?} We can implement a component. And we already know the application and role of components. What we should do now is to be familiar with a development tool, the so-called "ready for good, it is necessary to sharpen the tool so long as we have a good grasp of a tool, it is possible to step into the component technology gate (please do not tangle with the expression here when the component technology is language-independent, in addition, the language will have to be achieved through tools, isn't it ?), Otherwise, even if you have a thorough understanding of the component technology, you can only stand outside the door. So what we know now is nothing more than two points: components and tools we have mastered. What do we do now? What can we do?The building without the Foundation will surely collapse, and we will not have a solid foundation to back up, so the components we write will be a little rubbish! Or unformed toys. You may be familiar with components and FrameWork design, but it is all based on the lack of understanding of its kernel. It can only be said that this is a blank design, because the design model that you will not be able to understand will bring a qualitative leap to your components, such as components and others, just as a good project manager needs to have a keen mind and a superb or pretty good skill, others will only think that he is talking about his ideas. So what we should do now is to fully understand the application of components, the rules of components, and our development tools. This is what we should do and is currently the only thing we can do. When we have a basic profile or a clear influence on components, the next step is to combine our tools and components. Each development tool has its own characteristics. Although different languages can implement some of the same functions, it is even generalized by the words of which development tool is used, at this point, we should be aware that this is wrong, because development tools have their own advantages and disadvantages, and the advantages of applications are what we should do (not to discard the disadvantages ), this is one of them. In addition, we must also know what technologies can be used to bring benefits to our components, ensure redundancy, and ensure load balancing. So far, when we are familiar with our development tools, we also need to deeply penetrate the idea of object-oriented programming. Why ?. Net Framework Design Patterns give us a lot of advice, a component is actually a project, a project, and the best way to achieve the project, the project is to make full use of OOP ideas, of course, if you are sure that the version here is the final version, it would be fine. It is nothing more than the complexity of the encoding system in this version. We can see that OOP programming is very helpful for writing components. If you are not clear about it, let's take a very simple example: using OOP can fully reduce the degree of reuse, increase scalability. However, if a component is used as an application server for many terminals, we must consider its implementation efficiency, scalability, and many other features. This is a process of mutual. So after that, I will first make a simple summary of OOP {everyone is doing OOP programming, so here is just a simple mention, saving N Words }. Let Object-Oriented Programming penetrate into every detail of our implementations.{Because some examples need to be designed here, and the tool I am familiar with is Delphi, so here we will use Delphi as the object of OOP} the three core contents of Object-oriented thinking are encapsulation, inheritance and polymorphism. We will analyze these three points and comment on some of them. This removes the two concepts of analysis classes and objects, but we should understand that objects, as class instances, are a pointer in a sense or in general. Of course, if you want to emphasize that Delphi is a reference/object model, rather than an object pointer, I will not justify it. Encapsulation:The component object needs to encapsulate components, while the component needs to encapsulate interfaces. The final interface still needs to encapsulate the business logic rules implemented by the component. Therefore, if we only consider this from the perspective of OOP, component Objects and OOP should have an inseparable relationship. Encapsulation mainly involves two aspects: Class encapsulation and object encapsulation. For details, refer to relevant materials. Encapsulation is a kind of UI separation. Why do I say this? When it comes to encapsulation, black boxes are perhaps the easiest thing we can think. Indeed, I also admit that encapsulation is a black box-based implementation method, and it is also a pretty good metaphor. How can we say it? Because encapsulation also has two "interfaces", one being active and the other being stable, and the other being "active" is the implementation method for encapsulating the internal business rules to be processed, if we do not care about its efficiency, we can use any means to implement its internal functions, can be arbitrarily modified (the random modification here is only given to reflect its "active .) However, no matter how active it is or how random it is, it has a final purpose, that is, to achieve a stable "interface", internal content can be modified, stable interfaces should not be changed at will. This is especially true for an interface, component, or component object. From a project alone, this encapsulation is a kind of UI separation, do not stubbornly think that UI separation is to put user operations and Logical Rule Processing on two "physical" operations that are far away from encapsulation. If so, I can only say that your OOP does not understand well. Here is an example for analysis: TCustomForm = class (TScrollingWinControl) private FActiveControl: TWinControl; FFocusedControl: TWinControl; function GetMDIChildren (I: Integer): TForm; function GetMonitor: TMonitor ;...... Public constructor Create (AOwner: TComponent); override; procedure AfterConstruction; override ;...... End; here, we want to explain that private is the active part we just mentioned. It can be changed internally. However, it must ensure that the final Public is stable. This is an encapsulated entity and an instance of UI operations. At the same time, we should also note that because of encapsulation, we are required to do some work when considering the Stability Part. After a project is invested in an application, there is no way to change these stable parts, because these parts are directly associated with the user, and the user's operations are the operations on the urgent part, if you change the attributes of the stable part that a user is using, the consequence is re-planning and development of the project. In a word, encapsulation can hide implementation details, modularize the code, and realize code reusability. Do you understand the encapsulation? If you have any questions, contact me. You are welcome to discuss with me. Inheritance:Encapsulation hides implementation details. What about inheritance? Inheritance aims to expand existing modules (such as classes and interfaces). It also achieves code reusability, which has been emphasized in the encapsulation section, encapsulation is to clearly divide a module into a "active" implementation part and a stable implementation part. We also mentioned that after implementation and distribution, it should not be changed, especially when a project has been put into application, modifying the stable part will destroy the original intention and may cause the whole system to become junk. In the interface, obviously, how can we never add, modify, or perform any other operations on a module? Modify one of the interfaces? Certainly not, The modified interface is actually saying: My component will no longer serve my users, because I will re-plan the interface that the user is applying, in addition, other components may not call this interface any more. Imagine what the result is? {Note: an object can implement multiple interfaces, and a component can contain multiple objects that implement multiple interfaces. At the same time, a component object is a set of multiple components }. What should I do? Abandon this component object or project? What Should users do? Does the boss allow us to do this? Certainly not. At this point, it is time to use inheritance. For example, A method in interface A needs to be changed (the method here is actually A property !), At the same time, you need to add another attribute. There are two methods to re-write an interface. The other method is to inherit from interface A and let interface B be used as the derived interface of interface, it can implement the inherited attributes in all interface A, and overwrite A certain attribute, and implement it with another rule. It can also add its own methods and attributes. All of this is completely transparent to users. They do not know what you have done, but even more, some interfaces of their applications have been replaced (can they be replaced? Pay attention to the usage of As in Delphi ). Polymorphism:While understanding encapsulation and inheritance, let's take a look at polymorphism. If we want to make an image and a clear description of polymorphism, it will take too much space, at present, there are many explanations about polymorphism. You can refer to some materials for understanding. Here we will just give a brief description: polymorphism is the least understandable and interesting part of the three basic concepts in OOP. we mentioned that encapsulation can hide implementation details and make code modular; inheritance can extend existing code modules (classes) for the purpose of code reuse. Polymorphism aims to achieve another purpose-interface reuse! The essence of polymorphism is to assign the pointer of the subclass type to the pointer of the parent class (which is referenced in OP and essentially a pointer). As long as such a value is assigned, polymorphism occurs, because "upward ing" is implemented ". The code addition section {also talks about multi-state encapsulation, inheritance, and polymorphism constitute the three basic cores of OOP. We have previously introduced encapsulation and inheritance, but polymorphism is not described in detail, I would like to add the three major topics of OOP to end the one of OOP. Polymorphism is introduced in many materials, and the introduction is wonderful. Let's make a general introduction in this article. First of all, let's talk nonsense. In the following introduction and examples, I will use Object Pascal as a tool to explain, while polymorphism is essentially OOP and does not belong to a specific tool, it is a belief. Although it is described in Objec Pascal, it can be extended to any language. Let's continue our discussion. What is polymorphism? What is the essence of polymorphism? What is the relationship between polymorphism and encapsulation and inheritance? What kind of position does it play in OO? What does polymorphism bring to our work? This article will elaborate on these issues, understanding polymorphism, understanding polymorphism, and application polymorphism in the elaboration process. What is polymorphism? There seems to be no uniform definition to regulate polymorphism. Perhaps it is more appropriate to interpret polymorphism in our own way of understanding. Here we do not reference some terms for definition, this definition can also be understood by beginners as follows: polymorphism, Gu mingyu, is a variety of forms, and where are these forms specific? It can be understood in this way that we can use an object with a contour to describe multiple objects that are not equal to one another. It is not important for me to describe the state of the object. Why? Polymorphism provides us with such a mechanism. We only declare and define it in form, but we do not need to care about the details of implementation here. Or the specific implementation details will be handed over to other things for implementation. The base class we declare is just a definition in a sense. Just like an interface, there is no implementation. Here, we have to say the essence of polymorphism. The essence of polymorphism is that the base class provides a series of virtual methods. If you try to implement this base class, it will be reported by the compiler. The complete elevation of polymorphism is a way of thinking that the object and its sub-objects can accomplish together. Polymorphism is a technique that allows you to set a parent object to be equal to one or more of its sub-objects, the parent object can operate in different ways based on the features of the sub-objects assigned to it. For users, they only care about the virtual methods provided by the parent class without implementation details. In terms of interfaces, we do not care about the Implementation Details of interfaces. We only care about the methods provided by interfaces to complete our functions, as for the method in which an interface implements the different functions we need, or even multiple functions in a specific mode, it is internal. I don't know if such an explanation is vague or not acceptable. Continue. Speaking of polymorphism, we should first understand that for polymorphism, its parent class provides many virtual methods, so we cannot directly implement this parent class, only its derived classes can overwrite the virtual methods provided by it, so this produces polymorphism. We all know that a class can be inherited by multiple subclasses, and the methods implemented by each subclass are different, or, according to their own characteristics, there are differences in the implementation of a specific method due to class differences, but we can blur these operations through the parent class. You can use the base class to call subclass methods. Therefore, if this base class is not derived, this class has no meaning at all! Only when it is derived from a subclass does it actually have a meaning. Where does this meaning come from? Or how can we make this meaning the focus? This is why we need to further explore polymorphism, as shown below: TA = Class Public Procedure A; virtual; abstract; Procedure B; Virtual; abstract; Procedure C; virtual; abstract; end; when we declare class TA, we can see that it has three methods, and we also note that these three methods are completely virtual. If we try to instantiate this TA at this time, it makes no sense, because we cannot implement the methods provided by class TA, or the compiler will not provide space/mechanism for us to implement these virtual methods. Only by overwriting these virtual methods through its subclass can they be truly reflected in its role. Overwrite means that the subclass is redefined and the base class method is implemented. For example, TB = Class (TA) Private B _Str: String; Public Constructor Create (Value: String); Destructor Destroy (); override; {This is overwrite. Where can I use override? Override} Procedure A; override; Procedure B; override; Procedure C; override; end; TC = Class (TA) Private C_Str: String; Public Constructor Create (Value: String); Destructor Destroy (); override; Procedure A; override; Procedure B; override; Procedure C; override; end; here is a concept that is often obfuscated by beginners or those who do not pay much attention to syntax. Override and overload ). As mentioned above, overwrite refers to the practice of redefining the virtual function of the parent class by the subclass (what does inherted mean ?). Overload means that multiple functions with the same name are allowed, and the parameter tables of these functions are different (maybe the number of parameters is different, maybe the parameter types are different, or both are different ). Procedure OpenSQL (Sender: TADOQuery; SQLStr: String); overload; {If repeated, False is returned; otherwise, True} Function OpenSQL (SQLStr: String): Boolean; overload; Function ifrepeat (TableName, FieldName, FieldValue: String; IntValue: Integer = 0): Boolean; overload; Function ifRepeate (TableName: String; FieldName, FieldValue: Array of String ): string; overload; you can clearly see that the code above is a process in which a subclass covers the Virtual Methods of the base class. At this time, it is not clear to mention the polymorphism. Features, or the nature of polymorphism issues have not been mentioned yet, and you may not be very clear about the late binding. I will explain them below. When we derive the class TB and TC from the abstract class TA, And the subclass also covers the Virtual Methods of the base class, how can we apply these methods now? In what form will we call these methods? This is the time when polymorphism is the most important and the most important part of polymorphism, the essence of polymorphism is to assign the pointer of the subclass type to the pointer of the parent class. As long as this assignment happens, polymorphism is generated, because "upward ing" is implemented ". Why do we say this? Please continue with our instance, assuming their implementation methods are as follows: {TC} procedure TC. a; begin inherited; {inherted refers to handing over the corresponding message to its parent class for processing. It does not belong to the scope we discuss} ShowMessage ('tc '+ C_Str); end; ...... {TB} procedure TB. A; begin inherited; ShowMessage ('tb' + B _Str); end ;...... Now we can use the parent class to call the Child class, and this process is actually a "upward ing" process, that is: the Child class pointer is assigned to the parent class pointer; we can define a global process here to verify our above words: Procedure Test (Const pA: TA); begin pa. a; {put your attention here. As we have said, TA is A pumping class, and the methods it provides are all virtual and can be applied only when it is overwritten, is the processing here correct? The answer is yes. In this case, polymorphism is lifted throughout the whole process. At the same time, I also gave the call process} end; procedure Tform. buttonClick (Sender: TObject); var vTC: TC; begin vTC: = TC. create ('multi-state instance _ vTC '); Test (vTC); vTC. free; end; {can you see this "upward ing" mechanism? As a reference value (Object Pointer) of a subclass TC, vTC can be assigned to its base class TA. Therefore, a pointer of the subclass type is assigned to the pointer of the parent class, so polymorphism occurs !!!} Next, we will describe the late binding or dynamic process: When the subclass redefined the virtual function of the parent class, the parent class pointer will be assigned to it based on different subclass pointers, dynamic (remember: Dynamic !) The call of this function belongs to the subclass. Such a function call cannot be determined during compilation (the address of the virtual function of the subclass called cannot be provided ). Therefore, such a function address is bound at runtime (later bound ). I think, at this time, you should understand polymorphism very well. So we have mentioned that polymorphism is a top priority of OOP, so what is the role of polymorphism? What efficiency will it bring to our project? Is it just to accomplish some implementation method? Does it exist only as a concept? These are things we must think about after understanding polymorphism. Then we will explain how polymorphism affects our efficiency. We know that encapsulation can hide implementation details to modularize the code. inheritance can expand existing code modules (classes). They are all for the purpose of code reuse. Polymorphism aims to achieve another purpose-interface reuse! If you do not understand polymorphism, refer to the example below. In this case, we can say that the cannon can beat birds, the firegun can also beat birds. Which one do you use? All I know is whether it's a cannon or a firegun! I use a cannon for a bird as big as a dinosaur (for example, how can there be such a big bird? For the Chief Executive, what is the purpose of killing the birds? He doesn't care.) I use a firegun for birds. When the enemy comes, I can beat the enemy. This is the final explanation of the dynamic situation and the reuse of an interface!
There are many places where I am an application elder .} In the summary of OOP, I want to talk about some of my views on current programmers, or I am confused once when I have reviewed the penetration of my own OOP ideas, indeed, I always think that Delphi is indeed an excellent development tool that is efficient, fast, and easy to use ......, However, for a long period of time, I don't know if I have some OOP penetration during project and code writing? There is a feeling that I only seem to be able to apply those controls. coding is just about coding them, visual interface design, and a wide variety of available components make me feel uneasy, I don't know if I just pull a graph from a place like a graph, and then I will only modify it. Although this gives me a good app for the VCL component, but I have never been happy, and I have always been depressed. Does VCL just give us this? So I am no longer crazy about purchasing books for VCL components. Only when I got in touch with Interface Programming and component technology did I find that I used to spend a long time, or even throughout my entire programming career, focus only on the use of existing VCL components provided by Delphi, while ignoring the significance of the object-oriented thinking for the entire component architecture system of Delphi. I also deeply understand why some predecessors have said "Delphi is poisoning programmers". Here, I sincerely hope you will not stay on using VCL components, instead, we should use object-oriented ideas to understand the significance of Delphi's entire component architecture system. After understanding OOP, We need to describe the interface, another essential knowledge point of the component. Maybe it is boring for you to contact the interface just now, but it must be explained to you, the interfaces mentioned here will be fully referenced in future component technologies or component objects, because they are ultimately the implementation and encapsulation of interfaces! Please pay attention to the next article.