|
|
| (37 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | == General ==
| + | #REDIRECT [[Object Oriented Programming with Free Pascal and Lazarus#Free Pascal Language Extensions]] |
| − | | |
| − | FPC includes several language provisions to code in an object oriented manner.
| |
| − | | |
| − | * Objects (chapter 5)
| |
| − | * Classes (chapter 6)
| |
| − | * Interfaces (chapter 7)
| |
| − | * Generics (chapter 8)
| |
| − | | |
| − | These provisions are described in the indicated chapters of the FPC Language Reference Guide: http://www.freepascal.org/docs.var Here you will find syntax diagrams and further information not contained in this introductory guide. Of these four language features, Objects and Classes form the basis of object oriented programming (OOP) in FPC and for Lazarus.
| |
| − | | |
| − | OOP provides different ways to manage and encapsulate data and to manage program flow compared with other available programming language features. This method of programming often lends itself to modeling certain applications such as Graphic User Interfaces and physical systems in a more facile manner. However it is not appropriate for all applications. Program control is not as explicit as using the more standard Pascal procedural constructs and to get the most benefit of OOP, understanding of large class libraries is often required. Also, maintaining large OOP application code has its advantages and disadvantages compared to maintaining procedural code. There are many sources for learning OOP and OO design which are beyond the scope of this guide.
| |
| − | | |
| − | There are a lot of programming languages which incorporate OOP features as extensions or the basis of their language. As such, there are many different terms for describing OO concepts. Even within FPC, some of the terminology overlaps. In general, OOP usually consists of the concept of a programming object (or information unit) which explicitly combines and encapsulates a set of data and procedural code which are related. Usually, this data is persistent during program execution without having to be declared globally. In addition, there are usually features which enable additional objects to be incrementally modified and/or extended based on previously defined objects which is usually referred to by the term "inheritance." Many languages refer to the procedures which belong to an object as an object "method." Much of the power of OOP is realized by late dynamic binding of methods at run time rather than at compile time. This dynamic binding of methods is similar to using procedural variables and procedural parameters but with greater syntactic cohesion with the data it is related to.
| |
| − | | |
| − | | |
| − | == Objects - Basics ==
| |
| − | | |
| − | Of the two OOP implementations FPC provides, the one used less often seems to be what is referred to as "Objects" which probably gets its name from the type definition syntax. The syntax diagram for an object type declaration can be found in the FPC language reference - Chapter 5. Basically, an '''object''' type looks like a '''record''' type with additional fields including procedure fields and also optional keywords which indicate the scope of the fields. In fact, an oversimplified (but valid) simple object is hard to distinguish from a record structure as can be seen below.
| |
| − | | |
| − | <delphi>
| |
| − | Type
| |
| − | MyObject = Object
| |
| − | f_Integer : integer;
| |
| − | f_String : ansiString;
| |
| − | f_Array : array [1.3] of char;
| |
| − | end;
| |
| − | </delphi>
| |
| − | | |
| − | The only difference in the above example is that the Pascal keyword '''record''' has been replaced with the keyword '''object'''. When things start to be different are when methods are added to the object. Object methods are declared in FPC using the keywords '''procedure''' or '''function'''. These object methods (procedures or functions) are declared the same way as normal Pascal procedures and functions; just that they are declared within the object declaration itself. Lets create a different object; this time possibly as part of an oversimplified graphics drawing program.
| |
| − | | |
| − | <delphi>
| |
| − | Type
| |
| − | DrawingObject = Object
| |
| − | x, y : single;
| |
| − | height, width : single;
| |
| − | procedure Draw;
| |
| − | end;
| |
| − | | |
| − | Var
| |
| − | Rectangle : DrawingObject;
| |
| − | </delphi>
| |
| − | | |
| − | Besides the simple datatype fields providing some application specific location and size attributes, the object shown above declares an additional parameter; a procedure called ''Draw.'' The type declaration is followed by a variable identifier called ''Rectangle'' of the type ''DrawingObject''. Next, the ''Draw'' procedural code itself needs to be written as well as well as code for accessing and manipulating the data fields, as well as how to invoke the Draw procedure. The following simple program shows how all this works. It should compile and run on any system with FPC 2.2.2 and above. Note: For Mac OS X, the -macpas compiler directive must be turned off.
| |
| − | | |
| − | <delphi>
| |
| − | Program TestObjects;
| |
| − | | |
| − | Type
| |
| − | DrawingObject = Object
| |
| − | x, y : single;
| |
| − | height, width : single;
| |
| − | procedure Draw; // procedure declared in here
| |
| − | end;
| |
| − | | |
| − | procedure DrawingObject .Draw;
| |
| − | begin
| |
| − | writeln('Drawing an Object');
| |
| − | writeln(' x = ', x, ' y = ', y); // object fields
| |
| − | writeln(' width = ', width);
| |
| − | writeln(' height = ', height);
| |
| − | writeln;
| |
| − | // moveto (x, y); // probably would need to include a platform dependent drawing unit to do actual drawing
| |
| − | // ... more code to actually draw a shape on the screen using the other parameters
| |
| − | end;
| |
| − | | |
| − | Var
| |
| − | Rectangle : DrawingObject;
| |
| − | | |
| − | begin
| |
| − | | |
| − | Rectangle.x:= 50; // the fields specific to the variable "Rectangle"
| |
| − | Rectangle.y:= 100;
| |
| − | Rectangle.width:= 60;
| |
| − | Rectangle.height:= 40;
| |
| − | | |
| − | writeln('x = ', Rectangle.x);
| |
| − | | |
| − | Rectangle.Draw; // Calling the method (procedure)
| |
| − | | |
| − | with Rectangle do // With works the same way even with the method (procedure) field
| |
| − | begin
| |
| − | x:= 75;
| |
| − | Draw;
| |
| − | end;
| |
| − | | |
| − | end.
| |
| − | </delphi>
| |
| − | | |
| − | As can be seen in the above program, the body of the ''Draw'' method (procedure) is declared after the object type declaration by concatenating the type identifier with the procedure name. In a more realistic situation, the object would likely be declared in the '''interface''' section of a separate unit while the procedure body would be written in the '''implementation''' section of the same external unit. In this example, only standard vanilla Pascal is used, but if actual graphic primitives are available, they can be used if desired. The second thing to notice is that inside the ''Draw'' method (procedure), the object's data fields are referenced as if they were regular local variables. The only difference to regular local variables is that the values of these fields will persist between calls to the ''Draw'' procedure.
| |
| − | | |
| − | In the main program, the fields are assigned values and accessed just like record fields are. Similarly, the ''Draw'' procedure is invoked using the same dot notation as the fields. And like records, the '''with''' keyword works the same for accessing object fields and invoking methods. Finally, notice that the second time the '''Draw''' method is called, all the fields persisted between calls; the only field different is the x attribute which was explicitly changed.
| |
| − | | |
| − | The above example is meant to show the basic mechanics of simple '''Objects'''. There are a couple of problems, however. The first problem is that the '''Draw''' method only draws one thing and that is a rectangle (although even that is questionable.) Additional methods could be declared in the '''DrawingObject''' object such as DrawRectangle, DrawCircle, DrawTriangle, etc..., but this would not be too much different than declaring separate regular procedures and having to use '''case''' statements to select the appropriate procedure. So doing it this way with objects would require more work (and is not how it is accomplished.) The other problem is, the object's fields are able to be accessed and modified anywhere in the program very similar to using global variables which makes it harder to write well encapsulated and robust programs. These problems will be addressed in the next section.
| |
| − | | |
| − | == Objects - Inheritance and Better Encapsulation ==
| |
| − | | |
| − | under construction
| |
| − | | |
| − | == Classes ==
| |
