This document contains a short introduction to component-based programming involving the use of the NaturalX interface and a dedicated set of Natural statements.
The following topics are covered:
Software applications that are based on component architecture offer many advantages over traditional designs. These include the following:
Faster development. Programmers can build applications faster by assembling software from prebuilt components.
Reduced development costs. Having a common set of interfaces for programs means less work integrating the components into complete solutions.
Improved flexibility. It is easier to customize software for different departments within a company by just changing some of the components that constitute the application.
Reduced maintenance costs. In the case of an upgrade, it is often sufficient to change some of the components instead of having to modify the entire application.
Easier distribution. Components encapsulate data structures and functionality in distributable units.
Using NaturalX you can create component-based applications.
You can use NaturalX in conjunction with DCOM. This enables you to:
allow your components to be accessed by other components,
execute these components on local and/or remote servers,
access components written in a variety of programming languages across process and machine boundaries from within Natural programs,
provide your existing Natural applications with (quasi) standardized interfaces.
The following scenario illustrates how a company could exploit these advantages. A company introduces a new sales management system that is based on an application design using components. There are numerous data entry components in the application, one for each sales point. But all of these sales points use a common tax calculation component that runs on a server. If the tax legislation is changed, then only the tax component has to be updated instead of changing the data entry components at each site. In addition, the life of the programmers is made easier because they do not have to worry about network programming and the integration of components that are written in different languages.
This section covers the following topics:
NaturalX follows an object-based programming approach. Characteristic for this approach is the encapsulation of data structures with the corresponding functionality into classes. Encapsulation is a good basis for easy distribution. Because there are (quasi) standards for the interoperation of software components on the basis of object models, an object-based approach is also a good basis for making software components interoperable across program, machine and programming language boundaries.
In an object-based application, each function is considered to be a service that is provided by an object. Each object belongs to a class. Clients use the services either to perform a business task or to build even more complex services and to provide these to other clients. Hence the basic step in creating an application with NaturalX is to define the classes that form the application. In many cases, the classes simply correspond to the real things that the application in question deals with, for example, bank accounts, aircraft, shipments etc. There is a wide range of good literature about object-oriented design, and a number of well-proven methods can be used to identify the classes in a given business.
The process of defining a class can be broadly broken down into the following steps:
Create a Natural module of type class.
Specify the name of the class using the
DEFINE CLASS
statement. This name will be used by the clients to create objects of that
class.
Use the OBJECT clause of the
DEFINE DATA
statement to define how an object of the class will look internally. Create a
local data area that describes the layout of the object with the data area
editor, and assign this data area in the OBJECT clause.
These steps are described in more detail in the section Developing Object-Based Natural Applications.
In order to be useful to clients, a class must provide services, which it does through interfaces. An interface is a collection of methods and properties. A method is a function that an object of the class can perform when requested by a client. A property is an attribute of an object that a client can retrieve or change. A client accesses the services by creating an object of the class and using the methods and properties of its interfaces.
The process of defining an interface can be broadly broken down into the following steps:
Use the INTERFACE clause to specify an interface
name.
Define the properties of the interface with PROPERTY
definitions.
Define the methods of the interface with METHOD
definitions.
These steps are described in more detail in the section Developing Object-Based Natural Applications.
Simple classes only have one interface, but a class may have more than
one interface. This possibility can be used to group methods and properties
into one interface that belong to the same functional aspect of the class and
to define different interfaces to handle other functional aspects. For example,
an Employee class could have an interface
Administration that contains all of the methods and
properties of the administrative aspects of an employee. This interface could
contain the properties Salary and
Department and the method
TransferToDepartment. Another interface
Qualifications could contain the qualification aspects
of an employee.
Defining several interfaces for a class is the first step towards using
interface inheritance, which is a more advanced method of designing classes and
interfaces. This makes it possible to reuse the same interface definition in
different classes. Assume that there is a class Manager,
which is to be treated in the same way as the class
Employee with respect to qualification, but which is to
be handled differently as far as administration is concerned. This can be
achieved by having the Qualification interface in both
classes. This has the advantage that a client that uses the
Qualification interface on a given object does not have
to check explicitly whether the object represents an
Employee or a Manager. It can
simply use the same methods and properties without having to know of what class
the object is. The properties or methods can even be implemented in a different
way in both classes provided they are presented through the same interface
definition.
The process of using interface inheritance can be broadly broken down into the following steps:
Use the INTERFACE statements to define
one or more interfaces in a copycode instead of defining them directly in the
class.
The METHOD and PROPERTY definitions in the
INTERFACE statement do not need to contain the IS
clause. At this point, you just define the external appearance of the interface
without assigning implementations to the methods and properties.
Use the INTERFACE clause to include the copycode with
its interface definition in each class that will implement the interface.
Use the METHOD and
PROPERTY statements
to assign implementations to the methods and properties of the interface in
each class that will implement the interface.
