Java

1. JVM, JDK, JRE란 무엇인가?

JDK

Java Development Kit. Java 프로그램을 개발하고 실행시키는 환경을 제공하는 키트입니다.

Java로 프로그램을 개발하는 개발자가 사용합니다. JDK 안에는 두 가지가 존재하는데,

1. Development Tools - java 프로그램 개발환경을 제공
2. JRE - Java 프로그램 실행

JDK 안에 JRE가 존재하고, JRE 안에 JVM이 존재합니다.

JRE

Java Runtime Environment. 내 기기에 Java 프로그램을 실행시키는 인스톨 패키지입니다. 일반인들이 자바 프로그램을 실행시킬 때 필요합니다.

JVM

Java Virtual machine. JDK, JRE 어떤 걸 사용해 자바 프로그램을 실행하던지 JVM은 자바프로그램 등을 컴파일하여 만들어진 바이트 코드를 실행해주는 가상머신입니다. JVM 덕분에 Java는 플랫폼(OS)에 영향을 받지 않는 언어일 수 있습니다.

Java는 C와 달리 중간과정이 하나 더 존재하는데, 클래스파일(바이트코드)를 만들어내는 과정이 그것입니다. 때문에 C보다 해석 속도가 느리나, 이를 보완하기 위해 JIT(Just-In-Time)가 사용됩니다. JIT는 자주 쓰이는 자바 코드를 캐싱한 뒤 이를 가져다 쓰기 때문에 인터프리터 방식의 언어인 Java의 실행속도를 개선할 수 있습니다.

2. 자바의 메모리 영역에 대해 설명하시오

- Class loader : 런타임에 클래스를 처음으로 참조할 때 해당 클래스를 Runtime Data Areas로 로드하고 링크한다.

- Execution Engine : Load된 Class를 실행하는 엔진이다.

- Garbage Collector : 사용 되지않는 객체를 해제하여 자동으로 메모리를 관리한다.

- Runtime Data Areas : JVM이 운영체제 위에서 실행 되면서 할당받는 메모리 영역이다.

1. Method : 메서드 영역은 모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성된다. JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드 정보, Static 변수, 메서드의 바이트코드 등을 보관한다.
2. Heap : 인스턴스 또는 객체를 저장하는 공간으로 가비지 컬렉션 대상이다. JVM 성능 등의 이슈에서 가장 많이 언급된다.
3. Stact :
   • JVM 스택은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 생성된다. 스택 프레임(Stack Frame)이라는 구조체를 저장하는 스택으로, JVM은 오직 JVM 스택에 스택 프레임을 추가하고(push) 제거하는(pop) 동작만 수행한다. 예외 발생 시 printStackTrace() 등의 메서드로 보여주는 Stack Trace의 각 라인은 하나의 스택 프레임을 표현한다.
   • Last In First Out (LIFO)
   • 메서드 호출 시마다 각각의 스택프레임이 생성된다.
   • 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장한다.
4. PC Register : 레지스터는 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 생성된다. PC 레지스터는 현재 수행 중인 JVM 명령의 주소를 갖는다.
5. Native : 자바 외의 언어로 작성된 네이티브 코드를 위한 스택이다. 즉, JNI(Java Native Interface)를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 스택으로, 언어에 맞게 C 스택이나 C++ 스택이 생성된다.

3. 가비지 컬렉터 작동 원리를 설명하시오

Spring

1. 스프링부트 와 스프링의 차이를 설명하시오

2. 스프링의 특징에 대해서 사용 사례를 빗대어 설명하시오

3. 스프링의 서비스 추상화란 무엇인지 설명하시오

아키텍처

1. 객체지향과 절차지향의 차이에 대해 설명하시오

절차지향은 어떤 목적의 코드 수행에 앞서 기능을 절차(프로시저) 중심으로 수행하고 객체지향은 각각의 기능을 객체에 분담해서 처리한다.

객체지향과 절차지향에는 각각의 장단점이 있는데

가독성
객체지향적으로 코드를 짜면 기능들이 각 메서드에 분배되어있어 메서드를 하나하나 타고 들어가야 하지만
절차지향적으로 코드를 짜면 코드가 한 눈에 보이기 때문에 가독성이 객제지향보다 좋을 수 있다.

유지보수
그러나 유지보수(변경,확장) 측면에서
기능이 변경되었을 때 객체지향은 해당 기능을 하는 메서드 하나만 수정해 주면 되지만, 절차지향은 객체마다 기능을 위임하지 않았기 때문에 비슷한 역할을 하는 코드가 여러 곳에 중복으로 작성되어있을 수 있어 관련된 코드를 모두 수정해줘야 하고 하나의 기능에 비즈니스 로직이 다 들어있어 코드를 수정할 때 영향도가 객제치향보다 높은 편이다. 때문에 객체지향은 코드 재사용성이 좋으며 절차지향은 코드 가독성 측면에서 좋을 수 있다.

객체지향과 절차지향은 어떤 것이 더 좋고 나쁘다고 할 수 없고, 상황에 맞게 사용하게 되는데
만약 코드가 한 번 작성된 후로 변경되지 않는다면 절차지향적 프로그래밍이 더 적합할 수 있다.
그러나 대부분의 소프트웨어는 요구사항이 변경되고 기능이 확장되기 때문에 객체지향적으로 코드를 작성하는 데 메리트가 있다.

2. SOLID 원칙에 대해 아는대로 설명하시오

SOLID란 객체지향 프로그래밍 에서 더 가독성 높고 관리를 유연하도록 하는 5가지 개념의 약어입니다.

SRP (단일책임의 원칙: Single Responsibility Principle)

하나의 클래스는 하나의 책임만을 가져야 한다.
어떤 변화에 의해 클래스를 변경해야 한다면, 그 이유는 오직 하나뿐이어야 하며,
이 원리가 적용되면 책임 영역이 확실해지기 때문에 한 책임을 바꿀 때 다른 클래스도 바꿔야하는 연쇄작용에서 자유로울 수 있습니다.
SRP는 높은 응집도, 낮은 결합도 원칙을 준수하게 해줍니다.

응집도

• 소프트웨어 코드의 한 요소가 다른 것과 얼마나 강력하게 연결되어 있는지, 또한 얼마나 의존적인지 나타내는 정도
• 결합도가 낮다는 것은 그것이 다른 요소들과 관계를 그다지 맺지 않은 상태를 의미

결합도

• 프로그램의 한 요소가 해당 기능을 수행하기 위해 얼마만큼의 연관된 책임과 아이디어가 뭉쳐있는지를 나타내는 정도
• 응집도가 높다는 것은 일반적으로 프로그램의 한 요소가 특정 목적을 위해 밀접하게 연관된 기능들이 모여서 구현되어 있고, 지나치게 많은 일을 하지 않는 것

또한 책임을 적절히 분배함으로서 가독성 향상, 유지보수의 용이성도 누릴 수 있으며
객체지향 원리의 대전제 격인 OCP원리 뿐 아니라 다른 원리를 적용하는 기초가 됩니다.
ex) 산탄총 수술, 여러 원인에 의한 변경

OCP (개방폐쇄 원칙: Open Close Principle)
소프트웨어의 구성요소가 확장에는 열려있고, 변경에는 닫혀있어야 한다.
요구사항의 변경이나 추가사항이 발생하더라도 기존 구성요소는 수정이 일어나지 않고, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻입니다.
OCP는 재사용 가능한 코드를 만드는 기반이며, OCP를 가능케 하는 중요 메커니즘은 추상화와 다형성입니다.

LSP (리스코브 치환 원칙: The Liskov Substitution Principle)

서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다

• 하위클래스 is kind of 상위클래스
• 구현클래스 is able to 인터페이스

상속은 조직도나 계층도가 아닌 분류도가 되어야 한다.

• class 딸 extends 아버지 ⇒ X, 딸이 아버지의 한 종류?
• class 펭귄 extends 조류 ⇒ O. 상속 예약어부터 extend, 즉 계층이 아닌 확장의 개념
  class 펭귄 implements 날수없는 조류. (조류는 분류이므로 상속은 아닌듯)

ISP (인터페이스 분리의 원칙: Interface Segregation Principle)

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

• 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용
• 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다.

→ (비교) SRP가 클래스의 단일책임 을 강조한다면 ISP는 인터페이스의 단일 책임 을 강조합니다.
변화에의 적응성이라는 같은 목표를 가지고, SRP는 클래스 분리를 통해, ISP는 인터페이스 분리를 통해 목표를 이룹니다.

DIP (의존성역전의 원칙: Dependency Inversion Principle)

자신보다 변하기 쉬운 것에 의존하지 말라 는 원리입니다.

• [DIP가 적용되지 않은 예] 자동차 → 스노우타이어
• [DIP가 적용된 예] (Interface) 타이어 ←(상속)- 스노우타이어, 일반타이어, 광폭타이어

3. 캡슐화에 대해 설명하시오

• 객체의 필드와 메서드를 하나로 묶고
• 실제 구현 내용 일부를 외부에 감추어 은닉한다

캡슐화는 클래스를 사용함에 있어 그 클래스가 제공하는 기능만을 알고 사용할 뿐 내부 작동을 알 필요가 없게 합니다. 이러한 특성은 사용자가 기능을 사용함에 있어 건드릴 필요 없는 부분의 접근을 막아(private) 객체의 오용을 방지 해줍니다. 메소드의 내부가 변경되어도 기능을 사용하는 곳의 영향을 최소화할 수 있습니다.

캡슐화의 두 가지 규칙

1. Tell, Don't Ask

   • 데이터를 물어보지 않고, 기능을 실행해 달라고 말하는 규칙

2. 데미테르의 법칙

   • (한 객체가 다른 )객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 것이다.
   • 메서드에서 생성한 객체의 메서드만 호출
   • 파라미터로 받은 객체의 메서드만 호출
   • 필드로 참조하는 객체의 메서드만 호출

데미테르의 법칙을 위반한 예

customer.getWallet().getMoney();

• 두 뎁스를 들어가게되면 내부 변경이 쉽지 않음. 1뎁스만 들어가야 함.
• get메서드의 연속된 호출이 일어난다면 데미테르의 법칙을 위반했는지 의심해 봐야 합니다.

옳은 예

customer.getMoney();

• 메서드 내부적으로 고객의 돈을 차감.

추상화와 다른점?

추상화는 원하는 기능구현에 필요없는것들은 생략하고 필요한 부분만을 나타내는 것이고 캡슐화는 같은 기능의 데이터를 한 곳으로 모으는 것

그 중 클래스의 속성들을 밖에서 함부로 건드릴 수 없도록 private 예약어를 붙여 클래스 밖에서 함부로 건드릴 수 없도록 하는데 이는 데이터 은닉(data hiding)과 유사한 지점이 있습니다.

데이터 은닉 vs 캡슐화

데이터 은닉(data hiding)은 보안적 클래스의 멤버를 인가되지 않은 접근으로부터 보호하는 개념으로 보안적 측면에 더 중점을 둔다면, 캡슐화는 복잡한 로직 내부를 숨기는 것에 더 중점을 두게 됩니다.

 

참조

SOLID http://www.nextree.co.kr/p6960/

https://techdifferences.com/difference-between-oop-and-pop.html

http://www.nextree.co.kr/p6960/

스프링 입문을 위한 자바 객체지향의 원리와 이해

https://jjhwqqq.tistory.com/32

디미터의 법칙
https://johngrib.github.io/wiki/law-of-demeter/