1. 1.Cohesion and Coupling
   1. The public interface of a class is cohesive if all of its features are related to the concept that the class represents.
   2. If you find that the public interface of a class refers to multiple concepts, then that is a good sign that it may be time to use separate classes instead.
   3. A class depends on another class if it uses objects of that class.
   4. If many classes of a program depend on each other, then we say that the coupling between classes is high. Conversely, if there are few dependencies between classes, then we say that the coupling is low
   5. It is a good practice to minimize the coupling (i.e., dependency) between classes.
   6. UML (“Unified Modeling Language”)
      1. UML is a notation for object-oriented analysis and design invented by Grady Booch, Ivar Jacobson, and James Rumbaugh, three leading researchers in object-oriented software development.
         1. methods that operate on a particular instance of an object.
      2. The UML notation distinguishes between object diagrams and class diagrams.
         1. in a class diagram the class names are not underlined
         2. In a class diagram, you denote dependency by a dashed line with a -shaped open arrow tip that points to the dependent class.
   7. It is a good practice to minimize the coupling (i.e., dependency) between classes.
2. 2.Consistency
   1. When you have a set of methods, follow a consistent scheme for their names and parameters.
      1. This is simply a sign of good craftsmanship.
3. 4. Packages
   1. Organizing Related Classes into Packages
      1. A Java program consists of a collection of classes.
      2. As programs get larger, however, simply distributing the classes over multiple files isn't enough. An additional structuring mechanism is needed.
      3. A Java package is a set of related classes.
      4. To put classes in a package, you must place a line package packageName; as the first instruction in the source file containing the classes.
      5. A package name consists of one or more identifiers separated by periods.
      6. there is a special package, called the default package, which has no name.
      7. If you did not include any package statement at the top of your source file, its classes are placed in the default package.
   2. Importing Packages
      1. If you want to use a class from a package, you can refer to it by its full name (package name plus class name).
      2. For example, java.util.Scanner refers to the Scanner class in the java.util package: java.util.Scanner in = new java.util.Scanner(System.in);
      3. You can instead import a name with an import statement: import java.util.Scanner; Then you can refer to the class as Scanner without the package prefix.
      4. The import directive lets you refer to a class of a package by its class name, without the package prefix.
      5. You can import all classes of a package with an import statement that ends in .*. For example, you can use the statement import java.util.*;
      6. you don't need to import other classes in the same package. For example, when you implement the class homework1.Tester, you don't need to import the class homework1.Bank. The compiler will find the Bank class without an import statement because it is located in the same package, homework1.
   3. Package Names
      1. there is a more important reason for packages: to avoid name clashes.
      2. Use a domain name in reverse to construct unambiguous package names.
   4. How Classes are Located
      1. A package is located in a subdirectory that matches the package name.
      2. The parts of the name between periods represent successively nested directories.
      3. the package com.horstmann.bigjava would be placed in a subdirectory com/horstmann/bigjava.
      4. The path of a class file must match its package name.
   5. class path
      1. You need to add the directories that might contain packages to the class path
      2. In UNIX, the command might be export CLASSPATH=/home/walters/lib:.
      3. A typical example for Windows would be set CLASSPATH=c:\home\walters\lib;
      4. Class path contains the base directories that may contain package directories
4. Self Test
   1. quistion
      1. answer
   2. Why is the CashRegister class from Chapter 4 not cohesive?
      1. Some of its features deal with payments, others with coin values
   3. Why does the Coin class not depend on the CashRegister class?
      1. None of the coin operations require the CashRegister class
   4. Why should coupling be minimized between classes?
      1. If a class doesn't depend on another, it is not affected by interface changes in the other class
   5. Why might you want to add a precondition to a method that you provide for other programmers?
      1. Then you don't have to worry about checking for invalid values–it becomes the caller's responsibility
   6. When you implement a method with a precondition and you notice that the caller did not fulfil the precondition, do you have to notify the caller?
      1. No–you can take any action that is convenient for you
   7. Which of the following are packages?
      1. java No java.lang Yes java.util Yes java.lang.Math No
   8. Can you write a Java program without ever using import statements?
      1. Yes–if you use fully qualified names for all classes, such as java.util.Random and java.awt.Rectangle
   9. Suppose your homework assignments are located in the directory /home/me/cs101 (c:\me\cs101 on Windows). Your instructor tells you to place your homework into packages. In which directory do you place the class hw1.problem1.TicTacToeTester?
      1. /home/me/cs101/hw1/problem1 or, on Windows, c:\me\cs101\hw1\problem1
5. 3.Preconditions and Postconditions
   1. precondition
      1. A precondition is a requirement that the caller of a method must meet. If a method is called in violation of a precondition, the method is not responsible for computing the correct result.
      2. a precondition is an important part of the method, and you must document it.
      3. /** * Deposits money into this account. * @param amount the amount of money to deposit * (Precondition: amount >= 0) */
      4. Preconditions are typically provided for one of two reasons: 1. To restrict the parameters of a method 2. To require that a method is only called when it is in the appropriate state
      5. A method is responsible for operating correctly only when its caller has fulfilled all preconditions
      6. What should a method actually do when it is called with inappropriate inputs?
         1. 1. A method can check for the violation and throw an exception. Then the method does not return to its caller; instead, control is transferred to an exception handler. If no handler is present, then the program terminates.
            1. this approach can be inefficient, particularly if the same check is carried out many times by several methods.
         2. 2. A method can skip the check and work under the assumption that the preconditions are fulfilled. If they aren't, then any data corruption (such as a negative balance) or other failures are the caller's fault.
            1. The second approach can be dangerous.
         3. An assertion
            1. An assertion is a condition that you believe to be true at all times in a particular program location
            2. throwing an exception is another reasonable option. But assertions have one advantage: You can turn them off after you have tested your program,
            3. Many beginning programmers think that it isn't “nice” to abort the program when a precondition is violated. Why not simply return to the caller instead?
            4. That is legal—after all, a method can do anything if its preconditions are violated. But it is not as good as an assertion check. If the program calling the deposit method has a few bugs that cause it to pass a negative amount as an input value, then the version that generates an assertion failure will make the bugs very obvious during testing—it is hard to ignore when the program aborts. The quiet version, on the other hand, will not alert you, and you may not notice that it performs some wrong calculations as a consequence. Think of assertions as the “tough love” approach to precondition checking.
   2. postcondition
      1. If a method has been called in accordance with its preconditions, then it must ensure that its postconditions are valid.
      2. Condition that is true after a method has completed
      3. There are two kinds of postconditions
         1. 1. The return value is computed correctly.
         2. 2. The object is in a certain state after the method call is completed.
      4. /** * Deposits money into this account. * (Postcondition: getBalance() >= 0) * @param amount the amount of money to deposit * (Precondition: amount >= 0) */
      5. Don't document trivial postconditions that repeat the @return clause
   3. Note that we formulate pre- and postconditions only in terms of the interface of the class.
      1. Thus, we state the precondition of the withdraw method as amount <= getBalance(), not amount <= balance. After all, the caller, which needs to check the precondition, has access only to the public interface, not the private implementation.