Chapter 10, part 2
Working with Instances
To put us back in context, last time we talked about page 448 (banana numbers), where the author discusses passing an object as an argument. He creates a new object:
my_coin = coin.Coin()
This code called the Coin class from the coin library module where the author stored it. In the line below, he passes the name of the new object to a function:
The text explains that passing the object as an argument does not pass the value of the object, which would happen with a regular variable. What actually happens is that the function being called will receive a reference (also called a pointer) to the real object. Anything the function does will affect the actual object, not a copy. This means that the function receiving the argument could call any of the accessor methods of the object. The text uses the next ten pages to discuss saving objects in dictionaries and saving them in pickle files. It also introduces using the dictionaries you might create in an application that is accessed through a menu in program 10-19, which is in a gray section of the chapter. It goes through several stages of development, and output of the "final" version is shown at the end of the section. (No program is ever in a final version.)
Techniques for Designing Classes
In the last major section of the chapter, the text gives us some perspective on how to plan classes, and how to decide what classes we need in a program. This kind of advice was not offered for any other data structure in the book, so this is a surprise. The author gives us a quick introduction to using UML, Unified Modeling Language, which he uses to diagram the class he is designing. This kind of chart can be created in Lucid Chart, which is accessible through your Baker emailbox. I will show you how to access it in class, if you have forgotten.
The basic diagram that appears in the text is a starting point. We see a box with three sections. The top section has the name of the class. The middle section has the attributes of the class. The bottom section has the methods of the class In a real diagram for a program, such as the one below, you would expect to see multiple classes and their interactions.
Note: in the chart above, each attribute and method is marked with a plus sign. This is to show the visibility of that attribute or method. The chart below, from Wikipedia, shows the meaning of the plus signs, and the meaning of several other notations that stand for other kinds of visibility.
The text turns to a discussion of determining what classes you need in a project. It starts out quite simply: get a written description of the problem, including what happens in the business practices the problem entails. Then, go through that description, looking for nouns. Look at the Lucid chart above. The name of each class in it is a noun that was found in the kind of survey the book is talking about. Of course, the name of something is always a noun. The point is to find all the "somethings" in this project that should be represented as objects. If there will be multiple instances of any object, there should be a class that lays out how the object should be created.