| home / programming / javascript / gr / column22 / 1 |
  [next] |
|
|
|
By Guyon Roche
In Doodle - Part 2, the Doodle application gained an application framework with the document-view model. In this installment, Doodle starts to connect these components. Not much has changed visually except that once a line is drawn, Doodle allows the user to delete them by clicking on them (this will eventually be extended into a full selection mechanism).
Once again the internal workings of the Doodle code have been upated. The namespace technique has been extended and the Canvas class has gained some new subclasses to keep track of the onscreen objects.
In any large application it's important to use a programming style that's easy to read and maintain. The larger the application, the more important it becomes to impose a solid structure to the programming style. With this in mind, I've chosen a JavaScript class model developed for Preezo which supports single inheritance and simple, tightly bound class definition code.
While it may seem that the new class model has rendered the Doodle code unrecognizable, in practice, very little has changed: where once a class was created like this...
That same class is now created like this...
The new class model is based around the Class factory object contained within the namespace JSX. Its prime objective is to help make class oriented JavaScript programming more convenient. The entire class is bound together within a single object literal passed into the function called JSX.Class.create(). All aspects of the class are easy to find; the internal name of the class is useful for identifying the class by descendant classes, an optional base class, the constructor function, static members and class members typically follow. The most important benefit of this style of programming JavaScript is that all the details of the class are coded close together, useful when an application starts to grow complex with many tens or even hundreds of classes. Another stylistic benefit is that the symbol Doodle.Doc is now formally identified as a class and not just some function instance with a modified prototype.
Where methods were assigned to the class prototype, they're now included within the methods collection, reducing a large amount of the ClassName.prototype cruft.
In general, when making global changes to document-view applications, I find it helps to begin with the document as this is the focus of most of the code in the application.
The following methods (added to the Doodle.Doc methods collection) control access to the shapes collection.
It's generally good coding practice to discourage users of a class from accessing and modifying class or instance member variables directly. Allowing access to member variables creates dependencies on implementation that may be difficult to break later on. It's better to provide functions like the four above that perform the required tasks. This allows the implementation to be changed without much impact on other code.
The next modification is the addition of a class heirarchy for Doodle document shape objects. While the Doodle application supports only one shape (at the moment), it's a good time to set up the structure of a document shape class heirarchy before things get too complicated. The ideal class name for a shape class would be simply "Shape" but there may be other shape oriented classes in the Doodle application that could be called "Shape." This will also be true as we develop the shape heirarchy further with classes like "Line, Ellipse" and so on. The solution here is to use the namespacing technique once more so that the document's shape class will be called Doodle.Doc.Shape and the graphics library's shape will be JSX.Graphics.Shape.
Some readers may notice a passing resemblance to the Java language with its dot-delimited naming heirarchies. One might wonder if enabling this notation was intentional on the part of the JavaScript language designers.
The name field here isn't the fully qualified 'Doodle.Doc.Shape' but simply the short name 'Shape' which descendants from the document shape class will use to uniquely identify this class.
Notice also the "Types" element in the statics collection. The purpose of this is to act as an enumeration of different shape types. Each item in the object literal equates a name with a number. By convention, the name (e.g. LINE) is written in uppercase. Since it's included in the statics collection, the Types enumeration will be added as a property of the Doodle.Doc.Shape class itself and not to the class prototype so it can be accessed easily without requiring a Shape instance. So far there's only one shape type enumeration, but as each new shape type is added, a new enumeration value will be included here.
The Shape class maintains a numerical ID value which will be used to distinguish between different shape instances.
The document Line class now inherits from Shape. Inheritance is specified by adding a base class link in the class definition.
Notice that with the inheritance model used in this code, the Line constructor must call the Shape constructor explicitly since this isn't done automatically by the inheritance model. This gives the Line class the opportunity to choose alternate arguments to be passed to the Shape base class.
| home / programming / javascript / gr / column22 / 1 |
[next] |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: October 13, 2006
Revised: November 29, 2006
URL: http://webreference.com/programming/javascript/gr/column22/1
