Objects and State¶
This module is where you stop writing lists of instructions and start building things that hold their own data. By the end you can take a description of a problem, decide what the objects are, write them so they cannot be put into an invalid state, and hold many of them.
Everything that follows in this course rests on these four weeks. Inheritance, testing, files and the final application all assume you can look at a problem and see the things in it. That skill is the actual subject of Module 1, and the Java syntax is just how you write it down.
How a week works¶
Four hours, split in two.
The lecture, two hours. Two sessions of fifty minutes, the pages below, plus live coding. Read them with the editor open rather than on your phone.
The seminar, two hours. Where you write code yourself, on a different problem: the university system. Following a worked example teaches you the syntax. Building something you have not been shown teaches you the skill, and the skill is what the exam and the sprints ask for.
The slides, as a PDF. Everything shown in the lecture, including the diagrams. They are the summary, not the explanation. The pages carry the reasoning, the slides carry the pictures.
Week 1. Seeing objects¶
-
Thinking in things
Cutting a problem into things that know something and can be asked to do something. No code at all.
-
Why objects
What breaks when a rule lives away from its data, and exactly what Java adds to the C you already know.
-
Setting up and designing
Get your machine working, then design the university system on paper before you write a line of Java.
-
Week 1 slides
The cash machine told two ways, the knows and does atom, and ask rather than take.
Week 2. Writing them down¶
-
Your first class
Fields, a constructor, methods and
toString. The first code of the bank you will build all semester. -
What a variable really holds
References, aliasing,
null, and why==on objects almost never answers the question you meant. -
Your first classes
Three classes of your own, from the design you made in week 1.
Seminar opens in week 2.
-
Week 2 slides
One class and three objects, and the picture of what a variable actually holds.
Week 3. Keeping them valid¶
-
Objects that refuse
Invariants, the constructor as a gate, and the difference between a caller asking for too much and a caller passing you nonsense.
-
What belongs to whom
finalfields, immutability, and values that belong to the class rather than to any one object. -
Making them refuse
Go back to your own classes and make them impossible to break.
Seminar opens in week 3.
-
Week 3 slides
The invariant across an object's life, the two kinds of no, and where each value lives.
Week 4. Many of them¶
-
Many objects
Arrays,
ListandArrayList, searching and looping, and what a list of objects actually contains. -
Objects that own other objects
A customer with accounts. Keeping a collection private, and coordinating work without doing it yourself.
-
Connecting the system
Relationships, collections, and objects asking each other for work. Sprint 1 opens.
Seminar opens in week 4.
-
Week 4 slides
A list of arrows, a customer owning its accounts, and reaching in against asking.
One example, growing¶
Every lecture in this module builds the same thing: a small bank. It is a good problem to learn on because everyone already knows the rules, and because those rules are strict. A balance cannot go negative. An account number never changes. Money that leaves one place has to arrive somewhere.
Strict rules are exactly what objects are for.
You are not starting a new project every week. In the lectures you extend the bank. In the seminars you extend the university system, in one folder, in the repository you set up in week 1. In week 4 that folder becomes the starting point for Sprint 1.
All the code written live in the lectures is in the lecture code repository, one folder per week. Read the page first, write it yourself, then compare. Looking at the finished version before you have tried is the fastest way to feel like you understand something you cannot yet do.
By the end of this module you can¶
- Read a description of a system and say what each thing knows, what it does, and what it can refuse
- Decide which of those things deserve to be classes, and say why the others do not
- Explain what a reference is, and predict what happens when two variables point at the same object
- Write a class with private fields, a constructor that refuses bad data, and methods that do one thing
- Tell the difference between an outcome a caller should expect and a mistake a caller should have prevented
- Say whether a value belongs to one object, to the class, or to nobody after the moment it was set
- Hold many objects in a list, search it, and keep it safe from the code outside
A note on reading these pages¶
Type the code rather than copying it. The compiler errors you make are half the lesson and you will not make them by pasting.
Each lecture ends with a task that proves you understood, and a few questions with no answer you can look up. Those questions are what we argue about in the seminar, so arrive with an opinion rather than a correct answer.