I. Implement business objects
The class encapsulated the business rules is the foundation of true face-to-object programming
This article we will involve all aspects of programming, and question some usual ways we write Delphi procedures. The foundation concept behind these design methods is a package: design a set of clear definition interfaces (Methods) classes, which operate their properties. This concept will consider the entire program and have a great impact on how the data is saved and present. I am willing to introduce readers to learn Francis Glassborow's article about C , although the language is different, the excellent design concept is independent of language.
Most Delphi written programs today are not object-oriented. It is just a model in the language and uses the original or new classes, which is not aware that the program is a true object-oriented. The reuse of the code has ended with the third-party control to the window, and the interdependence between the windows and units is rapidly spread. (!!!) If the foundation of the program is to change the program (such as switching different databases or three-layer structure from two layers into three layers), it will be seriously blocked or expensive. If it is a program that is truly written in an object, it will be very convenient instead of being restricted. Of course, it is necessary to write such a program to improve the concept, and the lack of productivity is lacking, most development teams are not willing to consider. I hope to demonstrate how to write better procedures through this article. Eventually make the system more reliable, easy to maintain, uniform, flexible, reuse, better than running with traditional ways. Especially for large programs, clarity and truly faced objects require less maintenance resources than traditional ways.
Object-oriented program higher reliability comes from data and operations being packaged in a clear defined class. The compiler uses a powerful type to enable the correct class, method, and attributes in the code, and the code that affects the entire program will not make people misunderstand the code intend. The correct use class is a class between classes is self-clear, and most of the code truly focuses on the key part of the program, rather than considering how the data is sustained to store such a detail problem. The simplicity and consistency of through the code will increase the maintenance of the program. As we will see, extensive use of class inheritage adds productivity and reliability and enhances consistency. These consistency are embodied in the displayed code, including the behavior of the class, how the data stores and how the user interface is present. Since most features are provided in the base class, they can fundamentally change the program by rapidly changing their behavior. (If the user's interactive interface is changed from window driver to HTML as an HTML) These base classes can be designed to be independent of the program, so the second similar program will be immediately pushed on productivity. A set of excellent base classes for a medium program can provide a significant increase in up to% 50, from time, expense to reliability. The first thing to emphasize is that switching to real-oriented development is not trivial, the first time you should guarantee a rich experience, or less procedures and no urgent delivery period; also to explain an object-oriented (OO) The solution does not specify which classes should be used in the program. If a company has developed its own visual control, or uses a third-party visual control,
Core class
The first step of designing any object-oriented program is to consider which must be class. This is an absolutely basic step, there must be other development technologies, because the error in the early stage should be corrected. When designing our class, we generally strive to achieve low-coupling high-poly-class and classes to be independent, but can be compounded through some powerful manner. One way to achieve this is to divide the class into different categories in different roles in their programs. The correct choice for these roles will form a group of cohesive classes.
There is a consistent basic principle in the role design of the class: divided into performance, application, and persistent storage data (typically in the database). Although this is the same as the three-layer database program, it is prompted that the concept of this division can be implemented in a variety of environments: from the single-chip program to the distributed multi-layer program. This group of application logic is responsible for the most difficult task, such as requests to operate and process data. A part of this class has a real world entity and is model the system. These classes are often referred to as "business class" or "problem domain". They constitute any partially important part of the object-oriented program, because other classes will support these classes in some way, they become the focus of all developers. Identify which commercial objects in a particular program are generally experienced, although there is a complete discipline (or art?) Facing the object-oriented technology, such as SSADM (1), throughout the analysis design and The process of maintaining the entity: can perform each commercial object by object-oriented (OOA), object-oriented design (OOD) and object-oriented programming (OOP). We will explore some of the skills that identify the right business objects. First we assume that these processes have been completed.
Inter-communication between different layers (performance, application, and persistent) is clearly defined and connected to each other. The relationship between these classes is shown in Figure 1
The arrows in the figure displays the methods in the same layer to call the other class. This picture also describes the class of the performance layer (user interface) to operate other classes, application layer (commercial objects) in the application layer or user interface, can operate the application layer and the method of calling the persistence layer, and the persistence layer only responds to the application layer. Request.
Commercial object
In order to demonstrate how the business object is implemented, we will see a simplified program, including inventory, customer and order entity (a company offers a number of goods, customers to buy these goods). Our initial analysis determines that three commercial objects are needed to perform these entities. There will be three classes in our Delphi program: TstockItem, TCustomer and Torder. The public interfaces of these classes are shown in Listing 1. Here, it is important to indicate that these classes are exposed to the outside by properties: this is a simple and beneficial type design and controls external access by attribute control. There is also these properties should be in the Published area of the class (whose reason will be mentioned later) and is assigned to the appropriate default default value. Although these attributes are limited only when the fluid class is used, the code is given to each attribute and make the code more descriptive.
First class frame
In the initial phase of the development program, we have identified and implemented three commercial objects. These three objects play a common role: perform real-world entities through some way. So we want them to have similar properties and appropriate levels with their real-world entities. We will give each object a common base class called TPDObject (Problem Domain Object). Over time, we will join public methods and properties in this class, TPDObject will continue to expand. It should be noted that TPDObject does not (never) have any elements related to a specific program. As a program-independent class, it will place a separate unit and form a framework for the frame: a group can be reused in many programs. In the latter, our framework will have a large extension, forming a base class that provides important procedures and can be quickly used for specific systems. We tstockItem, TCustomer and Torder are custom objects from TPDObject as a specific system.
TMYApppdObject is a inheritance class of TPDObject, although its implementation is empty, but it is a good demonstration; if we add certain elements in a specific program, it affects all the problem domain classes in the program, this The class level should be relatively appropriate. The initial code of the framework is listed in the list. Class TPDObject also provides only a read-only attribute ID, which is TOBJECTID. This attribute gives an identifier for each object: we will think of two instances of the same type and ID as the same object. Here ID is intentionally declared for your own type to avoid the value directly assigned to other standard types. Type of TOBJECTID has not passed special choice: I have selected plastic here, and it may also be a special class in a particular situation. Although it is a more pure surface-phase object, based on our problem domain class, it is not allowed to be a thousand times of consideration, and I don't do this in order to avoid additional loads when I have an additional load. (As a pureist, I put the TOBJECTID contained the object in TPDObject as a composite object). There is a pair of functions in your code for converting strings and our object identification type, and has a constant as an initial value when it is not assigned. There are many classrooms that will be mentioned to object identity: Some said that all business objects should be given to a program that is not repeated within a program (even GUID). In fact, it is really important to distinguish between a given context, and maintain this simplicity will have a significant benefit on performance and storage space. Questions about the norms:
In order to enhance some ideas and designs of design, I will mention some problems, please read what the basic principles behind them are. I have mentioned that the true object-oriented design is not prohibited from using a specific class, but there is a very important exception. What is this exception (the answer is in Figure 1)
((Listing 1 - An Application-Specific Problem Domain Unit (Abridged)))))))))
UNIT problemdomain;
Interface
Uses
Framework;
Type
TMYAppPdObject = Class (TPDObject)
END;
TSTOCKITEM = Class (TMYApppdObject)
Published
Property name: String;
Property QuantityInstock: cardinal default 0;
Property TRADEPRICE: CURRENCY;
Property retailprice: currency;
END;
TCUSTOMER = Class (TMYAppPdObject) ...;
Torder = Class (TMYApppdObject) ...;
IMPLEMENTATION
End.
((End Listing 1))))))
((Listing 2 - An Application-Independent Framework Unit))))
UNIT Framework;
Interface
Const
NOTASSIGNED = 0;
Type
TOBJECTID = TYPE INTEGER;
TPDObject = Class
Private
FID: TOBJECTID;
public
Property ID: TOBJECTID Read FID Default NOTASSIGNED;
END;
Function Strtoid (Value: String): TOBJECTID;
Function IDTOSTR (Value: TOBJECTID): String;
IMPLEMENTATION
...
End.
((End Listing 2)))))))
(1) SSADM (Structured Systems Analysis & Systems Design) is the 1981 British government's central computer and telecommunications agent Agency, a referorbility CCTA; network station:
http://www.ccta.gov.uk
The Software Analysis Design Standard Method of Developed Software.
Philip Brown is a systems design consultant and active developer, presenter, and trainer. He'll promote the benefits of strong OO techniques to deliver better applications given any opportunity. You can contact him at
phil@informatica.uk.com
.
Related resources: Delphi object-oriented programming
