저의 회고 방식은 5F 입니다.
사실, 무슨 일이 있었나요 ?
자바 강의를 전부 공부했습니다.
스프링 코어 기본에 대하여 학습하기 시작했습니다.
소켓에 대하여 깊은 학습을 진행하였습니다.
느낀점, 어떤 느낌이 들었나요 ?
자바를 이렇게까지 딥하게 공부해 본 적은 처음이었는데 정말 뜻깊은 시간이었습니다. 딥하게 공부하다 보니 제 머릿속에 있었던 퍼즐들이 전부 맞혀지는 기분이었는데 특히 좋았던 부분들입니다.
1. JDK, JRE, JVM
2. 원시 자료형 VS 참조 자료형
3. 다형성
소켓의 경우 백엔드를 희망하면서 소켓은 어떤 경우에 사용할까를 고민해 봤습니다.
이러한 특징으로써 제가 쉽게 생각할 수 있는 기능은 채팅 기능이였습니다.
채팅 기능을 생각해 봤을 때, 요청 → 응답하는 방식으로 구현한다면, 처리 시간이 길어지고 효율성이 떨어질 수 있습니다.
따라서 소켓 통신을 통해 항상 연결을 유지함으로써 실시간으로 데이터를 전송이 가능하게 하므로, 실시간성이 중요한 상황에 적합합니다.
그러므로, 채팅 기능을 구현하는 한 가지 방법은 소켓 통신을 활용하는 것이라고 말할 수 있는데 소켓을 이용해 어떻게 구현해 볼지 고민하게 되었습니다.
배운 점, 어떤 인사이트를 얻었나요 ?
1. JDK, JRE, JVM
포함 관계로는 JDK가 JRE를 가지고 있고, JRE는 JVM을 가지고 있습니다.
JVM의 장점 중 하나는 jvm이라는 자바 가상환경 어디서든 자바 코드를 돌릴 수 있다는 점입니다.
그러면서 jvm은 추가적으로 메모리를 효율적으로 관리 및 최적화를 해주는데, 이 작업을 가비지 컬렉션이라고 하여 jvm이 메모리를 관리하는 프로세스를 지칭하는 말입니다.
JRE는 자바의 클래스 라이브러리, JVM, 자바 클래스 로더를 포함합니다.
클래스로더와 클래스 라이브러리를 통해 작성된 자바 코드를 라이브러리와 결합합니다.
이후 JVM으로 넘겨서 실행을 시켜줍니다.
JDK는 JRE에 없는 자바 컴파일러를 포함하고 있습니다.
JDK, JRE, JVM에 대하여 이름만 알고 있었고, 각각 깊게 학습하지 못했는데 이번 기회에 배울 수 있었습니다.
2. 원시 자료형 VS 참조 자료형
원시 자료형(primitive type) 과 참조 자료형 (reference type)을 비교해 보면 원시 자료형은 값 자체를 복사해 줍니다.
참조 자료형의 경우 배열로 생각하면, 방향을 가리키는 것이기 때문에 같은 게 아니라, 방향이 같아지는 것이서 어느 하나를 바꾸면 둘 다 바뀌게 됩니다.
따라서, 참조 자료형을 비교해 줄 때는 hashCode(), equals()를 오버라이딩 해서 정의해 줘야 참조가 아닌 값으로 비교해 줄 수 있습니다.
자주 쓰이는 String에서도 equals를 써주는데, String 클래스에는 이미 재정의 되어 있으므로, equals() 메서드를 통해 비교가 가능한 것이었습니다.
이러한 깊은 이해를 못 하고, String에서는 비교 연산을 진행할 때 equals()라고 외워서 사용했는데, 내부 동작 원리를 이해하고 나니 자바에 대하여 깊게 학습할 수 있었던 것 같습니다.
3. 다형성
지금까지 인터페이스를 왜 사용해야 할까? 라는 의문점이 사라졌습니다.
스프링부트 기본편을 수강하며, 좋은 객체 지향의 특징으로는 역할과 구현을 분리하는 방법입니다.
여기서 역할은 인터페이스이고, 구현은 클래스 입니다.
열할과 구현으로 구분하면 단순해지고, 유연해지며 변경도 편리해 집니다.
<장점>
1. 클라이언트는 대상의 역할만 알면 됩니다.
2. 클라이언트는 구현 대상의 내부 구조를 몰라도 됩니다.
3. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않습니다.
4. 클라이언트는 구현 대상 다체를 변경해도 영향을 받지 않습니다.
다형성을 활용하여 객체를 설계하는 과정에서는 먼저 인터페이스를 정의하게 됩니다. 인터페이스는 객체가 가져야 할 기능을 추상적으로 명시하는 역할을 합니다. 이후, 이 인터페이스를 구현하는 하나 이상의 구현 객체를 만들어냄으로써, 각각의 객체가 인터페이스에 정의된 기능들을 실제로 어떻게 수행할지 결정하게 됩니다. 이러한 접근 방법을 배움으로써 저는 개발 과정에서 유연성을 제공하며, 코드의 재사용성을 높이고 유지보수를 용이하게 만드는 방법을 배웠습니다.
향후 행동, 앞으로 무엇을 해야 할까요 ?
김영한 님 강의를 시작은 좋은 객체 지향 설계의 5가지 원칙을 시작으로 특히 OCP 개방 - 폐쇄 원칙과 DIP 의존관계 역전 원칙을 강조해 주셨습니다.
거기서도 특히 OCP 개방 - 폐쇄 원칙에 더 흥미가 생겼는데 평소 다형성의 개념을 알고 써보다 보니 더 깊게 파고 싶어서였습니다.
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 하고, 다형성을 활용하여 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 방식입니다.
여기서 더 궁금증이 생겼던 거는 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다는 점입니다.
다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경됨으로써 OCP를 지킬 수 없다는 점입니다.
그래서 뭔가 더 필요하다고 하셨는데 그 무언가를 공부해 보며 다음 주 회고 글에 작성하도록 하겠습니다.
'구름톤 트레이닝 풀스택 회고' 카테고리의 다른 글
⛅️[구름톤 트레이닝 풀스택 6회차] - 10주 차 회고⛅️ (0) | 2024.03.08 |
---|---|
⛅️[구름톤 트레이닝 풀스택 6회차] - 9주 차 회고⛅️ (0) | 2024.03.02 |
⛅️[구름톤 트레이닝 풀스택 6회차] - 7주 차 회고⛅️ (0) | 2024.02.16 |
⛅️[구름톤 트레이닝 풀스택 6회차] - 6주 차 회고⛅️ (0) | 2024.02.10 |
⛅️[구름톤 트레이닝 풀스택 6회차] - 5주 차 회고⛅️ (0) | 2024.02.04 |