Topic: "Encapsulation is the division of a program into distinct components which have limited interaction."
Every book on OOP mentions (and tries to explain) the three magic words 'encapsulation', 'polymorphism', and 'inheritance'.
The definition on p. 5 is the clearest I have seen yet:
Encapsulation is the division of a program into distinct components which have limited interaction.
Substitute 'system' for 'program' and we have a more general definition.
Can we think of examples of encapsulation not involving software?
Information hiding is intimately related to encapsulation, but slightly different. What is it?
"Information hiding enforces encapsulation." (p. 6)
I.e., information hiding is the encapsulation police.
Just as we could have a rule for drivers that you must stop for a red light (corresponding to encapsulation), we could take two attitudes towards how to make this work. We could just rely on everyone's good will and trust them to stop at red lights. Or we could hire a police force and have them catch people who drive through red lights.
Or you could have a rule that only designated people are to go into the room that says "authorized personnel only." And you could either trust people to obey the rule, or you lock the room and hire guards to protect it.
Likewise in software encapsulation. We can write encapsulated programs using Python classes. And as long as we honor the intended encapsulation, everything is fine. But Python does not enforce encapsulation (much). Any programmer is free to reach into the inner workings of a class.
Java on the other hand does provide encapsulation police, with two officers named private and protected. They stand at the doors of a class's internals and keep busybodies out.
So it is interesting that the designers of Python and Java had very different attitudes towards programmers. The Python view is that we can trust programmers to observe the conventions of encapsulation. The Java view is that we can't trust programmers.
Which do you believe? Or when do you believe one, and when the other?
Good programs are:
We study algorithms, which are not programs. Algorithms are the meanings of programs. Programs express algorithms in a particular programming language.
Encapsulation = "division of a program into distinct components which have limited interaction"
We frequently here that OOP = encapsulation + polymorphism + inheritance (see. p. 5), but does this really capture the essence of OOP?
Does encapsulation seem like a good idea?
Software engineering (p. 7): how to develop programs that are correct, efficient, general, in reasonable time.
The software development cycle (p. 7):
Design → implement → test → back to beginning
Alternative design strategies:
Discussion: pp. 8–9, Exercises 1.1–1.5
Distinguish between classes and instances
Distinguish between fields, methods, and constructors
What are the default initial values of Java fields?
What are the default initial values of local variables in Java methods?
What are static fields and methods?
What are private and public?
What are accessors and mutators (a.k.a. getters and setters)? Why do we use them?
Incremental development principle (p. 13, top): test early and often, attribute errors to recent changes, incremental change.
Develop incrementally in the classroom: a Java class representing a bank savings account. The account should have an account number and a balance. Define a constructor. Define an accessor but not a mutator for account number (which should be immutable). Define an accessor and mutator for balance—or should we do better and define withdraw and deposit methods? Incrementally define a main method for testing.
Form of assertion:
assert <booleanexpr>: "<message>";
java -ea MyClass
Continuing the bank savings account class, add an assertion such as that balance ≥ 0, run with assertions enabled and test.