Service--web Service

Object-oriented and component-oriented

. What is a Web service

. Application Classification of Web services

. Web services are an extension of object/component technology in the Internet

Object-oriented and component-oriented:

The base of object-oriented technology is encapsulation--interface and implementation separation, the core of object-oriented is polymorphism--this is a more advanced sublimation of interface and realization separation, and object-oriented representation is class and inheritance. The main objective of object-oriented is to make the system object, and the result of good object is that the parts of the system are clearer and the coupling degree is greatly reduced.

Component-oriented technology is based on the object technology, it is the further development of object technology, the concept of class is still a basic concept of component technology, but the concept of component technology is the core of the interface . The main goal of component technology is reuse-coarse-grained reuse , which is not reuse of classes, but the reuse of components, such as a DLL, a middleware, or even a framework. A component can have one class or multiple classes and other elements (enumerations,), but the component has a distinct feature, which is that it is a separate physical unit that is often present in non-source forms (such as binary, IL). A complete component typically has a main class, while other classes and elements exist to support the implementation of the main class's functionality. To support this physical independence and coarse-grained reuse, the components need more advanced conceptual support, the most basic of which are attributes and events, which once plagued our class's interdependence problem/messaging problem in the object's technology, so far I know that the best solution is the event. To understand the idea of component, we must first understand the thought and mechanism of the event.

I have always insisted that the shape/appearance of a component should be simple, clear, without redundancy, or irrelevant, and that the appearance is described by an interface that can publish events, properties, and methods. These three elements are sufficient to describe all the features of a component's appearance. For example, I used a finished port component of encapsulation, its appearance interface has only four methods, three events, three properties, and the internal implementation of the component has thousands of lines of code. So when designing a component, you need to make a lot of tradeoffs, what needs to be exposed through the interface, and which should be implemented as private. Sometimes you will be in a dilemma, because it makes the component easier to use, so you need to give a lot of default parameters, but in order to make the component more generic, you need to expose more properties to let people set, expose more methods and events to meet more complex functions. You need to decide, you need to weigh. No wonder someone would say that the design of software is more like art, because the beauty of art lies in the right choice and balance. My experience is that with low coupling, the interface of the component is good enough to deal with the current application. It's easy to refactor and enhance it if you need to strengthen it later, because it's already been said to keep the components low-coupling.

It should be noted that the controls that we usually call, such as buttons, are also a component, so to speak, a control is a component that has a UI form. The plug-in (Addin/plugin) is also a special component, and the standalone presence of plugins is meaningless, and is used by frameworks that are compatible with the plugin protocol.

What is a Web service

I am not the author of my own handwriting, is the result of online collection of information.

Service--web Service