📌 6주차 이후 질문 및 정리
-
객체 지향 설계 왜 해야 될까?
: 사람이 살아가는 세상에 물체를모델링해서 객체라는 구조체계로 만들고 그 객체들이 메서드(행위)를 가지고 서로 메시지(상태)를 전달해협력하는 구조로 프로그래밍하는 형식.
즉, Object(객체)를 중심으로 그 Object끼리협력이라는 context에서 결합도를 낮추고 응집도를 높이면서 요구사항에 대응하게 프로그래밍하는 설계 방식.
비즈니스적으로 요구사항이 계속 변할 수 밖에 없는 상황에선 거기에 유연하게 대응하기에 가장 최적화된 프로그래밍 방식이 아닌가 싶다.
그리고 객체지향설계를 위한 가이드로SOLID 원칙이 있는 것임. => 추상화(발췌화)로 정리가 됨.
아키텍쳐관점에서도 객체지향설계로 하는 게 좋은 아키텍쳐다. 클린 아티텍쳐의 로버트.c.마틴의 얘기를 빌리자면
'좋은 아키텍쳐는 구체적인 방법론들은 뒤로 최대한 미루게 해주는 것이다.'-> 구현체에 의존하는 게 아닌 인터페이스에 의존해 모듈화하여 유연하게 대응하고 확장할수있게 하는 것(추상화) -
volatile 키워드 다시한번
: 변수에 붙이는 키워드, 이 키워드를 변수에 붙이면, 스레드가 cpu내 캐시에 있는 변수를 재사용안하고메인메모리에 참조하게 되고 최신화된 데이터만 접근할 수 있다. 멀티스레드 환경에서 동기화를 보장해주는 기법 중 하나이다.
관련 블로그 : https://velog.io/@mooh2jj/volatile-transient-키워드의-의미 -
캡슐화의 의미. 데이타의 expose를 최소화하는 것
왜? side effect 을 줄이는 것. 변경불가피한 건 public 메서드(getter/setter)한 걸로 변경하는 것으로 이해함. -
final 키워드를 붙이는 이유
: 컴파일 시점에서 오류발생을 캐치할 수 있고 멀티스레드환경에서 변하지 않는 값으로 불변화(immuteable)시켜 데이타에 대한 신뢰할 수 있게 해주는 기법이다.
관련 블로그 : https://velog.io/@mooh2jj/final-키워드-정리 -
OOP SOLID 원칙 개념 정리
: 로버트 C.마틴이 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙
1)SRP: 응집도 얘기. 한 클래스에 너무 많은 기능(메서드)들을 넣지 말라.
2)OCP: 추상화된 클래스, 인터페이스를 사용해 추가기능 확장에는 열려 있고 상위 클래스가 하위 클래스들 변경에 닫히게 하는것. ex 고객 - 자동차 - impl(마티즈, 그랜저)
마티즈, 그랜져, 여기에 아반떼로 확장이 열림, 그러나 고객은 자동차만 바라보기에 impl들이 확장해도 변경되지 않음.
이게 컴포지션이자 DI하고 연관됨.
3)리스코비치: 하위타입(sub class)이 대체되더라도 문제가 없어야 한다. override 상속을 통한 재사용성 이야기와 맥을 맺는 이야기임.
4)ISP: SRP랑 비슷. interface 만드는 거 좋고 그렇다고 ISP에 너무 많은 기능(메서드)들을 넣지 말고 쪼개라.
5)DIP: OCP랑 비슷. 구체 클래스에 의존하지 말고 추상화된 클래스, 인터페이스에 의존하라는 말. 나중DI(Dependecy Injection)랑도 연관된 이야기. DIP에 DI는Dependecy Inversion(의존관계 역전)임.
관련 블로그 : https://velog.io/@mooh2jj/객체지향-설계-5원칙-SOLID를-파훼쳐보자
-
스프링의 DI란?
:DI(Dependecy Injection)로 의존관계 주입이라고 번역하는 것이 좋다.
스프링프레임워크가 생성과 사용을 분리하여 객체를 관리해줘 구현체에 의존하지 않게 추상화된 클래스, 인터페이스에 의존관계를 쉽게 만들어 주는 기법. -
스프링 bean이란? 등록하는 방법 중 annotation으로 하는 방법. @Configuration, @Component @Bean들
관련 블로그 : https://velog.io/@mooh2jj/Spring-Ioc-DI -
DI 방식 중 생성자 주입방식의 장점은?
: spring4.0부터 스프링쪽에서 권하는 DI 방식. final을 사용할 때 장점과 똑같다. 테스트 편한 것은 컴파일 오류로 확인할 수 있어서 그 얘기랑 맞닿아 있는 말이다.
관련블로그 : https://velog.io/@mooh2jj/생성자-주입의-장점-RequiredArgsConstructor-쓰는-이유
📌 전주 개인 공부한 내용들
-
<오브젝트> 일단 1회독 code부분을 많이 빼먹고 글로만 읽었기 때문에 회독의 의미가 사실 없는 것 같다.
-
<스프링 입문을 위한 객체지향의 원리>
자바에서 객제지향 그리고 spring을 이해하는 흐름이 너무 깔끔한 책이다. 정리가 잘 되어있어서 그럴 것이다. 한국인이 보기에 스프링 입문하는 데 이만한 책이 없는 것 같다. 👍
<토비의 스프링>으로 입문하는 것보다 이 책으로 입문하는 게 정답인 것 같다. -
김영한 JPA 활용1 ERD 활용하고 프로그래밍을 만들어 볼때 양방향 매핑 이해.
가끔씩 <자바 ORM 표준 JPA 프로그래밍> 책으로 복습. 사실 강의 pdf가 퀄리티가 높은 것 같음 -
인프런의 코딩테스트 Array 문제 일단 풀어 보기는 하는데 집중이 되지 않고 이해가 잘 되지 않는다. 멘토링 받을 때 Stack, Queue 풀어보라고 할때 Array가 참 어렵다고 느껴졌다..
📌 멘토링
주로 저번 주 멘토링 때 얘기한 OOP, SOLID 원칙을 내가 이해한 대로 설명해보고 피드백 받는 것으로 시간이 다 지나갔다. 코드적으로 설명하고 추상화라는 단어를 써야되는게 말이 잘 안나왔다. 오히려 추상화는 발췌화라는 단어로 번역되었으면 더 이해가 잘 될텐데 아쉬움도 있었던 시간이었다.
6주차 이후 질문 및 정리 얘기로 끝이 났다.
📌 느낀점
멘토님과는 <스프링 입문> 책으로 기술면접식으로 질문과 답변이 오갔다. 역시나 힘들었다.
추천해주신 책을 읽어보고 OOP적으로 내가 이해했다고 생각한 부분이 멘토님과 sync가 잘 맞지 않았던 것 같다. 아니 정확히 말하면 내가 잘 이해 못한 상태에서 얘기한 게 많았다.
나는 내가 잘 이해했다고 생각했는데 output하는 과정에서 정리가 잘 되지 않았다.
내가 제대로 이해를 했다고 생각할려면 내가 미리 글로도 적어보고 경험으로 승화하는 부분이 있어야 될 것 같은데 그게 참 부족한 게 아닌가 싶다.
특히 이 부분은 방법론적인 얘기인지라 fact적인 얘기로 결론 내릴 수 없고 내가 그렇게 생각할 수밖에 없는 근거를 가지고 할 수 없어 더 그런 것 같다.
📌 해야 할 것
- 김영한
proxy개념 이해하기 - 스프링
AOP개념 이해하기 - 코딩 테스트 - 자바 인프런 강의
- 멘토님께서 질문하셨던 내용들 블로그 정리
- 스터디 모임 - 젠킨스, 도커, AWS EC2 인스턴스에 배포하기 발표 준비
- 이젠 저번주부터 상체 운동
