❓
물음표살인마 블로그
  • 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. 불변 객체란 무엇인가?
  • 1.1 불변 객체의 특징
  • 2. 불변 객체의 이점
  • 2.1 스레드 안전성
  • 2.2 오류 감소
  • 2.3 코드의 단순화
  • 3. 불변 객체 설계 방법
  • 3.2 클래스를 확장할 수 없도록 한다
  • 3.3 모든 필드를 final로 선언한다
  • 4. Lombok을 활용한 불변 객체의 구현
  • 4.1 @Value 어노테이션
  • 4.2 @Builder 어노테이션
  • 5. 불변 객체의 예시: String 클래스
  • 6. 결론
  • 7. 함수형 프로그래밍과 절차형 프로그래밍: 객체와의 연관성
  • 8. 절차형 프로그래밍과 객체
  • 8.1 절차형 프로그래밍에서의 객체 사용
  • 9. 함수형 프로그래밍과 객체
  • 9.1 함수형 프로그래밍에서의 객체 사용
  • 10. 절차형 프로그래밍의 한계와 함수형 프로그래밍의 장점
  • 11. 객체지향 프로그래밍과 함수형 프로그래밍의 결합
  1. Books
  2. Effective Java

Item17. Minimize Mutability

아이템 17 변경 가능성을 최소화하라

불변 객체는 그 상태를 변경할 수 없기 때문에, 프로그램의 안전성과 신뢰성을 높이는 데 크게 기여할 수 있다. 이러한 불변 객체는 다중 스레드 환경에서도 특별한 동기화 없이 안전하게 사용할 수 있으며, 에러 발생 가능성을 최소화할 수 있다.

1. 불변 객체란 무엇인가?

불변 객체(Immutable Object)는 생성된 후 그 상태가 절대로 바뀌지 않는 객체를 말한다. 이는 객체의 모든 필드가 초기화 후에는 변경될 수 없음을 의미한다. 불변 객체를 사용하면 예상치 못한 변경으로 인한 오류를 방지할 수 있고, 객체 간 공유가 안전하게 이루어질 수 있다.

1.1 불변 객체의 특징

  • 상태 불변성: 객체가 생성된 후 그 상태가 변경되지 않는다.

  • 객체 공유 가능성: 불변 객체는 안전하게 공유될 수 있으며, 여러 스레드가 동기화 없이 접근할 수 있다.

  • 방어적 복사 필요 없음: 불변 객체는 외부에서 그 상태를 변경할 수 없으므로, 방어적 복사(defensive copy)가 필요 없다.

2. 불변 객체의 이점

불변 객체는 다양한 장점을 제공한다. 특히 다중 스레드 환경에서 유용하며, 코드의 유지보수성과 안정성을 크게 향상시킨다.

2.1 스레드 안전성

불변 객체는 스레드 안전(thread-safe)하다. 즉, 여러 스레드가 동시에 접근해도 객체의 상태가 변경되지 않기 때문에 동기화(synchronization) 없이 안전하게 사용할 수 있다. 이는 성능 최적화와 코드의 단순화에도 기여한다.

2.2 오류 감소

불변 객체는 상태가 변하지 않기 때문에 예상치 못한 변경으로 인한 오류를 방지할 수 있다. 특히, 객체가 여러 메서드나 클래스에서 사용될 때 이러한 장점은 더욱 두드러진다. 프로그램의 일관성을 유지하고, 디버깅과 테스트를 쉽게 할 수 있게 된다.

2.3 코드의 단순화

불변 객체는 객체를 생성하는 시점 이후에 상태를 변경할 필요가 없기 때문에, 불변 객체를 사용하는 코드는 일반적으로 가변 객체를 사용하는 코드보다 간단하다. 상태 변경에 따른 복잡한 로직이 제거되므로 코드가 더욱 명료해진다.

3. 불변 객체 설계 방법

불변 객체를 설계하려면 몇 가지 규칙을 따라야 한다. 아래는 불변 객체를 설계하기 위한 5가지 기본 원칙이다.

3.1 객체 상태를 변경하는 메서드를 제공하지 않는다

불변 객체의 가장 중요한 원칙은 객체의 상태를 변경하는 메서드를 제공하지 않는 것이다. 이 말은, 객체의 필드를 변경할 수 있는 메서드(setter)를 포함하지 않는 것을 의미한다.

public class ImmutableClass
public class ImmutableClass {
    private final int value;

    public ImmutableClass(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

위 예제에서 ImmutableClass는 value 필드를 초기화하는 생성자만 제공하고, 그 값을 변경하는 메서드를 제공하지 않는다.

3.2 클래스를 확장할 수 없도록 한다

불변 객체로 설계된 클래스는 확장할 수 없도록 해야 한다. 만약 클래스를 상속받아 하위 클래스에서 상태를 변경할 수 있다면, 불변성을 유지할 수 없기 때문이다. 이를 위해 클래스에 final 키워드를 사용한다.

public final class ImmutableClass {
    // 클래스 내용 생략
}

3.3 모든 필드를 final로 선언한다

클래스의 모든 필드는 final로 선언하여, 객체가 생성된 후에 필드가 변경되지 않도록 한다. final 키워드는 필드의 값이 한 번 초기화된 후에는 변경될 수 없음을 보장한다.

private **final** int value;

3.4 모든 필드를 private로 선언한다

모든 필드를 private로 선언하여 외부에서 접근하지 못하도록 해야 한다. 이렇게 하면 객체의 내부 상태가 외부에 노출되지 않으며, 불변성을 유지할 수 있다.

**private** final int value;

3.5 가변 객체를 참조하는 필드는 방어적으로 복사한다

불변 객체가 가변 객체를 참조할 때는 그 가변 객체를 방어적으로 복사하여 내부에 저장해야 한다. 이렇게 하면 외부에서 가변 객체를 변경하더라도 불변 객체의 상태가 변하지 않도록 보호할 수 있다.

public final class ImmutableClass
import java.util.Date;

public final class ImmutableClass {
    private final Date date;

    public ImmutableClass(Date date) {
        this.date = new Date(date.getTime()); // 방어적 복사
    }

    public Date getDate() {
        return new Date(date.getTime()); // 방어적 복사
    }
}

위 예제에서 Date 객체는 가변 객체이기 때문에, ImmutableClass에서 해당 객체를 직접 참조하지 않고 방어적으로 복사하여 사용한다.

4. Lombok을 활용한 불변 객체의 구현

Lombok은 자바에서 반복적인 코드를 줄여주는 유용한 라이브러리다. 특히 불변 객체를 쉽게 구현할 수 있도록 도와주는 @Value와 @Builder 등의 어노테이션을 제공한다. 이를 활용하여 불변 객체를 더 간단하게 작성할 수 있다.

4.1 @Value 어노테이션

@Value 어노테이션을 사용하면, 불변 객체를 간단하게 생성할 수 있다. @Value는 클래스의 모든 필드를 final과 private으로 선언하고, 생성자, getter 메서드, toString, equals, hashCode 메서드를 자동으로 생성해준다.

import lombok.Value;

@Value
public class ImmutableClass {
    int value;
}

위 예제에서 ImmutableClass는 Lombok의 @Value 어노테이션을 통해 불변 객체로 쉽게 선언되었다.

4.2 @Builder 어노테이션

Lombok의 @Builder 어노테이션은 빌더 패턴을 사용하여 객체를 생성할 수 있도록 도와준다. 빌더 패턴은 불변 객체를 생성할 때 특히 유용한 패턴으로, 복잡한 객체를 단계적으로 생성할 수 있다.

import lombok.Builder;
import lombok.Value;

@Value
@Builder
public class ImmutableClass {
    int value;
    String name;
}

위 예제에서 ImmutableClass는 빌더 패턴을 통해 불변 객체로 생성되었다. 빌더 패턴을 사용하면 코드의 가독성을 높이고, 더 유연하게 객체를 생성할 수 있다.

5. 불변 객체의 예시: String 클래스

Java의 String 클래스는 대표적인 불변 객체이다. String 클래스는 한 번 생성되면 그 값을 변경할 수 없으며, 모든 String 메서드는 새로운 String 객체를 반환한다. 이러한 불변성 덕분에 String 클래스는 안전하게 공유될 수 있으며, 여러 스레드가 동시에 사용할 수 있다.

String str = "Hello";
str.toUpperCase(); // 새로운 "HELLO" 객체 반환, 원본 "Hello"는 변경되지 않음

위 예제에서 toUpperCase() 메서드는 새로운 String 객체를 반환하며, 원래의 str은 여전히 "Hello" 값을 유지한다.

6. 결론

불변 객체는 자바 프로그램에서 안전성과 신뢰성을 높이는 중요한 개념이다. 불변 객체를 설계하고 사용하는 것은 오류를 줄이고, 유지보수성을 높이며, 특히 다중 스레드 환경에서 큰 이점을 제공한다. 이펙티브 자바의 아이템 17에서는 이러한 불변 객체의 중요성을 강조하며, 불변 객체를 효과적으로 설계하기 위한 가이드라인을 제공하고 있다. 또한, Lombok을 사용하여 불변 객체를 더 쉽게 구현할 수 있으며, 이를 통해 반복적인 코드를 줄이고 코드의 가독성을 높일 수 있다.

불변 객체를 설계할 때는 이 가이드라인을 따르고, 코드의 안정성과 일관성을 유지하는 데 주의를 기울여야 한다. 이를 통해 보다 견고하고 유지보수하기 쉬운 프로그램을 작성할 수 있을 것이다.

7. 함수형 프로그래밍과 절차형 프로그래밍: 객체와의 연관성

불변 객체의 개념을 이해하려면, 함수형 프로그래밍과 절차형 프로그래밍이 객체를 어떻게 다루는지 알아보는 것이 중요하다. 두 프로그래밍 패러다임은 객체의 상태 관리 방식에서 근본적인 차이를 보이며, 이는 프로그램의 안정성과 유지보수성에 큰 영향을 미친다.

8. 절차형 프로그래밍과 객체

절차형 프로그래밍은 프로그램을 일련의 명령어 또는 절차로 구성하며, 객체의 상태는 프로그램 실행 중 계속해서 변경될 수 있다. 이 패러다임에서는 객체가 상태를 가지며, 해당 상태를 변경하는 메서드가 일반적으로 사용된다.

8.1 절차형 프로그래밍에서의 객체 사용

절차형 프로그래밍에서 객체는 주로 상태를 변경하기 위해 사용된다. 예를 들어, 객체가 필드를 가지고 있으며, 이 필드는 메서드를 통해 변경될 수 있다. 이러한 방식은 프로그램이 동작하는 동안 객체의 상태가 여러 번 변경될 수 있음을 의미한다.

public class Account
public class Account {
    private double balance;

    public Account(double initialBalance) {
        this.balance = initialBalance;
    }

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        balance -= amount;
    }

    public double getBalance() {
        return balance;
    }
}

위 예제에서 Account 클래스는 balance라는 상태를 가지고 있으며, deposit과 withdraw 메서드를 통해 이 상태를 변경할 수 있다. 이러한 절차형 프로그래밍 스타일에서는 객체의 상태가 여러 번 변경될 수 있으며, 프로그램의 로직에 따라 그 상태가 바뀌는 것이 일반적이다.

9. 함수형 프로그래밍과 객체

함수형 프로그래밍은 불변성을 중심으로 설계된다. 함수형 프로그래밍에서는 객체의 상태를 변경하지 않고, 새로운 객체를 생성하여 변경된 상태를 반영한다. 이는 객체가 한번 생성되면 그 상태가 절대 변하지 않는다는 것을 의미하며, 불변 객체를 사용하여 프로그램의 예측 가능성과 안정성을 높인다.

9.1 함수형 프로그래밍에서의 객체 사용

함수형 프로그래밍에서 객체는 상태를 변경하지 않는 불변 객체로 사용된다. 상태를 변경할 필요가 있을 때는 기존 객체를 변경하는 대신, 변경된 값을 가진 새로운 객체를 반환한다.

public final class Account
public final class Account {
    private final double balance;

    public Account(double initialBalance) {
        this.balance = initialBalance;
    }

    public Account deposit(double amount) {
        return new Account(this.balance + amount);
    }

    public Account withdraw(double amount) {
        return new Account(this.balance - amount);
    }

    public double getBalance() {
        return balance;
    }
}

위 예제에서 Account 클래스는 불변 객체로 설계되었다. deposit과 withdraw 메서드는 새로운 Account 객체를 반환하며, 기존 객체의 상태를 변경하지 않는다. 이러한 방식은 객체가 불변성을 유지하도록 하며, 프로그램의 상태 관리가 더욱 간결하고 예측 가능해진다.

10. 절차형 프로그래밍의 한계와 함수형 프로그래밍의 장점

절차형 프로그래밍에서 객체의 상태가 자주 변경되면, 프로그램의 흐름을 추적하고 디버깅하기 어려워진다. 상태 변경이 많아질수록 예상치 못한 부작용(side effects)이 발생할 가능성도 높아진다. 특히 다중 스레드 환경에서는 동기화 문제로 인해 상태 관리가 복잡해지며, 버그 발생 가능성이 커진다.

반면, 함수형 프로그래밍은 객체의 상태를 변경하지 않으므로, 프로그램이 더욱 안정적이고 예측 가능해진다. 불변 객체는 다중 스레드 환경에서도 안전하게 공유될 수 있으며, 상태 변경으로 인한 부작용을 피할 수 있다. 이는 코드의 가독성을 높이고, 유지보수를 용이하게 만든다.

11. 객체지향 프로그래밍과 함수형 프로그래밍의 결합

Java와 같은 객체지향 프로그래밍 언어에서는 절차형 프로그래밍과 함수형 프로그래밍의 장점을 결합할 수 있다. 객체지향 언어에서 불변 객체를 사용하면, 객체지향의 캡슐화(encapsulation)와 상속(inheritance) 같은 이점을 누리면서도 함수형 프로그래밍의 불변성과 순수 함수의 장점을 활용할 수 있다.

public class Account
import lombok.Value;

@Value
public class Account {
    double balance;

    public Account deposit(double amount) {
        return new Account(balance + amount);
    }

    public Account withdraw(double amount) {
        return new Account(balance - amount);
    }
}

위 예제에서는 Lombok의 @Value 어노테이션을 사용하여 불변 객체를 더 쉽게 생성할 수 있다. 이처럼 객체지향 프로그래밍과 함수형 프로그래밍을 결합하면, 코드의 안정성을 높이고 유지보수를 쉽게 하면서도 객체지향의 유연성을 유지할 수 있다.

PreviousItem16. Accessor Methods Over Public FieldsNextItem18. Composition over inherentance

Last updated 9 months ago