일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 상속
- 제네릭 타입
- Switch Expressions
- 함수형 인터페이스
- 스파르타코딩클럽
- 브릿지 메소드
- yield
- System.in
- 로컬 클래스
- raw 타입
- throwable
- Study Halle
- 제네릭 와일드 카드
- System.out
- 익명 클래스
- 람다식
- annotation processor
- 자바스터디
- 합병 정렬
- System.err
- auto.create.topics.enable
- 자바할래
- 바운디드 타입
- 항해99
- 접근지시자
- docker
- github api
- junit 5
- 프리미티브 타입
- 정렬
- Today
- Total
목록Book (37)
코딩하는 털보
이펙티브 자바, 아이템 15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 정보 은닉의 장점 각 컴포넌트를 병렬로 개발할 수 있기 때문에 개발 속도를 높인다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고 교체하는 부담도 적기 때문에 관리 비용을 낮춘다. 다른 컴포넌트에 영향을 주지 않고 최적화할 수 있기 때문에 성능 최적화에 도움을 준다. 외부에 의존하지 않고 독자적으로 동작하는 컴포넌트는 재사용성이 높다. 개별 컴포넌트 동작 검증으로 큰 시스템을 제작하는 난이도를 낮춰준다. 접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심이다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다. 클래스의 접근 제한자 톱레벨 ..
이펙티브 자바, 아이템 14. Comparable을 구현할지 고려하라 Comparable 인터페이스의 compareTo를 구현하여 사용하는 것을 고려해 볼 수 있다. compareTo 메서드는 Object의 equals와 두 가지 차이가 있다. 단순 동치성 비교에 더해 순서까지 비교할 수 있다. Comparable을 구현했다는 것은 인스턴스들에 자연적인 순서가 있음을 뜻한다. 알파벳, 숫자, 연대 처럼 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자. compareTo 규약을 지키지 못하면 비교를 활용하는 클래스와 어울리지 못한다. (ex. TreeSet, TreeMap 또는 Collections와 Arrays의 정렬) compareTo 메서드로 수행하는 동치성 검사..
이펙티브 자바, 아이템 13. clone 재정의는 주의해서 진행하라 Java 제공 인터페이스 Cloneable는 아무 메서드도 가지고 있지 않지만 이 인터페이스를 구현하는 인스턴스에서는 Object의 clone 메서드의 동작이 바뀐다. Cloneable을 구현한 인스턴스에서 clone 메서드를 호출하게 되면, 해당 객체를 복사한 객체를 반환하게 된다. Object의 clone 메서드는 protected이기 때문에 외부 객체에서 사용하려면 재정의가 필요하다. Object clone()은 Object 타입을 반환하기 때문에 공변 반환 타입을 통해서 Object 대신 재정의하는 클래스 타입으로 캐스팅하여 반환하도록 재정의하는게 좋다. 공변 반환 타입 : 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반..
이펙티브 자바, 아이템 12. toString을 항상 재정의하라 toString의 일반 규약, 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보, 모든 하위 클래스에서 이 메서드를 재정의하라. Object의 기본 toString은 클래스이름@16진수해시코드를 반환하며, 그다지 쓸모 없는 메시지를 출력하게 된다. toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. toString은 우리가 직접 호출하지 않아도 다른 어딘가에서 쓰일 수 있다. 실전에서 toString은 그 객체가 가진 주요 정보를 모두 반환하는 게 좋다. PhoneNumber에서 지역 번호만 toString에 담았다고 가정한다. @Override public String toString..
이펙티브 자바, 아이템 11. equals를 재정의 하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 HashMap 또는 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생한다. hashCode 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals가 두 객체를 다르다고 판단했다면, 두 객체의 hashCode는 다르게 반환해야 해시 테이블의 ..
디자인 패턴 2. 옵저버 패턴 옵저버 패턴을 정기 신문 구독으로 예를 들어 설명해줬다. 신문출판사 : 주제(subject) 객체, 구독자 : 옵저버 주제 객체에서 일부 데이터를 관리하며 데이터가 달라지면 옵저버에 새로운 데이터 값이 전달된다. 옵저버 객체들은 주제를 구독하고(주제 객체에 등록되어)있으며 주제의 데이터가 바뀌면 갱신 내용을 전달받는다. 옵저버 패턴 옵저버 패턴에서는 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의합니다. 일대다 관계 옵저버 패턴에서는 일련의 객체들(주제와 옵저버) 사이에서 일대다 관계를 정의한다. 옵저버 패턴은 대부분 주제 인터페이스와 옵저버 인터페이스가 들어있는 클래스 ..
이펙티브 자바, 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 하나 이상의 자원에 의존하는 클래스가 있다. 예를들어 아래 SpellChecker 클래스는 dictionary에 의존한다. public class SpellChecker { private static final Lexicon dictionary = ...; public static boolean isValid(String word){ //... } } 예시에서는 인스턴스화를 막고 정적 유틸리티 클래스로 만들었는데, 이런 경우 dictionary를 단 하나만 사용한다고 가정해야 하기 때문에 여러가지 dictionary를 써야한다면 잘못된 방법이다. 싱글턴으로 만들어도 같은 문제가 생긴다. 그렇다면 자원의 final을 제거하고..
클린 코드, 11. 시스템 시스템 수준에서 깨끗함을 유지하는 방법, 높은 추상화 수준. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다. 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 안 된다. 설정 로직을 일반 런타임 로직과 분리하면 모듈성이 높아진다. SOC(관심사 분리) 프로그램을 기능 면에서 가능한 중복이 아닌 여러 모듈로 명확히 나누는 것 SOC를 적용하면 자연스럽게 단일 책임 원칙, 개방 폐쇄 원칙, 인터페이스 분리 원칙을 달성하게 된다. 초기화 지연(Lazy initialization) public FieldType getField() { if (fieldType == null) { fieldType = new FieldType(); } retur..
클린 코드, 10. 클래스 표준 자바 관례 변수 public static 상수 private static private public 변수가 필요한 경우는 거의 없다. 함수 public 메서드 private 메서드는 호출하는 함수 직후에 캡슐화 테스트 코드에서 함수를 호출하거나 변수를 사용해야 한다면 protected로 선언하거나 패키지 전체로 공개한다. 하지만 이렇게 캡슐화를 풀어주는 것은 언제나 최후의 수단이다. 클래스는 작아야 한다. 클래스의 크기는 클래스가 맡은 책임이다. 책임을 줄여야 한다. 만능 클래스가 있다면 단일 책임 클래스 여럿으로 분리하도록 노력해야 한다. 클래스 이름 클래스 이름이 모호하다면 클래스에 여러 책임을 떠안겼다는 증거다. 클래스 설명은 '만일', '그리고..
클린 코드, 9. 단위 테스트 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 많아졌으며 점점 더 늘어나는 추세다. 하지만 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 중요한 사실을 놓치고있다. TDD 법칙 세 가지 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 잘 돼면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 이렇게 일하면 실제 코드를 사실상 전부 테스트하는 많은 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리문제를 유발하기도 한다. 깨끗한..