UNPKG

epubjs

Version:

Render ePub documents in the browser, across many devices

54 lines (53 loc) 5.57 kB
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapter 5. Objects in Java</title><link rel="stylesheet" href="core.css" type="text/css"/><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"/></head><body><div class="chapter" title="Chapter 5. Objects in Java"><div class="titlepage"><div><div><h1 class="title"><a id="learnjava3-CHP-5"/>Chapter 5. Objects in Java</h1></div></div></div><p><a id="I_indexterm5_id688456" class="indexterm"/>In this chapter, we get to the heart of Java and explore the object-oriented aspects of the language. The term <span class="emphasis"><em>object-oriented design</em></span> refers to the art of decomposing an application into some number of objects, which are self-contained application components that work together. The goal is to break your problem down into a number of smaller problems that are simpler and easier to handle and maintain. Object-based designs have proven themselves over the years, and object-oriented languages such as Java provide a strong foundation for writing applications from the very small to the very large. Java was designed from the ground up to be an object-oriented language, and all of the Java APIs and libraries are built around solid object-based design patterns.</p><p>An object design “methodology” is a system or a set of rules created to help you break down your application into objects. Often this means mapping real-world entities and concepts (sometimes called the “problem domain”) into application components. Various methodologies attempt to help you factor your application into a good set of reusable objects. This is good in principle, but the problem is that good object-oriented design is still more art than science. While you can learn from the various off-the-shelf design methodologies, none of them will help you in all situations. The truth is that there is no substitute for experience.</p><p>We won’t try to push you into a particular methodology here; there are shelves full of books to do that.<sup>[<a id="learnjava3-CHP-5-FNOTE-1" href="#ftn.learnjava3-CHP-5-FNOTE-1" class="footnote">12</a>]</sup> Instead, we’ll provide some common-sense hints to get you started. The following general design guidelines will hopefully make more sense after you’ve read this chapter and the next:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Hide as much of your implementation as possible. Never expose more of the internals of an object than you need to. This is key to building maintainable, reusable code. Avoid public variables in your objects, with the possible exception of constants. Instead define <a id="I_indexterm5_id688536" class="indexterm"/><span class="emphasis"><em>accessor</em></span> methods to set and return values (even if they are simple types). Later, when you need to, you’ll be able to modify and extend the behavior of your objects without breaking other classes that rely on them.</p></li><li class="listitem"><p>Specialize objects only when you have to—use <span class="emphasis"><em>composition</em></span> instead of <span class="emphasis"><em>inheritance</em></span>. When you use an object in its existing form, as a piece of a new object, you are <span class="emphasis"><em>composing</em></span> objects. When you change or refine the behavior of an object (by <span class="emphasis"><em>subclassing</em></span>), you are using <span class="emphasis"><em>inheritance</em></span>. You should try to reuse objects by composition rather than inheritance whenever possible because when you compose objects, you are taking full advantage of existing tools. Inheritance involves breaking down the encapsulation of an object and should be done only when there’s a real advantage. Ask yourself if you really need to inherit the whole public interface of an object (do you want to be a “kind” of that object?) or whether you can just delegate certain jobs to the object and use it by composition.</p></li><li class="listitem"><p>Minimize relationships between objects and try to organize related objects in packages. Classes that work closely together can be grouped using Java packages, which can hide those that are not of general interest. Only expose classes that you intend other people to use. The more loosely coupled your objects are, the easier it will be to reuse them later.</p></li></ul></div><div class="footnotes"><br/><hr/><div class="footnote"><p><sup>[<a id="ftn.learnjava3-CHP-5-FNOTE-1" href="#learnjava3-CHP-5-FNOTE-1" class="para">12</a>] </sup><a id="I_indexterm5_id688495" class="indexterm"/><a id="I_indexterm5_id688501" class="indexterm"/><a id="I_indexterm5_id688506" class="indexterm"/><a id="I_indexterm5_id688512" class="indexterm"/>Once you have some experience with basic object-oriented concepts, you might want to look at <span class="emphasis"><em>Design Patterns: Elements of Reusable Object-Oriented Software</em></span> by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley). This book catalogs useful object-oriented designs that have been refined over the years by experience. Many appear in the design of the Java APIs.</p></div></div></div></body></html>