계승은 코드 재사용을 돕는 강력한 도구지만 항상 최선은 아니다. 계승을 적절히 사용하지 못한 소프트웨어는 깨지기 쉽다. 계승은 상위 클래스와 하위 클래스 구현을 같을 프로그래머가 통제하는 단일 패키지 안에서 사용하면 안전하다. 또한 계승을 고려하여 설계되고 그에 맞는 문서를 갖춘 클래스에 사용하는것도 안전하다. 일반적인 객체 생성 가능 클래스라면 해당클래스
변경 불가능 클래스는 그 객체를 수정할 수 없는 클래스이다. 객체 내부의 정보는 객체가 생성돌 때 주어진 것이며, 객체가 살아있는 동안 그대로 보존된다.변경불가능 클래스를 만드는 이유는 변경 가능 클래스보다 설계하기 쉽고 구현하기 쉬우며, 사용하기도 쉽다. 오류 가능성도 적고, 더 안전하다. 변경 불가능 클래스가 따라야 할 규칙1.객체 상태를 변경하는 메서
default1234class Point { public double x; public double y;} 데이터 필드를 직접 조작할 수 있어서 캡슐화의 이점을 누릴 수 없다. API를 변경하지 않고서는 내부 표현을 변경할 수 없고, 불변식도 강제할 수 없고, 필드를 사용하는 순간에 어떤 동작이 실행되도록 만들수도 없다. 이는 privat
정보은닉,캡슐화잘 설계된 모듈과 그렇지 못한 모듈을 구분짓는 중요한 속성은 세부사항을 구현사항을 다른 모듈에 잘 감추느냐의 여부이다. 잘 설계된 모듈은 구현 세부사항을 전부 API 뒤쪽에 감춘다. 모듈들은 이를 API를 통해서만 서로 통신하며 각자 내부정으로 무슨짓을 하는지는 신경쓰지 않는다. 이를 바로 정보은닉 또는 캡슐화라고 알려져있다.. 이는 소프트웨
compareTo 메서드는 Comparable 인터페이스에 포함된 유일한 메서드이다. Object의 equals 메서드와 비슷하지만 단순한 동치성 검사 이외에 순서 비교가 가능하며 좀더 일반적이다.compareTo 메서드의 일반 규약은 equals와 비슷하다. 규약규약 객체와 인자로 주어진 객체를 비교한다. 이 객체의 값이 인자로 주어진 객체보다 작으면 음
Cloneable의 괴상함Cloneable은 어떤 객체가 복제를 허용한다는 사실을 알리는 데 쓰려고 고안된 믹스인(mixin) 인터페이스이다. 해당 인터페이스에는 clone 메서드가 없으며 Object의 clone 메서드는 protected로 선언되어 있다.Cloneabledms protected로 선언된 Object의 clone 메소드가 어떻게 동작할지
java.lang.Object 클래스가 toString 메서드를 제공하긴 하지만 이 메서드가 반환하는 문자열은 일반적으로 사용자가 보려는 문자열이 아니다. toStirng의 일반 규약에는 “모든 하위 클래스는 이 메서드를 재정의함이 바람직하다”라고 나와있다.equals와 hashCode의 일반 규약을 지키는 것보다는 덜 중요하지만 toString을 잘 만들
많은 버그는 hashCode 메서드를 재정의하지 않아서 생긴다. equals 메서드를 재정의하는 클래스는 반드시 hashCode 메서드도 재정의 해야한다. 그렇지 않을경우 HashMap,HashSet 등과 같은 해시기반 컬렉션과 함께 사용하면 오작동하게 된다. hashCode의 일반적인 규약은 다음과 같다.1.응용프로그램 실행 중에 같은 객체의 hashCo
equals는 생각보다 재정의 하기 어렵다. 실수로 인한 결과는 끔찍해 질 수 있다. 다음중 하나라도 만족할 경우에는 equals를 재정의 하지 않아도 된다.1.각각의 객체가 고유하다.(ex. Thread 객체)2.클래스에 논리적 동일성 검사방법이 있건 없건 상관없다(ex. Random class)3.상위클래스에서 재정의한 equals가 하위 클래스에서 사
종료자는 예측 불가능하며 대체로 위험하고 일반적으로 불필요하다. 종료자의 단점 및 주의할 점1.C++의 소멸자와는 다른개념이다. 종료자는 즉시 실행되리라는 보장이 전혀 없다. 그러므로 긴급한 작업을 종료자 안에서 처리하면 안된다. 종료자의 실행시점은 GC 알고리즘에 좌우되는데 이는 JVM 구현마다 크게 다르다. 또한 클래스에 종료자를 붙여놓으면 객체 메모리