WIL_220523_객체지향프로그래밍, JVM, Gradle, Maven 그리고 이모저모

이번주도 자정이 넘은 WIL 작성 시간.

얼른 쓰고 자야되는데 항상 쓰다보면 또 시간이 금방 간다.ㅋㅋ

 

목요일에 알고리즘 주차를 마무리하는 시험을 보았고 저녁 9시 까지

JAVA 클래스, 인터페이스, 상속, 생성자 개념을 활용한 과제를 제출하며 알고리즘 주간이 마무리되었다.

 

금요일 오전 9시부터는 Spring 주특기 기본 주차가 시작되었다.

Spring 관련해서는 기존에 회사에서 쓰던 웹사이트가 Spring을 기반으로 구축이 되어있어서

보면서 아~ 대충 이렇게 돌아가는구나 정도는 알고 있었다.

하지만 직접 빌드 했던 웹서비스는 아니었기 때문에..

그리고 그 사이트를 유지 관리 하던 개발자가 이직을 하며 퇴사를 하는 바람에

어쩔 수 없이 도맡아서 부랴부랴 코드를 분석했기 때문에 상당히 얕게 알고 있었다.

(근데 그땐 뭘 안다고 분석을...ㅋ 호기롭게 하긴 했지만 지금 생각해보면 정말 아무것도 몰랐을 땐데 말이다..)

 

 

#Spring

아무튼 이번 Spring 주차가 시작되면서 Spring 강의를 듣는데,

쓰는 IDE(통합 개발환경)도 다르고(예전에는 이클립스, 지금은 인텔리제이)

스프링 프레임워크 내부 폴더 구조도 달랐다. 

뭔가 훨씬 더 간결해진 느낌? 특히 DB와 소통하는 Model 쪽을 구성하는 방식이 많이 달랐다.

특히 DAO, DTO 이런 파일들의 구성방식이 달랐고

회사 웹사이트는 sql Query를 별도로 Resources 폴더에 넣어서 DTO, DAO가 DB와 잘 연결될 수 있도록

했던 것 같은데..?(약간 가물가물.. 다시 한번 프로젝트 폴더를 봐야겠다.)

지금 프로젝트는 Repository Interface와 Service Class, DTO를 중심으로

훨씬 간편한 방식으로 DB와 소통하며 CRUD 할 수 있게 바뀐 것 같다.

 

그리고 기존 프로젝트는 Maven 빌드관리도구를 사용했던 것으로 보인다.

헌데 지금은 Gradle 빌드관리도구를 사용한다.(이 차이도 좀 큰 것 같다)

구글링을 좀 해보니 Maven에서 Gradle로 Java 개발자들이 많이 넘어오고 있는 추세라고 한다.

빌드업 속도가 훨씬 빠르고 Groovy라는 스크립트 언어로 빌드 스크립트가 구성되어있어서

기존의 XML 형식과는 가독성면에서도 훨씬 좋다고 한다.

 

<참고한 블로그>

https://dev-coco.tistory.com/65

메이븐(Maven)과 그래들(Gradle)의 개념 및 비교

 

 

아무튼 현재 트렌드에 맞는 빌드관리도구와 개발 방식으로 스프링 프로젝트를 진행하는 것은

매우 중요하다는 생각이 든다.

 

#객체지향 프로그래밍

JAVA라는 언어가 객체지향 프로그래밍 언어이고, 앞으로 진행될 미니프로젝트, 클론코딩, 실전 프로젝트들도

JAVA와 Spring을 이용하여 백엔드 개발을 해야되기 때문에 객체 지향 프로그래밍에 대한 깊은 이해는 필수적이다.

 

객체지향을 말할 때는 항상 절차지향과 대비가 되는데, 

소규모 프로젝트에서는 절차지향이 더 효율적일 수 있고, 여러 사람이 협업해야하는 중~대규모 프로젝트에서는

객체지향이 더 효율적이고 추후 유지보수에 용이하다는 장점이 있다.

 

객체지향에서 가장 중요한 것을 내가 이해한대로 좀 풀어 써보자면,

이 세상의 모든 것을 Class와 그 객체라는 개념으로 나누어 본다는 것이 가장 중요한 것 같다.

자동차(Car)라는 클래스, 버스(Bus)라는 클래스, 또 그것을 한데 어우르는 탈 것(Vehicle)이라는 클래스 처럼 말이다.

각각의 클래스는 공통적일 수도 그렇지 않을수도 있는 여러가지 속성들(바퀴 갯수, 엔진 종류, 쓰는 재료 등)이 있을 것이다. 또한 마찬가지로 (공통적일 수도 그렇지 않을수도 있는) 여러가지 기능들(엑셀밟기, 브레이크 밟기, 경적울리기, 와이퍼로 유리닦기 등)이 있을 것이다.

 

여기서 속성들은 Class의 생성자(Constructor)로 생성하는 객체(인스턴스)의 멤버변수들이라고 할 수 있다.

그리고 기능들은 Class의 여러 함수들(Method)라고 할 수 있겠다.

 

각 클래스들이 공통적으로 공유하는 속성들, 그리고 기능들은 더 상위의 클래스 즉, 부모클래스(탈 것)로 묶어주고

자식클래스(자동차, 버스)는 해당 속성과 기능을 상속 받아 사용할 수 있도록 하는 것이 

코드의 재사용 및 유지 보수 관점에서 상당히 유리한 면이 있다는 것이 느껴진다.

 

간단하게 표를 넣거나 객체지향 프로그래밍의 특징들(추상화, 캡슐화, 상속, 다형성)에 대해 설명하는 것도

생각해보긴 했지만, 실질적으로 내가 머릿속으로 이해하는 개념들에 대해 

조금 더 나의 언어로 풀어서 작성해 보는 것이 좋다는 생각이 들었다.

 

<참고한 블로그>

https://st-lab.tistory.com/151

객체지향(OOP)과 절차적 프로그래밍(PP)

https://techblog.woowahan.com/2502/

생각하라, 객체지향처럼 | 우아한형제들 기술블로그

 

#JVM

Java Virtual Machine의 약자로서 컴파일 된 자바 class 파일을

OS에 맞게 해석해주는 Java 프로그래밍 언어만의 특징적인 개념이라고 볼 수 있다.

아래의 이미지를 참고해보면 전체적인 구조에 대한 이해는 대충 된다...ㅎㅎ

JVM 구조도

하나하나 요소별로 너무 깊게 파고들어가면 아직은 이해안되는 개념들이 많기 때문에 ㅋㅋ

그건 차차 나중에 이해하는 것으로 하고...

간략하게만 어떠한 구조로 이루어져 있는지를 보자.

 

- Class Loader

RunTime 시점에 클래스를 로딩하게 해주며 클래스의 인스턴스를 생성하면 클래스 로더를 통해 메모리에 로드

 

- Runtime Data Areas

JVM이 프로그램을 수행하기 위해 OS로 부터 별도로 할당 받은 메모리 공간을 말하며, Runtime Data Areas는 크게 5가지 영역으로 나뉨

- Execution Engine

Load된 Class의 ByteCode를 실행하는 Runtime Module이 바로 Execution Engine. Class Loader를 통해 JVM 내의 Runtime Data Areas 에 배치된 바이트 코드는 Execution Engine에 의해 실행되며, 실행 엔진은 자바 바이트 코드를 명령어 단위로 읽어서 실행. Garbage Collector를 통해 더이상 쓰이지 않는 메모리를 자동으로 회수.

 

 

수년 전 쯤 역삼의 모 학원에서 Java를 처음 배울 때 JVM, Garbage Collector에 대해서 들었던 기억이 난다.

뭐 사실 그때는 퇴근하고 저녁반이라 피곤하기도 했고, 추상클래스? 인터페이스? 생성자? 객체? 응?????? WT..F

그랬을 시절이니, 솔직히 JVM, 가비지 콜렉터에 대해서는 생각 할 겨를이 없었지 싶다.

그래도 이제는 Java를 그때보다는 더 잘 이해하고 있고

다시 깊이 있게 공부하는 만큼 이러한 내부적인 구조나 개념에 대해서도

전반적인 이해를 하고 있어야 됨을 느낀다.

수 년 전의 나와 지금의 나를 비교해보면... 그래도 꾸준히 프로그래밍을 놓지 않고

여러 언어를 공부 했고, 여러 사이트의 코드를 보며 다뤄봤고, 직접 개발도 해보았기에

어느정도는 개발에 대한 개념을 탑재하게 되지 않았나 싶다.(스스로에게 잘했다고 칭찬ㅋ)

 

오늘의 WIL은 여기서 마친다.

뿅. 내일도 달려보자 !!