공부하는개미

😀 책에서 기억하고 싶은 내용을 써보세요.

private void setBooleanArg(ArgumentMarshaler m) {
	try {
    	m.set("true"); // 이전 코드: booleanArgs.get(argChar).set("true");
    } catch (ArgsException e) {
    }
}

• 변경 전 booleanArgs.get(argChar).set("true");  코드
  • 위 코드는 클린코드 6장에 나왔던 기차 충돌 코드 사례와 비슷하게 생겼습니다.
  • 변경 후 코드가 훨씬 간결해졌습니다.
    
    
• 리팩터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다.
  • 단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다.
    => 리팩터링은 루빅 큐브 맞추기와 비슷하다.
    => 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다.
    => 각 단계를 거쳐야 다음 단계가 가능하다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 이 챕터를 읽고 저자는 한번에 완벽한 코드를 작성할 수 없다는 것을 보여주는 것 같았습니다.
   => 챕터 제목 그대로 점진적인 개선을 보여주고 있습니다.
   
   
2. 모든 코드를 다 리팩터링 하고 테스트를 돌려보는 방식이 아녔습니다.
   => 한 부분을 리팩터링 하고 테스트를 돌리는 과정이 많았습니다.
   
   
3. 이전 장에서 배웠던 내용을 코드에 적용해 하나씩 리팩터링 하는 게 인상 깊었습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 코드가 엄청 방대해서 전체를 다 이해하기는 힘들다고 느꼈습니다.
  => 눈으로만 읽고 생각해서 그런지 가독성이 안 좋았습니다.

👀 소감 3줄 요약

• 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다.
• 점진적인 개선과 리팩터링
• 저자도 계속해서 리팩터링 과정을 거치면서 깨끗한 코드를 만들어가는 과정이 인상 깊었습니다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다.
  • 어떤 프로그램은 그저 그런 '개선'에서 결코 회복하지 못한다.
    => '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.
• TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다.
  • TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다.
    => 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 테스트 코드의 중요성을 오늘 또 느꼈습니다.
   => 테스트코드는 처음 의도에서 벗어나지 않게 해줍니다.
   => 테스트코드는 안정적으로 프로그램을 개선 할 수 있게 도와줍니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 이 책을 읽으면서 TDD는 필수라는 느낌을 많이 받았습니다.  그렇다면 TDD의 단점이 궁금합니다.
  • SI프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에
    TDD방식을 잘 사용하지 않는다고 합니다.
  • 블로그의 글을 찾아보니, 테스트 코드를 작성해야 하는 번거로움 때문에 생산성 저하가 발생한다고 합니다.
    => 가장 큰 이유는 TDD를 배워야 한다는게 큰 것 같습니다.

👀 소감 3줄 요약

• 그저 그런 프로그램 개선은 결코 회복되지 않는다.
• 개선을 하면서 로직이 틀어진 적이 상당히 많았어서 공감이 되는 파트였습니다.
• TDD! 테스트! 테스트!!

😀 책에서 기억하고 싶은 내용을 써보세요.

• 프로그래밍은 과학보다 공예(craft)에 가깝다는 사실이다.
  • 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다.
    
    
• 대다수 신참 프로그래머는 무조건 돌아가는 프로그램을 목표로 잡는다.
  • 일단 프로그램이 '돌아가면' 다음 업무로 넘어간다.
  • '돌아가는' 프로그램은 그 상태가 어떻든 그대로 버려둔다.
  • 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 오늘 시작한 [14장. 점진적 개선]을 읽으면서 느낀 점
   => 우선 코드 위주로 되어 있으니 타이핑해보자.
   => 타이핑 한 곳에 주석을 달면서 코드에 대해 이해해보자.
   => 작성 후 북 스터디에서 다른 분들이 올린 글을 보고 어떻게 공부했는지 참고해야 할 것 같습니다.
   
   
2. 깃허브 레포지토리 숫자를 상당히 많지만 그 코드를 개선하는 경우가 적었습니다.
   => 이전에 작성한 코드를 리팩터링 하지 않기 때문에 코드가 내 것이 되지 않는 문제 발생.
   => 예전에는 왜 이렇게 작성했는지 생각하면서 개선하고 어떻게 개선했는지 글로 남겨야겠습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

👀 소감 3줄 요약

• 프로그래밍은 과학보다 공예(craft)에 가깝다.
• 한 번에 완성되는 작품은 없으니 꾸준히 개선을 해나가야 한다.
• 예전에 작성한 코드들을 리팩터링 하면서 개선해야겠다고 느꼈습니다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 동기화하는 부분을 작게 만들어라
  • 자바에서 synchronized 키워드를 사용하면 락을 설정한다.
  • 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다.
    => 락은 스레드를 지연시키고 부하를 가중시킨다.
• 코드가 올바르다고 증명하기는 현실적으로 불가능하다.
  • 테스트가 정확성을 보장하지는 않는다.
    => 그럼에도 충분한 테스트는 위험을 낮춘다.
  • 권장사항: 문제를 노출하는 테스트 케이스를 작성하라.
    프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라.
    테스트가 실패하면 원인을 추적하라.
    => 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대로 안 된다.
    • 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라.
    • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자.
    • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 스레드 코드를 구현하라.
    • 다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 수 있게 작성하라.
    • 프로세서 수보다 많은 스레드를 돌려보라.
    • 다른 플랫폼에서 돌려보라.
    • 코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해 보라.
• 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라.
• 스레드 코드를 테스트할 때는 전적으로 스레드만 테스트한다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 멀티 스레드를 구현하는 수많은 개발자의 고통이 느껴졌습니다.
   => 아직 구현을 해보지 못해서 모르지만 수 많은 시행착오가 있다고 책에 나와있습니다.
   => 면접에서 스레드 얘기가 나오면 왜이렇게 면접관들이 질문을 할려고 하는지 알 것 같습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 전반적으로 거의 다 이해가 되지 않았습니다.
  => 이전 글에도 적었지만 스레드에대한 개념과 코드를 구현해보지 못한 것 때문에 이해가 힘든 것 같습니다.
  다음에 조금이라도 구현을 해보고 다시 읽으면 좋을것 같은 파트입니다.

👀 소감 3줄 요약

• 다중 스레드 코드는 올바로 구현하기 어렵다.
• 다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라. 
• 다중 스레드 코드를 작성한다면 각별히 깨끗하게 코드를 짜야한다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 동시성은 결합(coupling)을 없애는 전략이다.
  • 즉, 무엇(what)과 언제(when)를 분리하는 전략이다.
  • 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다.
    
    
• 동시성과 관련된 타당한 생각 몇 가지
  
  • 동시성은 다소 부하를 유발한다. 성능 측면에서 부하가 걸리며, 코드도 더 짜야한다.
  • 동시성은 복잡하다. 간단한 문제라도 동시성은 복잡하다.
  • 일반적으로 동시성 버그는 재현하기 어렵다.
    그래서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다.
  • 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.
• 동기화하는 메서드 사이에 존재하는 의존성을 이해하라.
  • 동기화하는 메서드 사이에 의존성이 존재하면 동시성 코드에 찾아내기 어려운 버그가 생긴다.
  • 자바 언어는 개별 메서드를 보호하는 synchronized라는 개념을 지원한다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 아직은 지금 이 단계를 깊게 공부할 시기는 아닌 것 같습니다.
2. 스레드를 지금 공부하면 좋겠지만, 아직 13장 전의 내용을 이해해야 할 것 같습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 서블릿이란?
  • 자바를 사용하여 웹을 만들기 위해 필요한 기술입니다.
  • 클라이언트가 어떠한 요청을 하면 그에 대한 결과를 다시 전송해주어야 하는데,
    이러한 역할을 하는 자바 프로그램입니다.
  • 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해주는 기술입니다.
• 동기화란?
  • 프로세스 또는 스레드들이 수행되는 시점을 조절하여 서로가 알고 있는 정보가 일치하는 것을 의미합니다.

👀 소감 3줄 요약

• 동시성은 결합(coupling)을 없애는 전략이다.
• 스레드의 개념이 나오니까 엄청 어렵다는 것을 느꼈습니다.
• 읽기만 해서는 이해하기 어려운 파트인 것 같습니다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 켄트 벡이 제시한 단순한 설계 규칙 네 가지(중요도 순)
  • 모든 테스트를 실행한다.
  • 중복을 없앤다.
  • 프로그래머 의도를 표현한다.
  • 클래스와 메서드 수를 최소로 줄인다.
• 테스트를 철저히 거쳐 모든 테스트 케이스를 통과하는 시스템은 '테스트가 가능한 시스템'이다.
• TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다.
  
  
• 자신이 이해하는 코드를 짜기는 쉽다.
  => 하지만 나중에 유지보수할 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다.
  
  

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 켄트 벡이 제시한 설계는 결국 지금까지 읽은 클린코드 내용을 지키는 것
2. 테스트 코드의 중요성
   => 테스트가 불가능한 시스템은 검증도 불가능하다.
   => SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다.
   => 테스트 케이스를 만들기 쉬운 코드는 결국 객체 지향의 목표를 저절로 도달하게 된다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• TEMPLATE METHOD 패턴
  • 전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화 할 때 유용하다.
  • 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법. 변하지 않는 기능은 슈퍼클래스에 
    만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 한다. - 토비의 스프링 3.1
• 창발성이란?
  
  • 창발성이란 단순한 결합이 복잡한 결과를 나타내는 것을 의미.
  • 각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나온다.
  • 이처럼 작은 요소들의 상호작용의 반복이 전체 구조에 영향을 미친다.

👀 소감 3줄 요약

• 테스트 코드 그리고 테스트 코드
• 리팩터링을 통한 중복 제거로 객체 지향적 프로그래밍
• 내가 이해하는 코드로만 짜면 결국 나중에 나도 못 알아볼 수 있다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 순수 자바 AOP 프레임워크
  • 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는
    내부적으로 프록시를 사용한다.
    * '순수 자바' 란 AspectJ를 사용하지 않는다는 뜻이다.
  • 스프링은 비즈니스 논리를 POJO로 구현한다.
  • POJO는 순수하게 도메인에 초점이 맞춘다.
  • POJO는 엔터프라이즈 프레임워크에 (그리고 다른 도메인에도) 의존하지 않는다.
    따라서 테스트가 개념적으로 더 쉽고 간단하다.
  • 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉬우며 미래 스토리에 맞춰
    코드를 보수하고 개선하기 편하다.
• 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 초창기 EJB 아키텍처는 기술을 너무 많이 넣느라 관심사를 제대로 분리하지 못했던 유명한 API 중 하나다.
  • 좋은 API는 걸리적거리지 않아야 한다. 그래야 팀이 창의적인 노력을 사용자 스토리에 집중한다.
    그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못한다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
  • 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다.
  • 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다.
  • 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

시스템을 설계하든 개별 모듈을 설계하든,
실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 도메인 설계를 왜 POJO로 하는지 개념이 확실하게 잡히지 않았었습니다.
   => 이번 챕터를 읽으면서 그 이유에 대해서 알 수 있었습니다.
2. 설계가 잘못되면 테스트가 힘들다는 것은 알고 있었는데 정확한 이유를 몰랐었습니다.
   => 도메인 논리를 POJO로 작성하면서 관심사 분리할 수 있다는 이점이 있었습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 횡단 관심사란?
  • 핵심적인 기능이 아닌 중간중간 삽입되어야 할 기능들 관심들을 횡단관심사라고 한다.
    ex) 로깅, 보안, 트랜잭션 처리 등 비즈니스 핵심적인 기능이 아닌 다양한 횡단 관심이 발생할 수 있다.
  • 다른 관심사에 영향을 미치는 프로그램의 Aspect이다. 이 관심사들은 디자인과 구현 면에서 시스템의 나머지 부분으로부터 깨끗이 분해되지 못하는 경우가 있을 수 있으며 분산(코드 중복)되거나 얽히는(시스템 간의 상단한 의존성 존재) 일이 일어날 수 있다. - 위키백과 -
  • 여러 비즈니스 로직이 수행될 때 서로 중복되는 로직이 존재하는지에 대한 관심사.

• 영속성(persistence) 정보란?
  
  • 영속성은 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성을 의미한다.
  • 영속성은 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 구현한다.
  • 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다.
  • 영속성은 특정 데이터 구조를 이전 상태로 복원할 수 있게 해주어 프로그램의 종료와 재개를 자유롭게 해준다.

👀 소감 3줄 요약

• 도메인 논리를 POJO로 작성하고, 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 

😀 책에서 기억하고 싶은 내용을 써보세요.

• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
  
  
• 시스템 제작과 시스템 사용을 분리하라.
  
  • 우선 제작(construction)은 사용(use)과 아주 다르다는 사실을 명심한다.
  • 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다.
    => 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다.
• 의존성 주입(Dependency Injection, DI)
  
  • 사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다.
  • 의존성 주입은 제어 역전(IoC)기법을 의존성 관리에 적용한 메커니즘이다.
    => 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.
    => 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙(SRP)을 지키게 된다.
• AOP(Aspect-Oriented Programming, AOP)
  • 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다.
  • 특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 많이 봤던 단어들이지만 이것에 대한 개념을 이해하기는 어려웠습니다.
2. 자바 스프링관련 책에서 나오는 것들과 겹치는 게 많아서 꾸준히 읽어보면 좋을 것 같다고 느꼈습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 전체적으로 이해하는데 어려웠습니다.
  => 클린코드 책을 여러 번 읽어보면서 이해를 해야 할 것 같습니다.
  => 아직 앞 부분의 내용을 전부 이해하지 못해서 뒷부분이 어려운 것 같습니다.

👀 소감 3줄 요약

• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
• 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다.
• 사용과 제작을 분리하는 강력한 매커니즘 하나가 의존성 주입이다.

🤢 리팩터링 전 코드

• 문제 라인 -> 7번째
• 클린코드 140p. [null을 전달하지마라]를 바탕으로 리팩터링 했습니다.
• null을 전달하면 NullPointerException이 발생한다.
  => null 처리를 if문으로 하기는 했지만 Optional로 처리를 하면 더 클린 하게 할 수 있다.

😄 [1차 리팩토링 후] 진리 1. null을 전달하지마라

• 여전히 코드가 더럽기는 하지만 우선 null을 그냥 넘겨주는 것을 Optional이라는 함수로 처리했습니다.
  => 만약에 찾는 레스토랑이 null이면 Exception 강제 발생
  => 아니라면 찾은 레스토랑의 정보를 바탕으로 다른 Exception 처리
• 하지만 여기서 28번째 라인을 보면 레스토랑 내 음식 중복검사까지 하는 걸 볼 수 있습니다.
  => 하나의 함수에 2 가지 이상의 로직 처리를 하는 소요 발생
  => 리팩터링 2차 진행!

😄 [2차 리팩터링 후] 진리 2. 한 가지만 해라!

• 클린코드 44p. [한 가지만 해라!]를 바탕으로 리팩터링 했습니다.
• 레스토랑에 등록하려는 음식에 중복되는 음식이 있는지 확인하는 함수를 따로 분리했습니다.
• 하지만 여전히 하나의 함수에 20줄이 넘고 난잡한 코드인 것을 볼 수 있습니다.
  => 3차 리팩터링 진행!

😄 [3차 리팩터링 후] 진리 3. (함수)작게 만들어라

• 클린코드 42p. [작게 만들어라]를 바탕으로 리팩터링 했습니다.
• 하나의 함수를 20라인 내외로 줄였습니다.
• 그만큼 함수가 많이 생기긴 했지만 훨씬 보기 편해지고 깨끗한 코드가 되었습니다.

👀 소감 3줄 요약

• 처음에 코드를 작성할 때 깨끗하게 작성했으면 이런 소요가 없었을 것 같습니다.
• 예전에 작성한 코드를 리팩터링 하면서 방청소를 하는 기분을 느꼈습니다.(힘들지만 뿌듯)
• 깨끗한 코드에 대해 끊임없는 고민이 필요한 것 같습니다.

😀 책에서 기억하고 싶은 내용을 써보세요.

• 변경하기 쉬운 클래스
  • 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
• OCP(Open-Closed Principle)
  • 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 객체 지향 설계에서 핵심 원칙
  • 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
• 변경으로부터 격리
  • 요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다.
  • 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
    그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
  • 상세한 구현에 의존하는 코드는 테스트가 어렵다.
  • 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
  • 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.
  • 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다.
• DIP(Dependency Inversion Principle)
  • 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. OCP, DIP 등 객체지향 선계의 핵심 원칙을 단순히 개념만 공부하는 정도로 했다는 걸 느꼈습니다.
   => "OCP는 이거다!"라는 개념이 아니라 빌드업 형식으로 책에서 설명해 이해에 도움되었습니다.
   
   
2. 강한 결합도의 코드를 짜서 프로젝트의 방향성이 조금만 바뀌어도 프로젝트가 흔들린 경험이 있습니다.
   => '위와 같은 개념을 알고 있었다면 프로젝트에서 어떻게 적용했을까?'라는 생각을 했습니다.
   => 당장 적용하는 것은 힘들겠지만, 코드를 작성하고 리팩터링 하면서 배워야겠다고 느꼈습니다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 이런 원칙을 지키기 위해서는 어떻게 해야 할까?
  • 직접 더러운 코드를 작성해보고 잘 작성한 사람의 코드를 봐야 된다고 생각합니다.
  • 좋은 책을 쓰기 위해서는 잘 작성한 사람의 책을 보고 분석하는 것과 비슷한 것 같습니다.

👀 소감 3줄 요약

• OCP -> 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.
• 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
• DIP -> 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다.