<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Scott@JAVA

    Java, 一杯濃濃的咖啡伴你到深夜

    《Effective Java》Chapter 4

    Chapter 4: Classes and Interfaces

    Item 12: Minimize the accessibility of classes and members

    The rule of thumb is that you should make each class or member as inaccessible as possible.

    For members (fields, methods, nested classes, and nested interfaces) there are four possible access levels, listed here in order of increasing accessibility:
       ? private— The member is accessible only inside the top-level class where it is declared.
       ? package-private— The member is accessible from any class in the package where it is declared. Technically known as default access, this is the access level you get if no access modifier is specified.
       ? protected— The member is accessible from subclasses of the class where it is declared (subject to a few restrictions [JLS, 6.6.2]) and from any class in the package where it is declared.
       ? public— The member is accessible from anywhere.

    It is nearly always wrong to have public static final array field.
    //Potential security hole!
    public static final Type[] VALUES =  };

    The public array should be replaced by a private array and a public immutable list:

    private static final Type[] PRIVATE_VALUES =  };
    public static final List VALUES =
        Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

    Alternatively, if you require compile-time type safety and are willing to tolerate a performance loss, you can replace the public array field with a public method that returns a copy of a private array:

    private static final Type[] PRIVATE_VALUES =  };
    public static final Type[] values() {
        
    return (Type[]) PRIVATE_VALUES.clone();
    }


    Item 13: Favor immutability
    The Java platform libraries contain many immutable classes, including String, the primitive wrapper classes, and BigInteger and BigDecimal.

    a) Don't provide any methods that modify the object (known as mutators).
    b) Ensure that no methods may be overridden.
    c) Make all fields final.
    d) Make all fields private.
    e) Ensure exclusive access to any mutable components.
    Immutable objects are inherently thread-safe; they require no synchronization.
    The only real disadvantage of immutable classes is that they require a separate object for each distinct value.
    This approach works fine if you can accurately predict which complex multistage operations clients will want to perform on your immutable class. If not, then your best bet is to provide a public mutable companion class. The main example of this approach in the Java platform libraries is the String class, whose mutable companion is StringBuffer.

    Item 14: Favor composition over inheritance
    Unlike method invocation, inheritance breaks encapsulation.

    // Broken - Inappropriate use of inheritance!
    public class InstrumentedHashSet extends HashSet {
        
    // The number of attempted element insertions
        private int addCount = 0;

        
    public InstrumentedHashSet() {
        }


        
    public InstrumentedHashSet(Collection c) {
            
    super(c);
        }


        
    public InstrumentedHashSet(int initCap, float loadFactor) {
            
    super(initCap, loadFactor);
        }


        
    public boolean add(Object o) {
            addCount
    ++;
            
    return super.add(o);
        }


        
    public boolean addAll(Collection c) {
            addCount 
    += c.size();
            
    return super.addAll(c);
        }


        
    public int getAddCount() {
            
    return addCount;
        }

    }

    This class looks reasonable, but it doesn't work. Suppose we create an instance and add three elements using the addAll method:

    InstrumentedHashSet s = new InstrumentedHashSet();
    s.addAll(Arrays.asList(
    new String[] {"Snap","Crackle","Pop"}));

    Internally, HashSet's addAll method is implemented on top of its add method, although HashSet, quite reasonably, does not document this implementation detail.

    Here's a replacement for InstrumentedHashSet that uses the composition/forwarding approach:

    // Wrapper class - uses composition in place of inheritance
    public class InstrumentedSet implements Set {
        
    private final Set s;

        
    private int addCount = 0;

        
    public InstrumentedSet(Set s) {
            
    this.s = s;
        }


        
    public boolean add(Object o) {
            addCount
    ++;
            
    return s.add(o);
        }


        
    public boolean addAll(Collection c) {
            addCount 
    += c.size();
            
    return s.addAll(c);
        }


        
    public int getAddCount() {
            
    return addCount;
        }


        
    // Forwarding methods
        public void clear() {
            s.clear();
        }


        
    public boolean contains(Object o) {
            
    return s.contains(o);
        }


        
    public boolean isEmpty() {
            
    return s.isEmpty();
        }


        
    public int size() {
            
    return s.size();
        }


        
    public Iterator iterator() {
            
    return s.iterator();
        }


        
    public boolean remove(Object o) {
            
    return s.remove(o);
        }


        
    public boolean containsAll(Collection c) {
            
    return s.containsAll(c);
        }


        
    public boolean removeAll(Collection c) {
            
    return s.removeAll(c);
        }


        
    public boolean retainAll(Collection c) {
            
    return s.retainAll(c);
        }


        
    public Object[] toArray() {
            
    return s.toArray();
        }


        
    public Object[] toArray(Object[] a) {
            
    return s.toArray(a);
        }


        
    public boolean equals(Object o) {
            
    return s.equals(o);
        }


        
    public int hashCode() {
            
    return s.hashCode();
        }


        
    public String toString() {
            
    return s.toString();
        }

    }

    Inheritance is appropriate only in circumstances where the subclass really is a subtype of the superclass. In other words, a class B should extend a class only A if an “is-a” relationship exists between the two classes.

    Item 15: Design and document for inheritance or else prohibit it
    The class must document precisely the effects of overriding any method.
    Constructors must not invoke overridable methods, directly or indirectly.

    public class Super {
        
    // Broken - constructor invokes overridable method
        public Super() {
            m();
        }


        
    public void m() {
        }

    }

    Here's a subclass that overrides m, which is erroneously invoked by Super's sole constructor:

    final class Sub extends Super {
        
    private final Date date; // Blank final, set by constructor

        Sub() 
    {
            date 
    = new Date();
        }


        
    // Overrides Super.m, invoked by the constructor Super()
        public void m() {
            System.out.println(date);
        }


        
    public static void main(String[] args) {
            Sub s 
    = new Sub();
            s.m();
        }

    }

    It prints out null the first time because the method m is invoked by the constructor Super() before the constructor Sub() has
    a chance to initialize the date field.

    If you do decide to implement Cloneable or Serializable in a class designed for inheritance, you should be aware that because the clone and readObject methods behave a lot like constructors, a similar restriction applies: Neither clone nor readObject may invoke an overridable method, directly or indirectly.

    Item 16: Prefer interfaces to abstract classes
    Existing classes can be easily retrofitted to implement a new interface.
    Interfaces are ideal for defining mixins. (eg. Comparable)
    Interfaces allow the construction of nonhierarchical type frameworks.
    Interfaces enable safe, powerful functionality enhancements via the wrapper class idiom.

    Using abstract classes to define types that permit multiple implementations has one great advantage over using interfaces: It is far easier to evolve an abstract class than it is to evolve an interface.

    Item 17: Use interfaces only to define types
    When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class.
    The constant interface pattern is a poor use of interface, use constant utility class instead. (public static final fileds)

    Item 18: Favor static member classes over nonstatic
    There are four kinds of nested classes: static member classes, nonstatic member classes, anonymous classes, and local classes. All but the first kind are known as inner classes.

    One common use of a nonstatic member class is to define an Adapter that allows an instance of the outer class to be viewed as an instance of some unrelated class. It is possible, although rare, to establish the association manually using the expression enclosingInstance.new MemberClass(args).

    // Typical use of a nonstatic member class
    public class MySet extends AbstractSet {
         
    // Bulk of the class omitted

        
    public Iterator iterator() {
            
    return new MyIterator();
        }

        
        
    private class MyIterator implements Iterator {
            
        }

    }

    If you declare a member class that does not require access to an enclosing instance, remember to put the static modifier in the declaration. If you omit the static modifier, each instance will contain an extraneous reference to the enclosing object. Maintaining this reference costs time and space with no corresponding benefits.

    One common use of a static member class is as a public auxiliary class, useful only in conjunction with its outer class.

    // Typical use of a public static member class
    public class Calculator {
        
    public static abstract class Operation {
            
    private final String name;

            Operation(String name) 
    {
                
    this.name = name;
            }


            
    public String toString() {
                
    return this.name;
            }


            
    // Perform arithmetic op represented by this constant
            abstract double eval(double x, double y);

            
    // Doubly nested anonymous classes
            public static final Operation PLUS = new Operation("+"{
                
    double eval(double x, double y) {
                    
    return x + y;
                }

            }
    ;

            
    public static final Operation MINUS = new Operation("-"{
                
    double eval(double x, double y) {
                    
    return x - y;
                }

            }
    ;

            
    public static final Operation TIMES = new Operation("*"{
                
    double eval(double x, double y) {
                    
    return x * y;
                }

            }
    ;

            
    public static final Operation DIVIDE = new Operation("/"{
                
    double eval(double x, double y) {
                    
    return x / y;
                }

            }
    ;
        }


        
    // Return the results of the specified calculation
        public double calculate(double x, Operation op, double y) {
            
    return op.eval(x, y);
        }

    }


    One common use of an anonymous class is to create a function object, such as a Comparator instance. Another common use of an anonymous class is to create a process object, such as a Thread, Runnable, or TimerTask instance.

    // Typical use of an anonymous class
    Arrays.sort(args, new Comparator() {
        
    public int compare(Object o1, Object o2) {
            
    return ((String)o1).length() - ((String)o2).length();
        }

    }
    );


    Local classes are probably the least frequently used of the four kinds of nested classes. A local class may be declared anywhere that a local variable may be declared and obeys the same scoping rules.

    posted on 2005-12-18 00:24 Scott@JAVA 閱讀(527) 評論(0)  編輯  收藏 所屬分類: Effective Java

    主站蜘蛛池模板: 亚洲精品福利在线观看| 91精品国产免费| 免费的黄色的网站| 免费成人高清在线视频| 国产亚洲综合视频| 暖暖日本免费中文字幕| 成人免费区一区二区三区| 国产乱妇高清无乱码免费| 日韩精品无码永久免费网站| 韩国免费A级毛片久久| 男人扒开添女人下部免费视频| ssswww日本免费网站片| 国产99久久久久久免费看| 91精品全国免费观看含羞草| 午夜无遮挡羞羞漫画免费| 久久国产乱子免费精品| 夜夜嘿视频免费看| 毛片亚洲AV无码精品国产午夜| 亚洲日韩国产二区无码| 中中文字幕亚洲无线码| 亚洲一区在线观看视频| 亚洲AV无码专区在线亚| WWW国产成人免费观看视频| 精品免费人成视频app| 四虎最新永久免费视频| 啊v在线免费观看| 亚洲一区二区影视| 青青青国产免费一夜七次郎| 亚洲情a成黄在线观看动漫尤物| 久久久综合亚洲色一区二区三区 | 在线a免费观看最新网站| 99在线精品免费视频九九视| 2021免费日韩视频网| 伊人亚洲综合青草青草久热| 亚洲AV成人精品网站在线播放| 国产精品亚洲精品日韩动图 | 色窝窝免费一区二区三区| 精品久久久久成人码免费动漫| 24小时日本在线www免费的| 亚洲国产精品VA在线观看麻豆 | 亚洲视频在线观看免费|