JVM은 CPU나 운영체제의 종류와 무관하게 실행 가능하다.

JVM은 아래와 같이 주요한 기능들을 제공한다.

• Loads code : 작성된 코드를 로드 (읽기)
• Verifies code : 코드 검증 및 확인 (문법 검증, 정상적으로 동작하는지 확인)
• Executes code : 코드 실행 (실제 머신에서 코드를 실행해 프로그램을 구동)
• Provides Runtime Environment : 런타임 환경 제공 (어떠한 장비에서건 구동이 되기 위해 기본 베이스 환경 구축)

JRE : Java Runtime Environment. 자바 실행 환경을 의미한다. JVM을 동작시키는데 필요한 각종 자바 클래스 라이브러리들을 담고 있다.

JDK : Java Development Kit = 자바 개발 키트 (JRE + 개발툴) JRE와 javac 등의 컴파일러, 디버거 등을 포함하는 프로그램이다.

JVM과 JRE, JDK의 포함관계를 나타낸 가장 간단하고 이해가 쉬운 그림이다.

JVM를 사용하기 위한 라이브러리가 JRE이며, 일반적인 자바 프로그램을 실행하기 위해 사용되는것이 JRE이다.

JDK는 JRE를 포함하고 있으며, 컴파일러와 디버거등이 포함된 버전이다. 개발자라면 JDK를 설치해야한다.

https://cryptosalamander.tistory.com/4

JVM(Java Virtual Machine)

: 자바 가상 머신으로 자바 바이트 코드를 실행할 수 있는 주체다.

CPU나 운영체제(플랫폼)의 종류와 무관하게 실행이 가능하다.

즉, 운영체제 위에서 동작하는 프로세스로 자바 코드를 컴파일해서 얻은 바이트 코드를 해당 운영체제가 이해할 수 있는 기계어로 바꿔 실행시켜주는 역할을 한다.

JVM의 구성을 살펴보면 크게 4가지 (Class Loader, Execution Engine, Garbage Collector, Runtime Data Area)로 나뉜다.

자바에서 소스를 작성하면 Person.java 처럼 .java파일이 생성된다.

.java 소스를 자바컴파일러가 컴파일하면 Person.class 같은 .class파일**(바이트코드)**이 생성된다.

이렇게 생성된 클래스파일들을 엮어서 JVM이 운영체제로부터 할당받은 메모리영역인 Runtime Data Area로 로드하는 역할 (자바 애플리케이션이 실행중일 때 이런 작업이 수행된다.)

Class Loader에 의해 메모리에 적재된 클래스(바이트 코드)들을 기계어로 변경해 명령어 단위로 실행하는 역할을 한다.

명령어를 하나 하나 실행하는 인터프리터(Interpreter)방식이 있고 JIT(Just-In-Time) 컴파일러를 이용하는 방식이 있다.

JIT 컴파일러는 적절한 시간에 전체 바이트 코드를 네이티브 코드로 변경해서 Execution Engine이 네이티브로 컴파일된 코드를 실행하는 것으로 성능을 높이는 방식이다.

Garbage Collector(GC)는 Heap 메모리 영역에 생성(적재)된 객체들 중에 참조되지 않는 객체들을 탐색 후 제거하는 역할을 한다.

GC가 역할을 하는 시간은 정확히 언제인지를 알 수 없다. (참조가 없어지자마자 해제되는 것을 보장하지 않음)

또 다른 특징은 GC가 수행되는 동안 GC를 수행하는 쓰레드가 아닌 다른 모든 쓰레드가 일시정지된다.

특히 Full GC가 일어나서 수 초간 모든 쓰레드가 정지한다면 장애로 이어지는 치명적인 문제가 생길 수 있는 것이다.

JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 저장하는 영역이다.

JVM이 운영체제 위에서 실행되면서 할당받는 메모리 영역이다. Class Loader에서 준비한 데이터들을 보관하는 저장소이다.

이 영역은 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

• 자바 런타임 메모리(Runtime Data area)구조

JVM이 읽어들인 클래스와 인터페이스 대한 런타임 상수 풀, 멤버 변수(필드), 클래스 변수(Static 변수), 생성자와 메소드를 저장하는 공간이다.

Runtime Constant Pool

• 메소드 영역에 포함되지만 독자적 중요성이 있다.
• 클래스 파일 constant_pool 테이블에 해당하는 영역이다.
• 클래스와 인터페이스 상수, 메소드와 필드에 대한 모든 레퍼런스를 저장한다.
• JVM은 런타임 상수 풀을 통해 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조한다

메소드 영역/런타임 상수 풀의 사용기간 및 스레드 공유 범위

• JVM 시작시 생성
• 프로그램 종료 시까지
• 명시적으로 null 선언 시
• 구성 방식이나 GC 방법은 JVM 벤더마다 다를 수 있다.
• 모든 스레드에서 공유한다.

• JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.
• New 연산자로 생성된 객체 또는 객체(인스턴스)와 배열을 저장한다.
• 힙 영역에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다.
• 참조하는 변수나 필드가 없다면 의미 없는 객체가 되어 GC의 대상이 된다.
• 힙 영역의 사용기간 및 스레드 공유 범위 객체가 더 이상 사용되지 않거나 명시적으로 null 선언 시 GC(Garbage Collection) 대상 구성 방식이나 GC 방법은 JVM 벤더마다 다를 수 있다. 모든 스레드에서 공유한다.

지역 변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값등이 생성되는 영역이다.

int a = 10; 이라는 소스를 작성했다면 정수값이 할당될 수 있는 메모리공간을 a라고 잡아두고 그 메모리 영역에 값이 10이 들어간다. 즉, 스택에 메모리에 이름이 a라고 붙여주고 값이 10인 메모리 공간을 만든다.

클래스 Person p = new Person(); 이라는 소스를 작성했다면 Person p는 스택 영역에 생성되고 new로 생성된 Person 클래스의 인스턴스는 힙 영역에 생성된다.

그리고 스택영역에 생성된 p의 값으로 힙 영역의 주소값을 가지고 있다. 즉, 스택 영역에 생성된 p가 힙 영역에 생성된 객체를 가리키고(참조하고) 있는 것이다.

메소드를 호출할 때마다 개별적으로 스택이 생성된다.

• 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다.
• 메소드를 호출할 때마다 프레임(Frame)을 추가(push)하고 메소드가 종료되면 해당 프레임을 제거(pop)하는 동작을 수행한다.
• 선입후출(FILO, First In Last Out) 구조로 push와 pop 기능 사용
• 메소드 호출 시 생성되는 스레드 수행정보를 기록하는 Frame을 저장
• 메소드 정보, 지역변수, 매개변수, 연산 중 발생하는 임시 데이터 저장
• 기본(원시)타입 변수는 스택 영역에 직접 값을 가진다.
• 참조타임 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다.

Thread(쓰레드)가 생성될 때마다 생성되는 영역으로 Program Counter 즉, 현재 쓰레드가 실행되는 부분의 주소와 명령을 저장하고 있는 영역이다. (*CPU의 레지스터와 다름)

이것을 이용해서 쓰레드를 돌아가면서 수행할 수 있게 한다.

자바 외 언어로 작성된 네이티브 코드를 위한 메모리 영역이다.

보통 C/C++등의 코드를 수행하기 위한 스택이다. (JNI)

쓰레드가 생성되었을 때 기준으로

1,2번인 메소드 영역과 힙 영역을 모든 쓰레드가 공유하고,

3,4,5번인 스택 영역과 PC 레지스터, Native method stack은 각각의 쓰레드마다 생성되고 공유되지 않는다.

Heap area & Garbage Collector

힙 영역은 좀 더 살펴봐야하는데 그 이유는 GC의 주요 대상이기 때문이다.

(Stack영역과 Method영역도 GC의 대상이 된다)

• Young Generation: 이 영역은 자바 객체가 생성되자마자 저장되고, 생긴지 얼마 안되는 객체가 저장되는 공간이다. 시간이 지나 우선순위가 낮아지면 Old 영역으로 옮겨진다. 이 영역에서 객체가 사라질 때 Minor GC가 발생한다.
• Old(Tenured) Generation: Young Generation 영역에서 저장되었던 객체 중에 오래된 객체가 이동되어 저장되는 영역이다. 이 영역에서 객체가 사라질 때 Major GC(Full GC)가 발생한다.

힙 영역은 우선 5개의 영역**(eden, survivor1, survivor2, old, permanent)**으로 나뉜다.

-> JDK7까지는 permanent영역이 heap에 존재했습니다. JDK8부터는 permanent 영역은 사라지고 일부가 "meta space 영역"으로 변경되었습니다. (위의 그림 JDK7 기준입니다.) meta space 영역은 Native stack 영역에 포함되었습니다.

(survivor영역의 숫자는 의미없고 두 개로 나뉜다는 것이 중요하다)

힙 영역을 굳이 5개로 나눈 이유는 효율적으로 GC가 일어나게 하기 위함이다. 자세한 것은 GC가 일어나는 프로세스를 보면서 설명한다.

GC는 Minor GC와 Major GC로 나뉜다.

- Minor GC : New 영역에서 일어나는 GC

1. 최초에 객체가 생성되면 Eden영역에 생성된다.

2. Eden영역에 객체가 가득차게 되면 첫 번째 GC가 일어난다.

3. survivor1 영역에 Eden영역의 메모리를 그대로 복사한다. 그리고 survivor1 영역을 제외한 다른 영역의 객체를 제거한다.

4. Eden영역도 가득차고 survivor1영역도 가득차게된다면, Eden영역에 생성된 객체와 survivor1영역에 생성된 객체 중에 참조되고 있는 객체가 있는지 검사한다.

5. 참조 되고있지 않은 객체는 내버려두고 참조되고 있는 객체만 survivor2영역에 복사한다.

6. survivor2영역을 제외한 다른 영역의 객체들을 제거한다.

7. 위의 과정중에 일정 횟수 이상 참조되고 있는 객체들을 survivor2에서 Old영역으로 이동시킨다.

• 위 과정을 계속 반복, survivor2영역까지 꽉차기 전에 계속해서 Old로 비움

- Major GC(Full GC) : Old 영역에서 일어나는 GC

1. Old 영역에 있는 모든 객체들을 검사하며 참조되고 있는지 확인한다.

2. 참조되지 않은 객체들을 모아 한 번에 제거한다.

• Minor GC보다 시간이 훨씬 많이 걸리고 실행중에 GC를 제외한 모든 쓰레드가 중지한다.

• Major GC(Full GC)가 일어나면,

Old영역에 있는 참조가 없는 객체들을 표시하고 그 해당 객체들을 모두 제거하게 된다.

그러면서 **Heap 메모리 영역에 중간중간 구멍(**제거되고 빈 메모리 공간)이 생기는데 이 부분을 없애기 위해 재구성을 하게 된다. (디스크 조각모음처럼 조각난 메모리를 정리함)

따라서 메모리를 옮기고 있는데 다른 쓰레드가 메모리를 사용해버리면 안되기 때문에 모든 쓰레드가 정지하게 되는 것이다.

스프링, 정확하게는 스프링 프레임워크이다. 먼저 스프링에 대해 이해하기 위해서는 프레임워크가 무엇인지, 라이브러리와의 차이가 어떤건지 알고 가는게 가장 중요하다. 라이브러리는 간단하게 특정 기능을 하는 코드 뭉치이다. 개발자는 자기 코드에 라이브러리를 포함시키고 원하는 기능을 사용해서 개발을 할 수 있다. 더욱 간단하게는 원하는 기능을 하는 함수를 콜해서 사용하는 것으로 라이브러리를 활용한다. 

프레임워크는 라이브러리를 포함하는 개념이고, 개발자가 만든 코드를 사용한다. 코드를 어떻게 실행하는지는 코드를 사용하는 프레임워크에 달려있다.

스프링 사이트에서는 스프링 프레임워크가 인프라와 관련된 내용을 애플리케이션 레벨에서 설정하도록 해줌으로써 개발자가 코드로 대부분을 컨트롤 할 수 있게끔 지원한다고 설명한다. 즉, 개발자가 코드 안에 애플리케이션 동작에 대한 내용을 기술하면 스프링 프레임워크가 이를 해석해서 동작하는 것이다. 스프링을 사용하는 가장 일반적인 예로는 Servlet API 가 있다. 개발자는 API를 처리할 클래스를 정의하고 이것이 Servlet API 를 위한 클래스임을 표시(어노테이션 활용)한다. 그 이후 프로그램을 실행하면 스프링은 API 요청이 들어오면 해당 클래스를 이용해서 처리한다. 개발자가 Servlet에 관련된 것을 개발하지 않아도 되며, 데이터 바인딩, 객체 생성 등 왠만한 것들은 스프링이 알아서 해준다. 이런 편한 점 때문에 많은 개발자들이 스프링 프레임워크를 사용하고 있다.

모든 Spring 모듈들의 핵심은 의존성 주입과 IoC(Inversion of Control)이라고 할 수 있습니다. 이렇게 의존성 주입과 IoC를 통해 소스변경을 최소화 하며 프로그램을 제어할 수 있습니다.

스프링 프레임워크는 기능이 많은만큼 환경설정이 복잡한 편이다. 이에 어려움을 느끼는 사용자들을 위해 나온 것이 바로 스프링 부트다.

스프링 부트는 스프링 프레임워크를 사용하기 위한 설정의 많은 부분을 자동화하여 사용자가 정말 편하게 스프링을 활용할 수 있도록 돕는다.

스프링 부트 starter 디펜던시만 추가해주면 바로 API를 정의하고, 내장된 탐캣이나 제티(= 내장 서블릿 컨테이너

)로 웹 애플리케이션 서버를 실행할 수 있다. 심지어 스프링 홈페이지의 이니셜라이저를 사용하면 바로 실행 가능한 코드를 만들어준다. 실행환경이나 의존성 관리 등의 인프라 관련 등은 신경쓸 필요 없이 바로 코딩을 시작하면 된다. 그리고 바로 그것이 스프링의 키 포인트이다.

• 의존성 관리 (spring-boot-starter~의 역할 - 관련 jar파일들을 자동으로 다운로드)
• 자동 설정 (@SpringBootApplication, 컴포넌트 스캔역할)
• 내장 웹서버(tomcat, netty, jetty, undertow)

좀더 자세히 설명해보면, 모든 웹 애플리케이션들이 다음과 비슷한 요구사항들을 갖죠. Spring MVC, Jackson Databind (데이터 바인딩 용), Hibernate-Validator (Java Validation API 를 이용한 서버사이드 유효성 확인 용), Log4j (로깅용). 우리가 이 코스를 생성하려면 이 모든 프레임워크들이 호환되는 버전을 선택해야 했습니다.

하지만 Spring Boot는 스타터들을 제공합니다. 아래는 Spring Boot에서 언급한 스타터입니다.

스타터들은 편리한 종속성 기술자들(dependency descriptors)로서 여러분은 이 것을 애플리케이션에 포함시킬 수 있다. 여러분은 모든 스프링과 여러분이 필요로하는 관련 기술을 얻을 수 있는 올인원 쇼핑몰을 얻는 것으로 굳이 샘플코드를 찾아보거나 로드할 종속성 기술자들을 복사/붙여넣기 하지 않아도 된다. 예를들어 여러분이 스프링과 데이터베이스 접근을위한 JPA 를 사용하고 싶다면 여러분의 프로젝트에 spring-boot-starter-data-jpa 종속성을 포함시키고 진행하면 된다.

즉 JPA를 구성하는데 필요했던 연관된 여러 라이브러리들을 한꺼번에 패키지로 다운로드해주고, datasource와 같은 복잡한 설정들을 따로 configuration 클래스에서 관련된 빈을 추가하여 하나하나 설정할 필요가 없고, application.properties 파일이나 application.yml 파일에 간단한 설정 코드로 설정을 끝낼 수 있다.

또한 dispatcherServlet 설정, componentscan 설정 등의 번거로운 작업도 spring-boot-starter-web의 dependency 추가만으로 알아서 해준다.

@SpringBootApplication 어노테이션이 붙은 패키지 내 모든 Component 를 스캔하며,

starter~ dependency를 추가할떄 (starter) 버전 명시를 안해도, 해당 기능을 필요한 다른 연관된 많은 라이브러리들의 적절한 버전을 알아서 다운로드해준다. (DEPENDENCY MANAGEMENT) - 개발자가 관리해야할 의존성이 줄어든다.

트랜잭션의 경계설정을 담당하는 코드는 일정한 패턴을 갖는 유사한 구조다. 이렇게 여러 기술의 사용 방법에 공통점이 있다면 추상화를 생각해볼 수 있다. 추상화란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접근할 수가 있다.

트랜잭션 처리 코드에도 추상화를 도입해볼 수 있지 않을까? 모든 기술이 트랜잭션 개념을 갖고 있으니 트랜잭션 경계설정 방법에서 공통점이 있을 것이다. 이 공통적인 특징들을 모아서 추상화된 트랜잭션 관리 계층을 만들 수 있다. 그리고 애플리케이션 코드에서는 트랜잭션 추상 계층이 제공하는 API를 이용해 트랜잭션을 이용하게 만들어준다면 특정 기술에 종속되지 않는 트랜잭션 경계설정 코드를 만들 수 있을 것이다.

스프링은 트랜잭션 기술의 공통점을 담은 트랜잭션 추상화 기술을 제공하고 있다. 이를 이용하면 애플리케이션에서 직접 각 기술의 트랜잭션 API를 이용하지 않고도, 일관된 방식으로 트랜잭션을 제어하는 트랜잭션 경계설정 작업이 가능해진다.

class UserService {
		private PlatformTransactionManager transactionManager;
		
		public void setTransactionManager(PlatformTransactionManager transactionManager) {
			this.transactionManager = transactionManager;
			// DI로 외부에서 구현체를 받는다. 
			// JdbcTemplate을 사용하고 싶으면 DataSourceTransactionManager 
			// JTA를 사용하고 싶으면 JTATransactionManager 
			// JPA를 사용하고 싶으면 JPATransactionManager
		}

		public void upgradeLevels() {
			TransactionStatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition());
			try {
					List<User> users = userDao.getAll(); 
					for (User user : users) {
						if (canUpgradeLevel(user)) {
							upgradeLevel(user); 
						} 
					}
			this.transactionManager.commit(status); 
			} catch (RuntimeException e) { 
					this.transactionManager.rollback(status);
					throw e; 
			} 
		}
}
출처: https://www.wbluke.com/16 [함께 자라기]

스프링이 제공하는 트랜잭션 경계설정을 위한 추상 인터페이스는 PlatformTransactionManager이다. 스프링의 트랜잭션 추상화 기술은 앞에서 적용해봤던 트랜잭션 동기화를 사용한다. 이제 UserService는 트랜잭션 기술에서 완전히 독립적인 코드가 됐다.

이렇게 기술과 서비스에 대한 추상화 기법을 적용하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다. UserDao와 UserService는 각각 담당하는 코드의 기능적인 관심에 따라 분리되고, 서로 불필요한 영향을 주지 않으면서 독자적으로 확장이 가능하도록 만든 것이다. 같은 애플리케이션 로직을 담은 코드지만 내용에 따라 분리했다. 같은 계층에서 수평적인 분리라고 볼 수 있다.

트랜잭션의 추상화는 이와는 좀 다르다. 애플리케이션의 비즈니스 로직과 그 하위에서 동작하는 로우레벨의 트랜잭션 기술이라는 아예 다른 계층의 특성을 갖는 코드를 분리한 것이다.

애플리케이션 로직의 종류에 따른 수평적인 구분이든, 로직과 기술이라는 수직적인 구분이든 모두 결합도가 낮으며, 서로 영향을 주지 않고 자유롭게 확장될 수 있는 구조를 만들 수 있는 데는 스프링의 DI가 중요한 역할을 하고 있다.

DI의 가치는 이렇게 관심, 책임, 성격이 다른 코드를 깔끔하게 분리하는 데 있다.

※ 단일 책임 원칙(Single Responsibility Principle)

단일 책임 원칙은 하나의 모듈은 한 가지 책임을 가져야 한다는 의미다. 하나의 모듈이 바뀌는 이유는 한 가지여야 한다고 설명할 수도 있다.

단일 책임 원칙을 지키는 코드가 되면 어떤 장점이 있을까? 단일 책임 원칙을 잘 지키고 있다면, 어떤 변경이 필요할 때 수정 대상이 명확해진다. 이 원칙이 잘 지켜지지 않은 상태라면, 하나의 변경 사항이 생길 때마다 수 백개의 클래스들과 테스트들을 수정해주어야 할지도 모른다. 그래서 적절하게 책임과 관심이 다른 코드를 분리하고, 서로 영향을 주지 않도록 다양한 추상화 기법을 도입하고, 애플리케이션 로직과 기술/환경을 분리하는 등의 작업은 갈수록 복잡해지는 엔터프라이즈 애플리케이션에는 반드시 필요하다. 이를 위한 핵심적인 도구가 바로 스프링이 제공하는 DI다.

객체지향 설계와 프로그래밍의 원칙은 서로 긴밀하게 관련이 있다. 단일 책임 원칙을 잘 지키는 코드를 만들려면 인터페이스를 도입하고 이를 DI로 연결해야 하며, 그 결과로 단일 책임 원칙뿐 아니라 개방 폐쇄 원칙도 잘 지키고, 모듈 간에 결합도가 낮아서 서로의 변경이 영향을 주지 않고, 같은 이유로 변경이 단일 책임에 집중되는 응집도 높은 코드가 나오니까 말이다. 심지어 이런 과정에서 전략 패턴, 어댑터 패턴, 브리지 패턴, 미디에이터 패턴 등 많은 디자인 패턴이 자연스럽게 적용되기도 한다. 객체 지향 설계 원칙을 잘 지켜서 만든 코드는 테스트하기도 편하다. 스프링이 지원하는 DI와 싱글톤 레지스트리 덕분에 더욱 편리하게 자동화된 테스트를 만들 수 있다.

서비스 추상화란 Spring framework는 물론 객체지향 프로그래밍에서 아주 중요한 개념이다. 간단히 이야기하면 개발환경, 혹은 어떠한 비즈니스 로직을 위한 로우레벨의 기술에 구애 받지 않게 하기위해서, 그리고 책임을 분리 시키기 위한 추상화 개념이다. 

예를 들어서 PlatformTransactionManager 같은 경우가 서비스 추상화의 대표적인 예이다. 트랜잭션을 관리한다는 것은 크게 보면 디비의 트랜잭션을 관리한다는 말이다. 그렇다면? 과연 디비라는 것은 종류가 하나인 것인가? 아니다. JDBC,하이버네이트 등등 아주 많은 디비의 종류가 있다.

그렇다면 각자의 디비의 트랜잭션을 관리하기 위해 각각다른 트랜잭션 코드가 필요하다면? 만약 디비가 바뀌게 된다면 그에 따라 트랜잭션 관리 코드 또한 바뀌어야 할것이다.

여기서 중요한 개념이 서비스 추상화 개념이다. 트랜잭션을 관리하기 위한 최상위 인터페이스인 PlatformTransactionManager를 선언하고 각 디비에 대한 transactionManager 클래스를 DI해주면? 트랜잭션 관련 코드는 통일되는 동시에 디비가 바뀐다면 DI설정만 교체해주면 된다. 디비가 바뀌게 되더라도 트랜잭션 관련코드의 변경은 하나도 없는것이다. 이것이 서비스 추상화의 장점인 것이다.

https://www.wbluke.com/16

• 순차적인 처리가 중요
• 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법
• c언어
• 컴퓨터의 작업 처리 방식과 유사 (객체 지향 언어보다 더 빨리 처리됨)
• 프로시져로 프로그램을 구성하는 기법
• 데이터를 중심으로 함수 구현

• 소프트웨어, 컴파일러의 발달로 하드웨어가 소프트웨어의 발달을 따라오지 못하는 배경에서 등장
• 개발하려는 기능들을 묶어 모듈화 → 하드웨어가 같은 기능을 중복 연산하지 않도록 함
• 모듈의 재활용성 → 하드웨어의 처리량을 획기적으로 줄임
• 실제 세계를 모델링
• 데이터와 절차를 하나로 묶어서 생각
• 객체는 자신만의 데이터와 프로시저를 갖는다.
• 객체는 자신만이 기능을 제공하며, 각 객체들은 서로 연결되어 다른 객체가 제공하는 기능을 사용할 수 있다.
• 기능을 중심으로 객체 내에 메서드를 구현
• 객체가 갖는 책임은 작을 수록 좋다.
• 객체는 각 가지고 있는 기능으로 정의 → 한 객체가 갖는 책임을 정의한것이 인터페이스
• 캡슐화 : 객체의 내부 구현(특히 데이터)을 외부에 노출하지 않음
• 상속 : 이미 작성된 클래스를 이어받아 새로운 클래스 생성 (부모 클래스 기능 재활용)
• 다형성 : 하나의 이름으로 많은 상황에 대처하는 기법
• 코드의 재활용성이 높다
• 코딩이 절차비향에 비해 간단
• 디버깅이 쉽다
• 설계에 많은 시간이 들어간다

https://brownbears.tistory.com/407
https://pjh3749.tistory.com/244

SOLID 원칙이란 객체지향 설계에서 지켜줘야 할 5개의 원칙( SRP, OCP, LSP, DIP, ISP )을 말합니다.

이러한 설계원칙을 알아야 하는 이유는 시스템에 예상하지 못한 변경사항이 발생하더라도, 유연하게 대처하고 이후에 확장성이 있는 시스템 구조를 설계하기 위해서입니다.

좋은 설계란 시스템에 새로운 요구사항이나 변경사항이 있을 때, 영향을 받는 범위가 적은 구조를 말합니다.

객체는 단 하나의 책임만 가져야 한다는 원칙을 말합니다.

객체지향적으로 설계할 때는 응집도를 높게, 결합도는 낮게 설계하는 것이 좋습니다.

• 응집도
  • 한 프로그램의 요소가 얼마나 뭉쳐있는지, 즉 구성 요소들 사이의 응집력을 말합니다.
• 결합도
  • 프로그램 구성 요소들 사이가 얼마나 의존적인지를 말합니다.

SRP에 따른 설계를 하면 응집도는 높게, 결합도는 낮게 설계할 수 있게 됩니다.

흔히 함수는 하나의 기능만 수행하도록 구현되어야 하는 것을 알고 있습니다.

calculator() 함수가 덧셈, 뺼셈, 곱셈, 나눗셈을 모두 한다면 이는 좋은 설계가 아닙니다.

덧셈, 뺼셈, 곱셈, 나눗셈이 각각의 함수로 정의되어 있어야 유지보수가 쉬울 것입니다.

마찬가지로 Calculator 객체가 있을 때, Calculator 객체는 덧셈, 뺄셈, 곱셈, 나눗셈만 할 수 있어야 합니다.

즉, 사칙연산에 대한 책임만 갖고 있어야 합니다.

이후에 계산기에 알람 기능을 추가한다고 해서, alarm() 함수를 Calculator의 기능으로 추가하는 것은 SRP에 위배됩니다.

한 객체에 책임이 많아질수록 클래스 내부에서 서로 다른 역할을 수행하는 코드끼리 강하게 결합될 가능성이 높아집니다.

즉, 객체마다 책임을 제대로 나누지 않는다면 시스템은 매우 복잡해집니다.

왜냐하면 그 객체가 하는 일( 함수 )에 변경사항이 생기면 이 기능을 사용하는 부분의 코드를 모두 다시 테스트를 해야 하기 때문입니다.

따라서 여러 객체들이 하나의 책임만 갖도록 잘 분배한다면, 시스템에 변화가 생기더라도 그 영향을 최소화 할 수 있기 때문에 SRP 원칙을 따르는 것이 좋습니다.

기존의 코드를 변경하지 않으면서( closed ), 기능을 추가할 수 있도록( open ) 설계가 되어야 한다는 원칙을 말합니다.

즉, 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다는 의미를 갖습니다.

이를 만족하는 설계가 되려면, 캡슐화를 통해 여러 객체에서 사용하는 같은 기능을 인터페이스에 정의하는 방법이 있습니다.

Animal 인터페이스를 구현한 각 클래스들은 울음소리 crying() 함수를 재`정의합니다.

울음소리를 호출하는 클라이언트는 다음과 같이 인터페이스에서 정의한 crying() 함수만 호출하면 됩니다.

public class Client {
    public static void main(String args[]){
        Animal cat = new Cat();
        Animal dog = new Dog();
        
        cat.crying();
        dog.crying();
    }
}

이렇게 캡슐화를 하면, 동물이 추가되었을 때 crying() 함수를 호출하는 부분은 건드릴 필요가 없으면서 쉽게 확장할 수 있게됩니다.

자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙입니다.

즉, 자식 클래스는 언제나 부모 클래스의 역할을 대체할 수 있어야 한다는 것을 말하며, 부모 클래스와 자식 클래스의 행위가 일관됨을 의미합니다.

자식 클래스가 부모 클래스를 대체하기 위해서는 부모의 기능에 대해 오버라이드 되지 않도록 하면 됩니다.

즉, 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 LSP를 만족하게 됩니다.

처음 OOP를 공부할 때 오버라이드가 OOP의 특징이라 배웠고 이를 잘 활용해야 할 것만 같았는데,

LSP에 따르면 객체지향적으로 설계를 하기 위해서는 오버라이드는 가급적 피하는 것이 좋다고 합니다.

자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 설계 원칙입니다.

즉, 하나의 거대한 인터페이스 보다는 여러 개의 구체적인 인터페이스가 낫다는 것을 의미합니다.

SRP는 객체의 단일 책임을 뜻한다면, ISP는 인터페이스의 단일 책임을 의미한다고 보면 됩니다.

예를 들어, 핸드폰( Phone )에는 전화( call ), 문자( sms ), 알람( alarm ), 계산기( calculator ) 등의 기능이 있습니다.

옛날 3G폰과 현재 스마트폰은 Phone의 기능들을 사용하므로, call, sms, alarm, calculator 기능이 정의된 Phone 인터페이스를 정의하려고 합니다.

그러나 ISP를 만족하려면 Phone 인터페이스에 call(), sms(), alarm(), calculator() 함수를 모두 정의하는 것보다,

Call, Sms, Alarm, Calculator 인터페이스를 각각 정의하여, 3G폰과 스마트폰 클래스에서 4개의 인터페이스를 구현하도록 설계되어야 합니다.

이렇게 설계를 하면, 각 인터페이스의 메서드들이 서로 영향을 미치지 않게 됩니다.

즉, 자신이 사용하지 않는 메서드에 대해서 영향력이 줄어들게 됩니다.

객체들이 서로 정보를 주고 받을 때 의존 관계가 형성되는데, 이 때 객체들은 나름대로의 원칙을 갖고 정보를 주고 받아야 한다는 설계 원칙입니다.

여기서 나름대로의 원칙이란, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 것을 의미합니다.

일반적으로 인터페이스를 활용하면 이 원칙을 준수할 수 있게 됩니다. (캡슐화)

Client 객체는 Cat, Dog, Bird의 crying() 메서드에 직접 접근하지 않고, Animal 인터페이스의 crying() 메서드를 호출함으로써 DIP를 만족할 수 있습니다.

TV라는 객체를 생각해봅시다. 사용자는 전원을 키고, 채널과 음량을 조절 할 줄 안다면 TV를 문제 없이 사용할 수 있습니다. TV의 내부적인 모습이나 원리는 알 필요가 없습니다. 하지만 사용자가 TV 객체에 대한 충분한 이해 없이 중요한 부품들을 건들이게 된다면, TV는 개발자가 의도한 대로 혹은 사용자가 예상한대로 작동하지 않을 확률이 매우 높습니다. 이러한 이유로 사용자가 객체에 접근할 수 있는 영역을 제한하는 것을 객체의 캡슐화(encapsulation)라고 합니다.

사용자가 불필요한 부분을 접근하지 못하게 하여, 객체의 오용을 방지 할 수 있습니다. (항상 개발자와 사용자가 다를 수 있음을 기억해야 합니다.) 객체의 내부가 바뀌어도 그 객체의 사용방법이 바뀌지 않습니다. (사용자는 객체 내부가 바뀌어도 같은 결과를 기대 할 수 있습니다.) 객체 내부에서 사용되는 데이터가 바뀌어도 다른 객체에게 영향을 주지 않습니다. (각 객체들의 독립성이 유지됩니다.) 객체간의 결합도가 낮아지게 됩니다. (객체간의 결합도를 낮추는 일은 객체 설계의 기본 원칙입니다.) 큰 시스템 일지라도 컴포넌트 별로 작게 분리하여 개발이 가능하게 됩니다. 이로 인하여 시스템 개발 속도를 높이고 성능을 최적화 하기가 쉽습니다.

클래스를 만드는 개발자는 클래스 멤버(필드와, 메소드)에게 접근제어자를 사용하여서 객체를 캡슐화 할 수 있습니다. Java에서 접근제어자는 4가지가 존재합니다.

private : 같은 클래스 내부에서만 접근 가능 default : (같은 클래스) + 같은 패키지 클래스에서만 접근 가능 protected : (같은 클래스) + (같은 패키지) + 자신을 상속받은 자손 클래스에서만 접근 가능 public : 자유롭게 접근 가능

public class AccessModifier {
    private int a = 10;
    int b = 20; //default는 키워드를 적지 않습니다.
    protected int c = 30;
    public int d = 40;
}

class AmTester {
    public static void main(String[] args) {
        AccessModifier am = new AccessModifier();
        //int a = am.a; //다른 클래스 에서는 접근 불가!
        int b = am.b;
        int c = am.c;
        int d = am.d; 
    }
}