Java Reference
In-Depth Information
such an object, and how much memory and processing time gets chewed up trying to make a temporary
copy for every method that gets that object as an argument? And what happens if we use such an object
recursively (that is, the object can modify itself)? If you think about those issues for a minute, you see
why objects are passed as references (that is, as memory addresses). Otherwise, Java programs would be
substantially harder to create and perform more poorly than they could.
Summary
Many topics have been written (and no doubt more topics will be written) on object modeling. It's a
fundamental part of object-oriented programming, and it's easy to fall into bad practices. Mastering
object modeling requires both experience and study: experience to see how object models actually work
and study to be aware of the issues. This chapter presents one simple example (a few members of the
animal kingdom), but it's by no means a complete treatment of object modeling.
Along the way, we learned when to use abstract classes, static and final methods, and static fields.
We also learned why we generally want fields to be private and have get methods rather than having the
field be visible outside the class.
We also learned a bit about the value of granular programming (also known as “chunking” and
modularity and many other similar names). Remember to “chunk” your programs into classes and
interfaces, both to make them easier to understand and to make them easier to debug when problems
arise.
Finally, we dove into the thorny theoretical issue of pass-by-reference versus pass-by-value. In
particular, we learned that Java is strictly pass-by-value. However, some of those values are pointers
(that is, memory addresses at which objects reside). Consequently, modifying an object that has been
passed modifies the original object, whereas modifying a primitive modifies only a local copy of the
primitive rather than the original.
