Ruby Programming: An Object-Oriented Paradigm
Introduction
This article describes a computer program designed using Ruby and object-oriented principles. All design phases, as well as relevant coding, are outlined, diagrammed, and examined. Each user screen is presented and followed by the Ruby implementation behind the user interface.
In addition to screen samples, the Ruby code used to interact with the screen options is available, along with the code for processing user input (See Appendix A). Another section describes the conversion algorithm by way of pseudocode. Beyond that, a method for compiling and storing an activity log file is presented from a high-level perspective (See Appendix B). Finally, an alternative graphical user interface is included for the purpose of comparative analysis (See Appendix C).
User Interface
The first page is usually the starting point from which the user selects their interaction options. An arbitrary scenario would be international travel software where conversion of units is required. In a program that converts Fahrenheit to Celsius or kilometers to miles, the main page primarily displays the options (See Figure 1).
The intermediate screen for this example follows the main screen in order to carry out the request (See Figure 2). This screen handles the entry and display of information. The content of this screen varies in the sense that switching between specific types of data would require different kinds of messages intended to communicate with the user.
Finally, the last page does not appear on the screen. Instead, it tracks the total number of tasks requested by the user. That information is then stored in a computer file, which resembles a computer screen layout, except that it is recorded inside a log file.
Numerical Analysis
The user begins the process by selecting the option to convert, for instance, temperature in degrees. By pressing the “1” key followed by the “Enter” key, the program will display the message enclosed in angle brackets, or “<>” (See Figure 1).
The next screen requires the user to enter a number representing the temperature, where henceforth, the program converts the number into the requested unit (See Figure 2). Both the user-provided initial value and the program-generated conversion value are then placed in the appropriate position on the screen for viewing. The initial value is displayed in the corresponding field and the conversion value is displayed in the subsequent field. The user may choose to continue entering values for conversion or return to the main screen by selecting “0” to exit from the Conversion Page.
At that point, the user can select other conversion options or, once again, quit the entire program by choosing “0” followed by the "Enter" key (See Figure 1). By selecting the option to quit the program, the program initiates a subroutine to store the user activity into a log file (See Figure 3).
Conversion Algorithm
Once the user has indicated the initial value, the program begins the process.
First, the last character of the input value is checked for the proper unit. That is, when the user enters “F” or “C” as the initial value, the program removes that character to extract the number of degrees. Next, the conversion value is computed. Lastly, the program reloads the Conversion Page along with the initial and calculated value for display.
Note: The formulas for temperature and distance conversion are listed below.
Data Validation
It is expected that the user will make every effort to verify the input prior to and after submission. Nonetheless, the program incorporates several phases of data validation in order to ensure proper initial and final data values.
The program extracts the last character of the initial input value. This character is inspected for alignment with the only two acceptable values, namely, “F” for Fahrenheit or “C” for Celsius.
The alphanumeric character from this phase is stored in memory for display in a later phase of the validation process. Upon completion of this verification step, the program inspects the preceding digits for inclusion within the valid range of 0 through 9.
Once it is determined that all required information has been provided and verified, the program proceeds to the final phase of validation. The program invokes the display function, along with both values, and reprints the Conversion Page. This page now contains the user provided value and the conversion value.
Usage Report
In situations where several conversions are computed, or where patterns of conditions are useful for recordkeeping purposes, the program provides storage of information in a log file (See Figure 3).
In essence, the program maintains the input internally and eventually writes that information to a log file for retrieval. The log file records successive information from a program session and finalizes it with a current date and time, as retrieved from the computer time clock.
As discussed in the section on user data validation, the program similarly performs a verification step after attempting to open, and thereby create, the log file. If the program fails to successfully create the computer file, it merely returns control back to the main routine — without compiling the usage report and without interrupting normal program execution.
Design Principle General
Of course, this computer program could have just as simply been coded in any language without the need for object-oriented principles. A structural programming platform can sufficiently provide the entire framework necessary for implementing the features discussed in this scenario.
The drawback to this design discipline can best be conveyed through one particular example within the airline industry. A modern aircraft can contain instrument panels with a series of switches and gauges. A pilot is trained to operate most of the switches. If he cannot, he will delegate such responsibility to co-pilots in order to adequately control the aircraft. In this model, the principle of object-oriented design is worth considering. In structured design, each one of the conversion functions would probably require a separate and independent procedure.
In object-oriented design, one entity is defined where any and all functionally is encapsulated. In a sense, the entity represents both the basic elements of information, the processing of those elements, and the communication of the entity with the main program. Another way to understand this technique is to view the program as an organism, one with elements and vital functions that collaborate in tandem within a centralized feedback cycle.
Thus, object-oriented design seeks to control all the variables and functions that perform a unique computation, or a set of similar or complementary computations. In this way, the system need only indicate the required functionality and proceed with normal operation until the entity responds with the outcome. The system need not concern itself with the intricacies of logic or memory handling in the completion of program functionality. The entity is invoked, the process runs, and the end product is delivered until the next request, and so forth. The program determines what function to invoke by activating a temporal condition within the program execution.
The closest example of this is a toggle switch.
When such a toggle switch is set, a relative series of events is set into motion and those events persist until the switch is reset. Through such a mechanism, the program can determine which path to take or to avoid during program execution. The condition allows the program to understand the request and subsequently initiate only the relevant functionality.
Formerly, the programmer specified the function to perform and the variables to track the data. Presently, the entity binds and oversees the entire process, variables and procedures, through the condition set forth.
In effect, the program understands the prevailing state of the runtime environment and the proper reaction to invoke based on that particular condition. Another advantage to this method of object-oriented design is that the entity can be efficiently accessed by merely one invocation along with just a few auxiliary steps.
Design Principle Specific
In light of this framework, the travel conversion program has three distinct entities, each with obvious specialization characteristics.
The first is the display entity that prints screen menus and user interaction messages. The second is the conversion entity that oscillates between the conversion of temperature or distance measurements based on a user-specified condition. The third is the storage entity that records the user activity within a log file for retrieval or archival purposes (See Appendix B for a top-down view).
By relegating system functionality in this manner, the main section of the program is tasked with the primary role of iteration and subordination of user requests. This entity manages both integer and text variables as well as methods to apply for retrieval of information.
The Track entity thereby contains the main decision-making routine to manipulate the appropriate variables; not to mention, the proper communication of such variables back to the invocation processes. Nonetheless, the vital core of the Ruby code is evident in the Track entity (See Figure 4, Appendix A).
It is this capability that allows the designer to merely indicate a reference to the entity that, in turn, signals the ensuing chain of events. Meanwhile, the main process continues to cycle through until a new request is provided, or until the current request signals completion of program execution.
In Closing
The alternative paradigm discussed in this segment seeks to differentiate the structured programming method to that of the object-oriented programming discipline.
The object-oriented model offers a more entity-based conceptualization of computer automation against the block-style computer algorithms that are characteristic of the structured model.
The benefit is a highly organized, efficient, and pragmatic software scheme. The end result is a more rigorous, more organic approach to program development and, ultimately, software engineering concepts that meet or exceed the inordinate demands of modern computing.
Appendix A
Appendix B
Appendix C
