728x90 공부/이펙티브자바33 [이펙티브자바]item 15. 클래스와 멤버의 접근 권한을 최소화하라 구현과 API 분리하는 정보은닉 장점 시스템 개발 속도를 높인다 인터페이스 설계시 사용하는 쪽과 지원하는 쪽이 동시에 개발이 가능하다. 시스템 관리 비용을 낮춘다 컴포넌트를 더 빨리 파악할 수 있기 떄문에, 인터페이스 위주로 빠르게 파악이 가능하다 소스프퉤어 재사용성을 높인다 모듈화가 잘되어 있따면 병목지점을 빠르게 찾아서 처리할 수 있다. 시스템 개발 난이도를 낮춘다 큰 시스템을 개발할때 작은 단위로 나눠서 구현하다보면 전체를 구현할 수 있다. 모든 클래스와 멤버의 정급성을 가능한 한 좁혀야 한다. 톱레벨 클래스와 인터페이스에 pakage-private(default) 또는 public 을 쓸 수 있다. public 으로 선언하면 API가 되므로 하위 호환성을 유지하려면 계속 관리해야 한다. 패키지 외.. 2023. 1. 19. [이펙티브자바]item14.Comparable을 구현할지 고려하라. 추후 업데이트 예정. 2023. 1. 19. [이펙티브자바]item13.clone 재정의는 주의해서 진행하라. 자꾸 Object 에 있는 메서드들을 오버라이딩할때 조심하라는데.. Object 은 구상클래스로서([Concrete class]: new 키워드를 통해 인스턴스를 만드는 클래스) 이러한 구상클래스는 내부구현이 되어 있어야 한다. 하지만 몇몇 메서드 들은 되어 있지 않다. clone, toString, hashCode, equals 등등 이러한 메서드 들은 오버라이딩할때 지켜야할 몇가지가 있다. 이러한 주의점들과 해결책들을 계속 말해주는것 같다. 근데 왜 다른것들은 final 이 아니라 오버라이딩을 가능하게 했을까? 음..편의성 떄문인가 입맛대로 수정할 수 있게끔?필요할때마다 다른 기능을 구현해야할 상황이 있어서 ===Cloneable 을 상속받아 clone 메서드를 override 하면 Cloneable.. 2023. 1. 18. [이펙티브자바]item12.toString을 항상 재정의하라. 요즘 코틀린만 써서 toString을 재정의 안해서 편했는데,, toString 을 보기좋게 원하는 데이터를 볼 수 있도록, 재정의하도록 하자. ide 도움을 받아서 override 하면 될듯하다. 2023. 1. 17. [이펙티브자바]item11.equals를 재정의하려거든 hashCode도 재정의하라. equals를 재정의한 클래스 모두 hashCode도 재정의 해야 한다. 재정의할때에는 좋은 hashcode 작성 요령 같은 키워드로 찾아서 작성해주자. ide 의 도움을 받아 정의하는 방법도 괜찮다. 2023. 1. 17. [이펙티브자바]item10.equals는 일반 규약을 지켜 재정의하라. 아래와 같은 상황에서는 equals 를 재정의하지 않는게 최선이다. 각 인스턴스가 본질적으로 고유하다. 싱글톤 오브젝트같은 경우에 equals 가 필요할까?enum 일때는?? 굳이 필요없다. 논리적 동치성을 검사할 일이 없다 객체의 동일성이 논리적으로 일치할 경우 굳이 equals 를 재정의 하지 않아도 된다.ex) 문자열 같은 상위클래스에서 재정의한 equals 가 하위 클래스에서도 딱 들어 맞는다 set, list 같은 상속하여 만들때 클래스가 private 이거나 package-private 이고 equals 를 호출할 일이 없다. public 은 equals 를 호출하지 않는다라는걸 보장하지못하지만 private 는 다르다. 각 인스턴스가 본질적으로 고유하다. equlas 를 재정의 안하는걸 추천.. 2023. 1. 17. [이펙티브자바]item9.try-finally보다는 try-with-resources를 사용하라. InputStream, OutputStream, Connetion 등의 자바 라이브러리를 직접 close() 해줘야하는 경우가 있다 왜 이것들은 close()를 해주고 다른객체들은 GC가 수거해 갈까? 메모리를 관리하며, 더이상 필요없는 객체는 GC가 수거해 가는데, Stream의 경우에는 외부 자원을 가져와서 쓰기때문에, 하드데이터 GC가 이를 알지 못해 close 를 통해서 처리한다. 외부 라이브러리를 쓸때 한번씩 더 체크해야할 상황인듯. 기존 try finally 방식도 나쁘지는 않다고 생각하지만, 코드가 더 깔끔하고, 실수할 여지가 없는 try-with-resources 를 사용하자. *참고로 코틀린은 use 를 사용한다 2023. 1. 17. [이펙티브자바]item8.finalizer와 cleaner 사용을 피하라. finalize? 가비기컬렉션의 수행될 때 실행되는 메소드를 정의할 수 있다고 한다. leak 을 방지하기 위한 기술이였던거 같다. cleaner? finalize 의 대안책으로 덜 위험하지만, 예측할 수 없고, 느리고, 일반적으로 불필요하다. --- 사용안하는 이유 즉시 수행된다는 보장이 없음.(가비지 컬렉터 알고리즘에 따라 다름) 성능문제 정말 필요한 상황이 아니라면 쓰지말자. 자원의 close 가 필요한 상황에 안전망 같은 경우에 사용은 가능하지만 안쓰는게 나을듯. 추후 업데이트 하겠지만, 잘 쓰지 않은 부분이라 크게 와닿지 않은 부분. 그래서 어떻게? item9 에서 나오겠지만 try with resources 를 사용하면 될듯하다. 2023. 1. 17. [이펙티브자바]item7.다 쓴 객체 참조를 해제하라. 자바는 가비지컬렉터가 다 쓴 자원을 자동적으로 회수해 가지만 무조건 적인건 아니다 예외적인 상황 stack 클래스 왜? 스택 클래스는 왜 메모리 누수에 취약할까 스택이 자기 메모리를 직접 관리하기 때문. 객체를 담는 elements 배열로 저장소 풀을 만들어 원소들을 관리한다. 활성 역역에 속한건 사용하고 비활성은 사용하지 않는다. 이를 가비지컬렉터가 알 길이 없다. 그래서 다 쓴 원소는 nul 처리를 하자. 캐시 역시 메모리 누수를 일으키는 주범 캐시 생성 후 메모리를 잘 정리하자 조만간 업데이트 예정 리스너(listener) 혹은 콜백(callback) 이것도 조만간 업데이트 예정 WeakHashMap 사용하지 않는 객체를 가비지컬렉터가 자동으로 삭제해 주는 맵 주의점: key 를 만들경우 레퍼런스 .. 2023. 1. 13. 이전 1 2 3 4 다음 728x90