Class Design Hints Core Java

Without trying to be comprehensive or tedious, we want to end this chapter with some hints that may make your classes more acceptable in well-mannered OOP circles.

  1. Always keep data private.
    This is first and foremost: doing anything else violates encapsulation. You mayneed to write an accessor or mutator method occasionally, but you are still betteroff keeping the instance fields private. Bitter experience has shown that how thedata are represented may change, but how they are used will change much less frequently. When data are kept private, changes in their representation do notaffect the user of the class, and bugs are easier to detect.
  2. Always initialize data.
    Java won’t initialize local variables for you, but it will initialize instance fields ofobjects. Don’t rely on the defaults, but initialize the variables explicitly, either bysupplying a default or by setting defaults in all constructors.
  3. Don’t use too many basic types in a class.
    The idea is to replace multiple related uses of basic types with other classes. Thiskeeps your classes easier to understand and to change. For example, replace the followinginstance fields in a Customer class
  4. with a new class called Address. This way, you can easily cope with changes toaddresses, such as the need to deal with international addresses.
  5. Not all fields need individual field accessors and mutators.
    You may need to get and set an employee’s salary. You certainly won’t need tochange the hiring date once the object is constructed. And, quite often, objects haveinstance fields that you don’t want others to get or set, for example, an array of stateabbreviations in an Address class.
  6. Use a standard form for class definitions.
    We always list the contents of classes in the following order:
  7. public features
    package scope features
    private features Within each section, we list:
    instance methods
    static methods
    instance fields
    static fields

    After all, the users of your class are more interested in the public interface than inthe details of the private implementation. And they are more interested in methods than in data.

    However, there is no universal agreement on what is the best style. The Sun coding style guide for the Java programming language recommends listing fields first andthen methods. Whatever style you use, the most important thing is to be consistent.

  8. Break up classes that have too many responsibilities.
    This hint is, of course, vague: “too many” is obviously in the eye of the be holder.However, if there is an obvious way to make one complicated class into two classes that are conceptually simpler, seize the opportunity. (On the other hand, don’t gooverboard; 10 classes, each with only one method, is usually overkill.)
  9. Here is an example of a bad design.

    This class really implements two separate concepts: a deck of cards, with its shuffle and draw methods, and a card, with the methods to inspect the value and suit of acard. It makes sense to introduce a Card class that represents an individual card.Now you have two classes, each with its own responsibilities:

  10. Make the names of your classes and methods reflect their responsibilities.
    Just as variables should have meaningful names that reflect what they represent, soshould classes. (The standard library certainly contains some dubious examples,such as the Date class that describes time.)

A good convention is that a class name should be a noun (Order) or a noun preceded by an adjective ( RushOrder) or a gerund (an “-ing” word, like Billing Address). As for methods, follow the standard convention that accessor methods begin with a lower caseget (getSalary), and that mutator methods use a lowercase set (setSalary).


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Core Java Topics