Object-oriented programming has a number of touted advantages over traditional structured programming:
When you set out to write a new program, particularly one that will be very large, it is useful to begin with the largest, highest-level of the program's functionality, and then break it down into smaller sub-programs. This will help you to modularize things, but most importantly, it will help you keep sight of the big picture. It is easy to lose sight of the big picture once you find yourself churning out individual lines of code.
When you set out to write a new chunk of code, it is a very good idea to write the comments before you write the code. Why would you want to do this? It can be summed up in one word: Planning. If, before you write a single line of code, you can go through and plot out what you are going to do, it will make it that much easier when the time comes to write the actual lines of code. Furthermore, writing the comments first can help you to spot design flaws in your approach that you might have not been aware of otherwise, once your attention is distracted as you get into the thick of figuring out syntax. (For an example of this, look at page 121.)
It is also important to write your comments in a non-language-specific fashion. By this, I mean that in a C program, for example, there shouldn't be comments that talk about "pointers" (unless the purpose of the comment is to clarify a hunk of confusing syntax). Ideally, you would be able to strip the comments out of a program written in one language, transplant them into a program written in another language, and you wouldn't need to change the wording of the comments. The idea you should be getting here is to write your comments in more abstract, objective, descriptive terms.
The last word on comments, is that whne you write comments, you should tell why you are doing something, and not what you are doing. This is a piece of advice I once received from a supervisor of mine, and it's good advice. This complements the guideline given in the previous paragraph about writing comments in a non-language-specific fashion.
More comment on comments can be found on page 127.
As this pertains directly to Ada, most Ada programs do not need comments because they lines of code you write are already so long and descriptive that there's simply no need to explain it further. Up to you to determine if this is good or bad.
Important things in this chapter...
Ada supports the notion of a subtype which allows you to constrain the range of values normally supported by a scalar type. Example:
SUBTYPE LowerCase IS Character RANGE 'a'..'z';
Why use subtypes? Short answer: To help avoid out-of-range problems. See the 'Motivation for Using Subtypes' box at the top of page 118.
The NULL keyword is just an "empty" statement. This allows you to, say, pass an argument which is devoid of value to a function (or as the body of a procedure) to satisfy necessary, required parameters. But if you are only just now learning this concept, you are enrolled in the wrong class.
Definition: Enumeration is the ability to define a fixed-list of non-numeric values. Examples include the days in a week or the months in a year.
TYPE enumeration IS (comma-seperated-list);
Attributes: Enumeration objects (yes, objects) in Ada have some nice features. The nicest of these is Attributes (see p. 130-131). This means that enumeration objects are self-describing because they tell you something about themselves and the items they contain. Remember the theory we talked about earlier? --This is an example of that theory in practice.
I/O: Ada is a little awkward when you want to output an enumerated type, but has some nice built-in validation when you want to input a value. See page 132-3 for the gory details.
Packages: (p. 136) Packages export the follwing resources: Types and subtypes, Procedures, and Functions.
At this point, you will note the new keyword FUNCTION. From our good, old Pascal days, we know that the difference between a procedure and a function is that procedures do not return a value, and functions do.
Callendar Package: (p. 137) Ada provides a Callendar package which allows you to do date processing, and query the computer for the system time. The "Partial Specification of Package Ada.Calendar" shows a good example of a "sample" package. Someday, you will write one of these. You have been warned.
Screen Package: (bottom of p. 145) This package allows you to do quick-and-dirty screen manipulations, like clearing the screen, setting the cursor position, or making the console beep. You can see the package definition on p. 121 and the implementation on p. 122.
Write a program which clears the screen, and then displays the current date in "Day Month 4-digit Year" format in the center of the screen. For example, if today was 09/10/01, you would display the date like so on the screen:
10 September 2001
If you want, you can even make the program beep when it exits.
This assignment is due the night of the first midterm, September 26th.