Outline 07: Classes and Objects, Revisited

Held: Tuesday, 9 September 2014

Summary

We continue to explore the construction of classes in Java.

Related Pages

Overview

Administrivia

Surveys!
Because of confusions raised yesterday, we'll spend some time debriefing on the lab. We'll move on to arrays tomorrow.
Reminder: I am happy to receive questions via email or via the anonymous Google question form. (I'll often respond via class email or these daily announcements.)

Convo Wednesday at noon. "Limiting Armed Drone Proliferation" by Micah Zenko, the Douglas Dillon fellow in the Center for Preventive Action at the Council on Foreign Relations and vice chair of the World Economic Forum Global Agenda Council on Terrorism.
- Sam's comments on the value of convo
Any other event in the Rosenfield Drones program.
CS Extra, Thursday, September 11: Ajuna Kyaruzi '17 on being a SysAdmin
CS Table, Friday, September 12: Socially-Assistive Robots Help Children with Autism

Second-year students get extra credit for doing the second-year science retreat on Sept. 20.

Thinking with Objects

In yesterday's lab, you saw something potentially surprising: When we're doing operations on two values, we often ask the first value to do the computation.
For example, to multiply two BigInteger values, a and b, you use a.multiply(b) rather than a * b or BigInteger.multiply(a,b).
In order to write such functions, we need to refer to the fields of the current object. We do so by prefixing each field with this.

Conventions:
- Field names begin with lowercase letters and use camelCase.
- Method names begin with lowercase letters and use camelCase.
- Class names begin with Uppercase letters and use CamelCase.
- Constant names are ALL CAPS and use underscores.
- Package names are all lowercase and hierarchical.
We do not use "prefix" conventions to provide type or role information. (Some folks use m_name for fields, where m_ indicates "member".)
- In Clean Code, Robert Martin says "You also don't need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don'ta need them. And you should be using an editing environment that highlights or colorizes members to make them distinct. Besides, people quickly learn to ignore the prefix (or suffix) to see the meaningful part of the name. The more we read the code, the less we see the prefixes. Eventually, prefixes become unseen clutter and a marker of older code."