Topic: "Encapsulation is the division of a program into distinct components which have limited interaction."

Discussion Notes

Revised 9/4/2010

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?

1.1 Software Development

Good programs are:

• correct
• efficient
• clear, maintainable
• general purpose
• rapidly developed

Comments:

• Any disputing of these claims?
• Are all good programs correct? Completely correct?
• How much general-purpose should a program be?
  • Does the program itself need to be general purpose, or built from general purpose components?
  • And is this to reduce the cost of development?
• Rapid development also is to reduce cost.
• Rapid development could also mean if we need the program now, can we have it now please?

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?

• Where are the objects?
• Object = bundle of data and functions (Java: fields and methods)

Does encapsulation seem like a good idea?

• Division of labor analogy
• Especially good for projects with multiple developers
• Information hiding = enforcement of encapsulation (not a certain operating system's "security by obscurity"!)
• Of course, we can carry a good thing too far.

Software engineering (p. 7): how to develop programs that are correct, efficient, general, in reasonable time.

• Compare Software Engineer, System Analyst, Programmer.

The software development cycle (p. 7):

Design → implement → test → back to beginning

• [But we could actually loop back to implementation.]
• Design:
  • Problem specification
  • Breakdown of program into components, such as objects or functions
• Implementation = writing the code
• Testing = run the program to verify that it works as desired (correctly, efficiently, etc.)
• Maintenance = more of the same, after program is in production or "released" (redesign, re-implement, retest)

Alternative design strategies:

• Top-down
• Bottom-up
• In between
• [All at once? Since in some sense we have to be thinking about both ends at once.]

Discussion: pp. 8–9, Exercises 1.1–1.5

1.2 Classes and Objects

Distinguish between classes and instances

Distinguish between fields, methods, and constructors

What are the default initial values of Java fields?

• Zeroish: 0, 0.0, false, character 0, null
• Avoid relying on default initialization

What are the default initial values of local variables in Java methods?

• None. It is an error to use an uninitialized local variable.
• Why are instance variables and local variables different? Is this a good design?

What are static fields and methods?

• Why must every program have at least one static method?

What are private and public?

• What do we normally make private?

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.

• We can (almost) always have a program that works, at least to some small extent.
• Alternative of monolithic development
• A program that won't compile (so it won't run) is useless!

Example

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.

• Solution (2012 Aug 29): SavingsAccount.java

1.3 Using Objects

toString

• The role of the toString method
• Example: continue the bank savings account class, adding a toString method.

Assertions

• Form of assertion:

  assert <booleanexpr>: "<message>";

• Compile as usual
• Run with java -ea MyClass

• Continuing the bank savings account class, add an assertion such as that balance ≥ 0, run with assertions enabled and test.

Lab 1

• Instructions
• Overview, Q & A