| ITEC 120 |
| 2008spring |
| ibarland, jdymacek |
|
|
|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
We have seen that Objects are a way of bundling together multiple pieces of data (say a salary, a bank-balance, and a name) along with functions which work on that data. People use different terms for these things, but they all mean the same thing: Objects are:
history:For each of the following, what fields might the class have? What methods?The term object-oriented programming now starts to make some sense. If you're kickin' it old school, programmers (pre 1990 or so) would bundle their data together just like we are now doing, but they'd call them “structures” instead of “classes”. And there'd be no methods -- there'd just be regular old functions which took in a structure as input, and might return a structure (new, or modified). This is known as procedural programming.
In comparison, object-oriented programming lets you have a place for not just the data, but all the pertinent methods for a piece of compound data. In the last week of the course, we'll glimpse the true additional power of object-oriented programming, when we introduce “inheritance”.
By the way, we'll see later that fields can be not just a primitive or built-in type (like int or String, resp.), but also any class we define. So a class FootballGame might contain two fields of type FootballTeam, where each FootballTeam contains (in turn) both a name and many fields of type FootballPlayer, where FootballPlayer is a class which would contain … and so on.
Using classes gives us a natural way to think about how to organize our data (namely: in a way which reflects how we humans conceive/organize the topic). Once we have the data well-organized, then writing the methods follows.
Discuss from lab: MINIMUM_WAGE. Where to put this, so it can be used by several methods? What are the advantages to naming this?
Looking ahead: This violates our previous statement that fields should only be information which is inherently part of the object -- information which separates one PizzaServer from another. We'll see next week, that named constants will be static fields: fields which actually belong to the class (blueprint) rather than having a copy within each individual object. We'll see that Math.PI and Integer.MAX_VALUE are such named constants.
Other constants in PizzaServer: CRUST_WIDTH, CENTS_PER_SQ_IN. Note that this last one (which was 3.0, and then later modified to 3.14) can now be clearly distinguished from Math.PI.
We can also review some lab solutions.
Practice
Suppose that some
Emcees (from lab)
can become a bit crazy,
and even when asked to give a normal (non-spy) introduction,
they still give the same answer they would
for a spy introduction.
(Initially, all Emcees are created sane.)
What is the additional state, for Emcee?
What sort of field would represent this?
Add that, along with a getter and setter.
(Test them, of course.)
Change your introduce method
so that depending on their sanity,
the Emcee gives either a normal
or spy introduction.
Optional practice:
Giving spy introductions is a bit addictive.
Make it so that a sane Emcee goes
a bit wacky after the first time they make a spy introduction.
Note that your test situations are much more involved:
You'll have to make an Emcee,
and call several methods, specifying the expected output
each time.
Challenge practice:
Even if an Emcee is a bit wacky,
after being requested to make 3 normal introductions
in a row they will become sane again.
What is the additional state, which every Emcee
must now keep track of?
Add that state, and implement this feature.
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
| ©2008, Ian Barland, Radford University Last modified 2008.Feb.27 (Wed) |
Please mail any suggestions (incl. typos, broken links) to iba�rland  rad�ford.edu |
 |