❓
물음표살인마 블로그
  • README
  • ALGORITHM
    • Sieve of Eratosthenes
    • Round Up
    • Binary Search
    • Union Find
    • Sorting Array
    • Lcm, Gcd
  • TechTalk Review
    • Template
  • Books
    • CS Note for Interview
      • Ch1. Design Pattern & Programming paradigm
        • 1.1.1 Singleton Pattern
        • 1.1.2 Factory Pattern
        • 1.1.4 Observer Pattern
        • 1.1.5 Proxty Pattern & Proxy Server
        • 1.1.8 Model-View-Controller Pattern
        • 1.2.1 Declarative and Functional Programming
        • 1.2.2 Object Oriented Programming
      • Ch2. Network
        • 2.2.1 TCP/IP Four-Layer Model
        • 2.2.1-1 TCP 3, 4 way handshake
        • 2.3 Network Devices L4, L7
        • 2.4.1 ARP, RARP
        • 2.4.2 Hop By Hop Communication
        • 2.4.3 IP Addressing Scheme
      • Ch3. Operating System
        • 3.1.1 Roles and Structure of Operating Systems
        • 3.2.1 Memory Hierarchy
        • 3.2.2 Memory Management
        • 3.3.1 Processes and Compilation Process
        • 3.3.3 Memory Structure of a Process
        • 3.3.4 Process Control Block (PCB)
        • 3.3.5 Multiprocessing
        • 3.3.6 Threads and Multithreading
        • 3.3.7 Shared Resources and Critical Sections
        • 3.3.8 Deadlock
        • 3.4 CPU Scheduling Algorithm
      • Ch4. Database
        • 4.1 Database Basic
        • 4.2 Normalization
        • 4.3 Transaction and Integrity
        • 4.4 Types of Databases
        • 4.5 Indexes
        • 4.6 Types of Joins
        • 4.7 Principles of Joins
      • Ch5. Data Structure
    • Learning the Basics of Large-Scale System Design through Virtual Interview Cases
      • 1. Scalability based on user counts(1/2)
      • 1. Scalability based on user counts(2/2)
      • 2.Back-of-the-envelope estimation
      • 3. Strategies for System Design Interviews
      • 4. Rate Limiter
      • 5. Consistent Hashing
      • 6. Key-Value System Design
      • 7. Designing a Unique ID Generator for Distributed Systems
      • 8. Designing a URL Shortener
      • 9. Designing a Web Crawler
      • 10. Notification System Design
      • 11. Designing a News Feed System
      • 12. Chat System Design
      • 13. AutoComplete
      • 14. Design YouTube
      • 15. Design Google Drive
      • Loadbalancer Algorithms
      • Cache tier
      • CDN, Content Delivery Network
      • Stateless Web tier
    • Computer System A programmer's perspective
    • Effective Java
      • Item 1. Consider Static Factory Methods Instead of Constructors
      • Item 2. Consider a Builder When Faced with Many Constructor Parameters
      • Item 3. Ensure Singleton with Private Constructor or Enum Type
      • Item 4. Enforce Noninstantiability with a Private Constructor
      • Item 5. Prefer Dependency Injection to Hardwiring Resources
      • Item 6. Avoid Creating Unnecessary Objects
      • Item 7. Eliminate Obsolete Object References
      • Item 8. Avoid Finalizers and Cleaners
      • Item 9.Prefer try-with-resources to try-finally
      • Item10. Adhering to General Rules When Overriding equals
        • Handling Transitivity Issues
        • Ensuring Consistency
      • Item11. Override hashCode When You Override equals
      • Item12. Always Override toString
        • Always Override toString
      • Item13. Override Clone Judiciously
      • Item14. Consider Implementing Comparable
      • Item15. Minimize the Accessibility of Classes and Members
      • Item16. Accessor Methods Over Public Fields
      • Item17. Minimize Mutability
      • Item18. Composition over inherentance
      • Item19. Design and Document for Inheritance, or Else Prohibit It
      • Item20. Prefer Interfaces to Abstract Classes
      • Item21. Design Interfaces with Implementations in Mind
      • Item22. Use Interfaces Only to define Types
      • Item23. Prefer Class Hierarchies to Tagged Classes
      • Item24. Favor Static Member Classes Over Non-Static
      • Item28. Use Lists Instead of Arrays
      • Item29. Prefer Generic Types
      • Item30. Favor Generic Methods
    • Head First Design Patterns
      • Ch1. Strategy Pattern
      • Ch2. Observer Pattern
        • Ver1. Ch2. Observer Pattern
      • Ch3. Decorator Pattern
        • Ch3. Decorator Pattern
      • Ch4. Factory Pattern
      • Ch5. Singleton Pattern
      • Ch6. Command Pattern
      • Ch7. Adapter and Facade Pattern
      • Ch8. Template Method Pattern
    • Digging Deep into JVM
      • Chapter 2. Java Memory Area & Memory Overflow
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (1/2)
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (2/2)
      • Chapter 5. Optimization Practice
      • Chapter 6. Class file structure
      • Chapter 8. Bytecode Executor Engine (1/2)
  • Interview Practices
    • Restful API Practices
      • Url Shortener API
      • Event Ticket Reservation API
      • Course Management API
      • Search posts by tags API
      • Online Code platform API
      • Simple Task Management API
      • Event Participation API
      • Review System API
      • Car management API
      • Online Library
    • Tech Review
      • if(kakao)
        • Kakao Account Cache Migration / if(kakao)2022
        • Improving the Anomaly Detection System for KakaoTalk Messaging Metrics / if(kakao) 2022
        • Standardizing API Case Handling Without Redeployment / if(kakaoAI)2024
        • JVM warm up / if(kakao)2022
    • Naver Computer Science
      • Process & Thread
      • TCP & UDP
      • Spring & Servlet
      • Filter & Interceptor & AOP
      • Equals() & ==
      • Dependency Injection
      • Object Oriented Programming
  • F-Lab
    • Week1
      • Client & Server
      • HTTP
      • TCP/UDP
      • REST API
      • Questions
        • Object Oriented Programming
        • HTTP
        • Process & Thread
        • Data Structure
    • Week2
      • OSI 7 layer
      • Web vs WAS
    • Week3
      • RDB vs NoSQL
      • RDB Index
      • Cache
      • Redis
      • Messaging Queue
    • Week4
      • Project - Ecommerce
    • Week5
      • ERD - 1
    • Week6
      • Ecommerce - 2
      • Role
      • pw hashing && Salt
      • CreatedAt, ModifiedAt
      • JWT
      • Copy of ERD - 1
    • Week7
      • Vault (HashiCorp Vault)
    • Week 8
      • Api Endpoints
    • Week10
      • Product Create Workflow
  • TOY Project
    • CodeMentor
      • Implementation of Kafka
      • Project Improvement (Architectural Enhancements)
      • Communication between servers in msa
  • JAVA
    • MESI protocol in CAS
    • CAS (Compare and Set)
    • BlockingQueue
    • Producer & Consumer
    • Synchronized && ReentrantLock
    • Memory Visibility
    • Checked vs Unchecked Exception
    • Thread
    • Batch delete instead of Cascade
    • Java Questions
      • Week 1(1/2) - Basic Java
      • Week 1(2/2) - OOP
      • Week 2(1/2) - String, Exception, Generic
      • Week2(2/2) Lambda, Stream, Annotation, Reflection
      • Week3(1/2) Collections
      • Week3(2/2) Threads
      • Week4 Java Concurrency Programming
      • Week5 JVM & GC
    • Java 101
      • JVM Structure
      • Java Compiles and Execution Method
      • Override, Overload
      • Interface vs Abstract Class
      • Primitive vs Object Type
      • Identity and equality
      • String, StringBuilder, StringBuffer
      • Checked Exceptions and Unchecked Exceptions
      • Java 8 methods
      • Try-with-reources
      • Strong Coupling and Loose Coupling
      • Serialization and Deserialization
      • Concurrency Programming in Java
      • Mutable vs Immutable
      • JDK vs JRE
  • SPRING
    • DIP. Dependency Inversion Principal
    • Ioc container, di practice
    • @Transactional
    • Proxy Pattern
    • Strategy Pattern
    • Template Method Pattern
    • using profile name as variable
    • Spring Questions
      • Spring Framework
      • Spring MVC & Web Request
      • AOP (Aspect-Oriented Programming)
      • Spring Boot
      • ORM & Data Access
      • Security
      • ETC
  • DATABASE
    • Enhancing Query Performance & Stability - User list
    • Ensuring Data Consistency, Atomicity and UX Optimization (feat.Firebase)
    • Redis: Remote Dictionary Server
    • Database Questions
      • Week1 DBMS, RDBMS basics
      • Week2 SQL
      • Week3 Index
      • Week4 Anomaly, Functional Dependency, Normalization
      • Week5 DB Transaction, Recovery
    • Normalization
      • 1st Normal Form
      • 2nd Normal Form
      • 3rd Normal Form
  • NETWORK
    • HTTP & TCP head of line blocking
    • HTTP 0.9-3.0
    • Blocking, NonBlocking and Sync, Async
    • Network Questions
      • Week1 Computer Network Basic
      • Week2(1/3) Application Layer Protocol - HTTP
      • Week2(2/3) Application Layer Protocol - HTTPS
      • Week2(3/3) Application Layer Protocol - DNS
      • Week3 Application Layer
      • Week4 Transport Layer - UDP, TCP
      • Week5 Network Layer - IP Protocol
    • Network 101
      • https://www.google.com
      • TCP vs UDP
      • Http vs Https
      • TLS Handshake 1.2
      • HTTP Method
      • CORS & SOP
      • Web Server Software
  • OS
    • Operating System Questions
      • Week1 OS & How Computer Systems Work
      • Week2(1/2) Process
      • Week2(2/2) Thread
      • Week3 CPU Scheduling
      • Week4 Process Synchronize
      • Week5 Virtual Memory
    • Operating System 101
      • Operating system
        • The role of the operating system
        • The composition of the operating system.
      • Process
        • In Linux, are all processes except the initial process child processes?
        • Zombie process, orphan process
        • (Linux) Daemon process
        • Process address space
        • Where are uninitialized variables stored?
        • Determination of the size of the Stack and Heap
        • Access speed of Stack vs Heap
        • Reason for memory space partitioning
        • Process of compiling a process
        • sudo kill -9 $CURRENT_PID
      • Thread
        • Composition of a thread's address space
      • Process vs Thread
        • Creation of processes and threads in Linux
      • Multiprocessing
        • Web Browser
        • Implementation of multiprocessing
        • Application areas of multiprocessing
      • Multithreading
        • Application areas of multithreading
      • Interrupt
        • HW / SW Interrupt
        • Method of handling interrupts
        • Occurrence of two or more interrupts simultaneously
      • Polling
      • Dual Mode
        • Reason for distinguishing between user mode and kernel mode
      • System call
        • Differentiation between system calls
        • Types of system calls
        • Execution process of a system call
      • Process Control Block (PCB)
        • PCB의 구조
        • 쓰레드는 PCB를 갖고 있을까?
        • 프로세스 메모리 구조
      • Context switching
        • Timing of context switching
        • Registers saved during context switching
        • Context switching in processes
        • Context switching in threads
        • Difference between context switching in processes and threads
        • Information of the current process during context switching
      • Interprocess Communication (IPC)
        • Cases where IPC is used
        • Process address space in IPC Shared Memory technique
        • Types of IPC
  • COMPUTER SCIENCE
    • Computer Architecture 101
      • 3 components of a computer
      • RAM vs ROM
      • CPU vs GPU
      • SIMD
      • Two's complement
      • Harvard Architecture vs. von Neumann Architecture
      • The structure of a CPU.
      • Instruction cycle (CPU operation method)
      • Instruction pipelining
      • Bus
      • Memory area
      • Memory hierarchy structure
        • Reason for using memory hierarchy structure
      • Cache memory
      • L1, L2, L3 Cache
      • Locality of reference (cache)
      • Fixed-point vs Floating-point
        • epresentation of infinity and NaN (Not a Number) in floating-point
      • RISC vs CISC
      • Hamming code
      • Compiler
      • Linking
      • Compiler vs Interpreter
      • Mutex vs Semaphore
      • 32bit CPU and 64bit CPU
      • Local vs Static Variable
      • Page
  • Programming Paradigm
    • Declarative vs Imperative
  • JPA, QueryDsl
    • why fetchResults() is deprecated
  • PYTHON
    • Icecream
  • FASTAPI
    • Template Page
  • LINUX
    • Template Page
  • DATA STRUCTURE
    • Counting Sort
    • Array vs Linked List
  • GIT, Github
    • git clone, invalid path error
  • INFRA
    • Template Page
  • AWS
    • Server Log Archive Pipeline
    • Image Processing using Lambda
  • DOCKER
    • Docker and VM
    • Python Executable Environment
    • Docker commands
  • docker-compose
    • Kafka, Multi Broker
  • KUBERNATES
    • !Encountered Errors
      • my-sql restarts
      • kafka producer: disconnected
    • Kubernetes Components
    • Helm
      • Helm commands
    • Pod network
    • Service network
      • deployment.yaml
      • services.yaml
    • Service type
      • Cluster IP
      • NodePort
    • service-name-headless?
    • kube-proxy
  • GraphQL
    • Template Page
  • WEB
    • Template Page
  • Reviews
    • Graphic Intern Review
    • Kakao Brain Pathfinder Review
    • JSCODE 자바 1기 Review
  • 😁Dev Jokes
    • Image
      • Plot twist
      • Priorities
      • SQL join guide
      • Google is generous
      • Genie dislikes cloud
      • buggy bugs
      • last day of unpaid internship
      • what if clients know how to inspect
      • its just game
      • how i wrote my achievement on resume
      • self explanatory
      • chr(sum(range(ord(min(str(not))))))
Powered by GitBook
On this page
  • 1. 각 인스턴스가 본질적으로 고유하다
  • 2. 인스턴스의 '논리적 동등성'을 검사할 일이 없다
  • 3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다
  • 4. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다
  • 언제 equals를 재정의해야 하는가?
  • equals 메소드 구현 규약
  • 1. 반사성 (Reflexivity)
  • 2. 대칭성 (Symmetry)
  • 3. 추이성 (Transitivity)
  • 4. 일관성 (Consistency)
  • 5. null-아님 (Non-nullity)
  • 종합 예시
  • 올바른 equals 메소드 구현 단계
  • 결론
  1. Books
  2. Effective Java

Item10. Adhering to General Rules When Overriding equals

equals는 일반 규약을 지켜 재정의하라

자바에서 equals 메소드는 객체의 논리적 동등성을 비교하는 데 사용된다. 이는 특히 컬렉션 프레임워크에서 중요한 역할을 한다. 하지만 equals 메소드를 잘못 재정의하면 예상치 못한 문제를 일으킬 수 있다.

1. 각 인스턴스가 본질적으로 고유하다

equals 메소드는 논리적 동등성을 검사하므로, 값을 포함하는 클래스가 아니라 인스턴스가 고유한 객체에 대해 정의되어야 한다. 예를 들어 Thread 클래스와 같은 경우 Object의 equals 메소드를 그대로 사용한다. 다음은 Thread 클래스의 equals 메소드 예시이다.

@Override
public boolean equals(Object o) {
    return this == o;
}

2. 인스턴스의 '논리적 동등성'을 검사할 일이 없다

논리적 동등성(Logical Equality)을 검사할 필요가 없는 경우 equals 메소드를 재정의하지 않는다. 예를 들어, java.util.regex.Pattern 클래스는 두 Pattern 객체의 논리적 동등성을 검사하지 않는다.

3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다

추상 클래스에서 equals를 구현할 때, 모든 하위 클래스가 같은 논리적 동등성 기준을 공유하는 경우 equals 메소드를 재정의하지 않는다. 예를 들어, AbstractList와 같은 클래스는 상속받는 하위 클래스에서 추가적인 동작 없이 상위 클래스의 equals 메소드를 사용할 수 있다.

4. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다

이런 경우도 equals 메소드를 재정의할 필요가 없다. 이는 메소드가 외부에 노출되지 않기 때문이다.

언제 equals를 재정의해야 하는가?

다음은 equals 메소드를 재정의해야 하는 경우이다:

  • 객체 식별성(Object Identity): 두 객체가 동일한 객체인지 확인해야 할 때가 아니라 논리적 동등성을 확인해야 할 때. 예를 들어, 값 클래스(예: Integer, String) 등은 equals 메소드를 재정의하여 논리적 동등성을 비교해야 한다.

  • 상위 클래스의 equals가 논리적 동등성을 비교하도록 정의되지 않았을 때: 상위 클래스의 equals 메소드가 논리적 동등성을 검사하지 않는 경우, 하위 클래스에서 이를 재정의해야 한다.

  • 값을 표현하는 클래스: 값 클래스는 동일한 값을 가지는 두 객체를 논리적으로 동일하다고 간주해야 한다. 예를 들어, 두 개의 Float 객체가 동일한 값을 가질 때 논리적으로 동등하다고 판단해야 한다.

equals 메소드 구현 규약

equals 메소드는 다음과 같은 규약을 따라야 한다:

  1. 반사성(Reflexivity): 모든 비null 참조 값 x에 대해, x.equals(x)는 true이다.

  2. 대칭성(Symmetry): 모든 비null 참조 값 x와 y에 대해, x.equals(y)가 true이면 y.equals(x)도 true이다.

  3. 추이성(Transitivity): 모든 비null 참조 값 x, y, z에 대해, x.equals(y)가 true이고 y.equals(z)가 true이면 x.equals(z)도 true이다.

  4. 일관성(Consistency): 모든 비null 참조 값 x와 y에 대해, equals 비교가 일관된 결과를 반환해야 한다.

  5. null-아님(Non-nullity): null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false를 반환해야 한다.

1. 반사성 (Reflexivity)

정의

모든 비null 참조 값 x에 대해, x.equals(x)는 true이다.

설명

반사성은 객체가 자기 자신과 비교할 때 항상 true를 반환해야 한다는 의미입니다. 이는 논리적으로 타당합니다. 어떤 객체가 자신과 다르다고 판단될 이유는 없기 때문입니다. 반사성을 충족하지 않는 equals 메소드는 논리적으로 문제가 발생할 수 있습니다.

예시

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;  // 자기 자신과 비교하면 항상 true
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
}

2. 대칭성 (Symmetry)

정의

모든 비null 참조 값 x와 y에 대해, x.equals(y)가 true이면 y.equals(x)도 true이다.

설명

대칭성은 두 객체가 서로를 비교할 때 결과가 동일해야 한다는 의미입니다. 즉, x.equals(y)가 true라면 y.equals(x)도 true여야 합니다. 이를 통해 객체 비교의 일관성을 유지할 수 있습니다. 대칭성을 충족하지 않는 equals 메소드는 서로 다른 객체 간의 비교에서 일관성이 없어질 수 있습니다.

예시

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
}

3. 추이성 (Transitivity)

정의

모든 비null 참조 값 x, y, z에 대해, x.equals(y)가 true이고 y.equals(z)가 true이면 x.equals(z)도 true이다.

설명

추이성은 객체 비교의 결과가 일관되게 전달되어야 한다는 의미입니다. x가 y와 같고 y가 z와 같다면, x도 z와 같아야 합니다. 이를 통해 객체 비교의 체계적인 일관성을 유지할 수 있습니다. 추이성을 충족하지 않는 equals 메소드는 객체 간 비교 결과가 혼란스러워질 수 있습니다.

예시

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
}

4. 일관성 (Consistency)

정의

모든 비null 참조 값 x와 y에 대해, equals 비교가 일관된 결과를 반환해야 한다.

설명

일관성은 동일한 객체들 간의 비교 결과가 항상 일관되게 유지되어야 한다는 의미입니다. 만약 x와 y가 같다면, x와 y의 비교는 언제나 같은 결과를 반환해야 합니다. 이를 통해 객체 비교의 신뢰성을 유지할 수 있습니다. 일관성을 충족하지 않는 equals 메소드는 동일한 객체들 간의 비교에서 다른 결과를 반환할 수 있습니다.

예시

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
}

5. null-아님 (Non-nullity)

정의

null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false를 반환해야 한다.

설명

null-아님은 어떤 객체도 null과 비교할 때 true를 반환하지 않아야 한다는 의미입니다. 이는 객체 비교에서 null 값을 특별하게 다루기 위해 필요합니다. null과의 비교에서 true를 반환하는 것은 논리적으로 맞지 않으며, 프로그램에서 예기치 않은 오류를 일으킬 수 있습니다.

예시

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
}

종합 예시

위의 모든 규약을 충족하는 종합적인 equals 메소드 구현 예시를 보면 다음과 같습니다:

public class Person {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true; // 반사성
        if (o == null || getClass() != o.getClass()) return false; // null-아님 및 타입 체크
        Person person = (Person) o;
        return Objects.equals(name, person.name); // 핵심 필드 비교
    }

    @Override
    public int hashCode() {
        return Objects.hash(name);
    }
}

이 예시에서는 equals 메소드가 반사성, 대칭성, 추이성, 일관성, null-아님의 모든 규약을 충족하도록 구현되었습니다. 또한, equals를 재정의할 때는 반드시 hashCode 메소드도 함께 재정의해야 함을 보여줍니다.

다음은 위 규약을 준수하는 equals 메소드의 예시이다:

public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    @Override
    public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString) {
            return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
        }
        if (o instanceof String) {
            return s.equalsIgnoreCase((String) o);
        }
        return false;
    }

    // 나머지 코드는 생략
}

위 코드는 대칭성을 위반할 수 있다. 다음과 같이 수정할 수 있다:

@Override
public boolean equals(Object o) {
    if (o instanceof CaseInsensitiveString) {
        return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
    }
    return false;
}

이렇게 하면 String과 비교할 때 대칭성 문제가 발생하지 않는다.

올바른 equals 메소드 구현 단계

  1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다: 이는 성능 최적화를 위해 사용된다.

  2. instanceof 연산자로 입력이 올바른 타입인지 확인한다: 입력이 다른 타입이면 false를 반환한다.

  3. 입력을 올바른 타입으로 형변환한다: 형변환은 안전하다.

  4. 입력 객체와 자기 자신의 대응되는 ‘핵심’ 필드들이 모두 일치하는지 하나씩 검사한다: 모든 필드가 일치하면 true, 그렇지 않으면 false를 반환한다.

다음은 이 단계를 따른 PhoneNumber 클래스의 equals 메소드 예시이다:

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "지역코드");
        this.prefix = rangeCheck(prefix, 999, "프리픽스");
        this.lineNum = rangeCheck(lineNum, 9999, "가입자 번호");
    }

    private static short rangeCheck(int val, int max, String arg) {
        if (val < 0 || val > max) {
            throw new IllegalArgumentException(arg + ": " + val);
        }
        return (short) val;
    }

    @Override
    public boolean equals(Object o) {
        if (o == this) {
            return true;
        }
        if (!(o instanceof PhoneNumber)) {
            return false;
        }
        PhoneNumber pn = (PhoneNumber) o;
        return pn.lineNum == lineNum && pn.prefix == prefix && pn.areaCode == areaCode;
    }

    // 나머지 코드는 생략
}

equals를 재정의할 때 hashCode도 반드시 재정의하자

equals를 재정의할 때 hashCode 메소드도 반드시 재정의해야 한다. 그렇지 않으면 HashSet, HashMap 등 해시 기반 컬렉션의 동작이 불완전해질 수 있다.

결론

올바른 equals 메소드를 구현하는 것은 자바 프로그래밍에서 매우 중요한 부분이다. 이는 객체의 논리적 동등성을 정의하며, 특히 컬렉션 프레임워크에서 올바르게 동작하는 데 필수적이다. 따라서 equals 메소드를 재정의할 때는 반드시 일반 규약을 따르고, 필요에 따라 hashCode 메소드도 함께 재정의해야 한다.

핵심 정리:

  • equals 메소드를 재정의할 때는 일반 규약을 반드시 따라야 한다.

  • 필요할 경우 equals와 함께 hashCode도 재정의해야 한다.

  • 값 객체의 경우 모든 핵심 필드를 비교해야 한다.

  • 객체 식별성이 아닌 논리적 동등성을 검사하는 경우에만 equals를 재정의한다.

PreviousItem 9.Prefer try-with-resources to try-finallyNextHandling Transitivity Issues

Last updated 10 months ago