정보은닉,캡슐화잘 설계된 모듈과 그렇지 못한 모듈을 구분짓는 중요한 속성은 세부사항을 구현사항을 다른 모듈에 잘 감추느냐의 여부이다. 잘 설계된 모듈은 구현 세부사항을 전부 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 구현마다 크게 다르다. 또한 클래스에 종료자를 붙여놓으면 객체 메모리
GC가 메모리 관리를 알아서 해주면 메모리관리의 중요성을 잊게 될 수도 있는데 그러지 말자 만기참조를 없애라더이상 참조되지 않는 만기참조의 경우 제거해주지 않으면 의도치 않은 객체 보유문제(실수로 객체 참조를 계속 유지하는 경우 해당 객체만 쓰레기 수진에서 제외되는것이 아니라 그객체를 통해 참조되는 다른 객체들도 쓰레기 수집에서 제외되는것)를 유발할 수 있
기능적으로 동일한 객체는 매번 만드는것보다 재사용하는 편이 낫다.가령 String s = new String(“test”);라는 문장을 반복문안에 넣을경우 매번 String 객체가 생성된다.이는 String s = “test”; 로 대체하는것이 낫다. 이는 실행할 때마다 객체를 만드는 대신 동일한 String 객체를 사용하며 같은 JVM안
정적 메서드나 필드만 모은 클래스가 필요한 경우는 다음 세가지로 볼 수 있다.1.자바의 기본 자료형 값 또는 배열에 적용되는 메서드를 한군데 모아둘 때.(java.lang.Math, java.lang.Arrays)2.특정 인터페이스를 구현하는 개체를 만드는 팩터리 메서드 등의 정적 메서드를 모아놓을 때(java.util.Collection)3.final 클