Java18 Java | 클래스와 멤버의 접근 권한을 최소화하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다.핵심프로그램 요소의 접근성은 가능한 한 최소한으로 하라.꼭 필요한 것만 골라 최소한의 public API를 설계하자.그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다.public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안 된다.public static final 필드가 참조하는 객체가 불변인지 확인하라.이유잘 설계된 컴포넌트는 다른 컴포넌트와 소통하며 내부 동작 방식에는 전혀 개의치 않는다.즉, 정보 은닉, 캡슐화의 개념은 소프트웨어 설계의 근간이되는 원리다.정보은닉의 장점시스템 개발 속도.. 2024. 8. 6. Java & Spring | Swagger 커스텀 ApiResponse 어노테이션 사용기 💎 작성된 글의 프로젝트https://github.com/MARU-EGG/MARU_EGG_BE GitHub - MARU-EGG/MARU_EGG_BEContribute to MARU-EGG/MARU_EGG_BE development by creating an account on GitHub.github.com 💎 작성된 글의 Pull Requesthttps://github.com/MARU-EGG/MARU_EGG_BE/pull/42 [feat] Swagger 커스텀 ApiResponse 어노테이션 적용 by Hoya324 · Pull Request #42 · MARU-EGG/MARU_EGG_BE✅ 작업 내용 작업 관련 정리 블로그 Swagger 커스텀 ApiResponse 어노테이션을 적용했습니다. 프로.. 2024. 7. 17. Java | Comparable을 구현할지 고려하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야한다.compareTo 메서드에서 필드의 값을 비교할 때 연산자는 쓰지 않는다.그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자. 이유compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있다는 것이 Object의 equals와 다른 점이다.compareTo 메서드의 일반 규약이 객체와 주어진 객체의 순.. 2024. 7. 4. Java | clone 재정의는 주의해서 진행하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안 되며, 새로운 클래스도 이를 구현해서는 안 된다.final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야 한다.기본 원칙은 ‘복제 기능은 생성자와 팩터리를 이용하는 것이 최고’라는 것이다.단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라 할 수 있다. 이유Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다.리.. 2024. 7. 4. Java | toString을 항상 재정의하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다.toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야한다. 이유toString: “모든 하위 클래스에서 이 메서드를 재정의하라”toString은 유익한 정보를 담고 있고, 핵심을 직접 전달해야한다.{ Jenny=PhoneNumber@adbbd } 보다는 { Jenny=010-1234-5678 }로 오는 것이 더 반가운 것과 같은 이치이.. 2024. 7. 4. Java | equals를 재정의하려거든 hashCode도 재정의하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다.재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야하며, 서로 다른 인스턴스라면 되도롣 해시코드도 서로 다르게 구현해야 한다. 이유equals를 클래스 모두에서 hashCode도 재정의해야한다.그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashSet이나 HashMap 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다.hashCode 일반 규약equals 비교에 사용되는 정보가 변경되지 않았다면.. 2024. 7. 4. 이전 1 2 3 다음
