Page 109 of 229 Start Back Next End ZBasic Language Reference 99 ZBasic Microcontrollers Chapter 4 - ZBasic Object-Oriented Extensions The purpose of the object-oriented extensions for ZBasic is to bring the benefits of object-oriented programming - inheritance, polymorphism, and encapsulation - to ZBasic users. Although ZBasic historically has been derived from Microsoft Visual Basic (VB6), the decision was made not to implement the VB object-oriented features in ZBasic largely due to its weak implementation of the inheritance model. Since inheritance is one of the primary benefits of object oriented programming, implementing a weak version of it would do a great disservice to ZBasic users, especially those who are getting their first exposure to object-oriented programming. Instead, the realization of ZBasic object-oriented features takes ideas from other, more popular, object-oriented languages (e.g. C++ and Java) and implements them in ways that fit well in the ZBasic language structure. The purpose of this chapter is to briefly describe the important aspects of the ZBasic object-oriented extensions. The intended audience is those who have a basic understanding of object-oriented programming principles. Those who do not meet this qualification should utilize the many print and Internet-based resources on the topic before continuing. 4.1 Enabling Object-Oriented Extensions In order to use the ZBasic object-oriented extensions, you must enable them. This strategy was chosen so that the additional keywords needed by the extensions do not cause existing programs to fail to compile. Enabling the extensions can be achieved by using the directive Option Objects in the first module compiled. Alternately, the compiler option –-objects has the same effect; it must occur on the command line or in the .pjt file before the first .bas file processed. One side effect of enabling object extensions is that it also allows overloaded subroutines and functions to be defined outside of a class. See section 3.19 for more information on procedure overloading. 4.2 Defining a Class The characteristics of an object are described by defining a Class. In many ways, defining a class is very similar to defining a structure in ZBasic. However, instead only of having members that are data items, a class generally will also have members that are subroutines or functions. As with a structure, the members of a class may have either Public or Private visibility attributes. A third visibility attribute, Protected, affords an additional dimension of access control (described later) that is useful when one class inherits characteristics from another class. Similar to defining a Structure, a Class is defined using the Class…End Class sequence. You may define as many classes in a module as you wish. A private class cannot be used by code in other modules while a public class can be. [Public | Private] Class <name> <member-definition> ... End Class The ellipsis in the syntax above connotes that there may be zero or more additional member definitions. As with structures, if neither Public nor Private is specified, the class will be public, meaning that it will be visible outside of the module in which it is defined. After a class is defined, its name may be used as the type in a variable definition. Consider this simple example. Public Class myClass Dim i as Integer Dim s as String End Class A <member-definition> that describes a data member has the same syntax as that used to define a variable. As with an ordinary variable, a member may be a single data element or it may be an array.