정리.

A. 추상

1) 구체에서 중요한것만 남겨서 추상화 해야 한다. 

2) 추상으로 부터 구체를 유추하지 못한 이유

• 추상화 과정에서 중요한 정보를 부각 시키지 못했다.

• 공유 문맥이 없다.

• 중요한 정보의 기준이 다를 수 있다.

• 도메인 영역별 추상화 기준이 다를 수 있다. 

• 잘못된 추상화가 야기하는 side-effect가 크다. 

   

3) 이름짓기

• 줄임말.

   

  • 자제하는 것이 좋으나 관용적인 경우도 있다. 

  • 문맥이 있는 경우에는 허용할 수 있다.(lat, lon)

• 은어/ 방언 사용하지 않기.  

• 좋은 코드를 보고 습득하기

   

4) 메서드와 추상화

- 한 문단의 주제는 반드시 하나여야 한다.

- 메서드는 하나의 일을 해야 한다. 

5) 반환타입 메서드명 (파라미터) {}

• 구성

  • {} : 메서드 구현부

  • 반환타입 + 메서드명 + 파라미터 : 메서드 선언부

  • 메서드명 (파라미터) : 메서드 시그니처

• 메서드명

   

  • 추상화된 구체를 유추할 수 있는 적절한 의미가 담긴 이름

  • 파라미터와 연결지어 더 풍부한 의미를 전달할 수도 있다.

• 파라미터

  • 파라미터의 타입, 개수, 순서를 통해 의미를 전달

  • 파라미터는 외부 세계와 소통하는 창

• 반환타입

  • 메서드 시그니처에 납득 가는, 적절한 타입의 반환값 돌려주기

  • Void대신 충분히 반환할 만한 값이 있는지 고민해보기. 

  • -> 반환값이 있다면 테스트도 용이. 

     

* 한줄이라도 추상화를 하는지 -> 코드 크기보다 추상화로 부여하는 의미가 더 중요하다.

6) 추상화 레벨

• 외부세계 (추상화 레벨이 높다.) 

   

• 내부세계( 추상화 레벨 낮다.)

• 추상화 레벨을 맞춰주어서 읽다가 너무 구체적인 내용으로 나오지 않는지 체크.

   

7) 상수로 추출

• 의미 가지고 있으나 상수로 추출 되지 않은 숫자, 문자열

• 상수 추출로 이름을 짓고 의미를 부여함으로서 가독성과 유지보수성 높아진다. 

B. 논리 사고의 흐름

1) Early return을 해서 if문 복잡하게 만들지 말기

2) 사고의 depth 줄이기:

• 이해하기 복잡하다면 중첩문의 depth 줄이기

• 변수 사용하는 곳 가까이 쓰기

   

3) 공백 라인: 의미를 어디서 나눌지에 대한 의미를 가진다.

4) 부정어는 사용 지양.

5) 예외처리

• 해피케이스도 중요하지만 예외를 꼼꼼히 해야 소프트웨어가 견고해진다.

• 예외 가능성을 낮추기 -> 의도와 다르게 동작하지 않도록 한다.

• 외부와의 접점이 검증 필요

  • 사용자 입력, 외부 서버, 객체 생성자 등

  • 불신을 하면서 검증하며 신뢰를 쌓아간다.

• 의도한 예외랑 의도치 않은 예외 검증

   

  * Optional : orElse(항상 실행), orElseGet(null인 경우만 실행)

   

   

  C. 객체 지향 패러다임

1) 객체로 추상화

• 비공개 필드, 비공개 로직

• 공개 매서드의 선언을 통해 외부와 소통(퍼블릭 인터페이스)

• 객체의 책임이 나뉨에 따라 객체간 협력 발생

2) 객체가 제공하는 것

• 절차 지향에서 잘 보이지 않았던 개념을 가시화

• 관심사가 한군데로 모임.

• 클라이언트는 구현에 신경 쓰지 않고 추상화 레벨에서 도메인 로직 사용 가능.

3) 새로운 객체를 만들 때 주의할 점

• 1개의 관심사로 명확하게 책임 정의 되었는지 확임.

  • 객체를 만듦으로써 외부 세계와 어떤 소통을 하려고 하는지 생각.

• 생성자, 정적 팩토리 메서드에서 유효성 검증이 가능

  • 도메인에 특화된 검증 로직이 들어갈 수 있다.

• Setter 사용 자제 -> 의도 드러내는 메서드로 사용

• getter도 처음에는 사용 자제하고 반드시 필요한 경우 추가.

  • 외부에서 객체 내 데이터가 필요하다고 getter 남발은 무례하다. (또한, 의도를 드러내자)

  • 객체에 메세지를 보내기

• 필드의 수는 적을 수록 좋다.

  • 소나큐브에서는 7개를 권장한다.

4) SOLID

1. SRP : 단일 책임 원칙

    

   • 응집도를 높이고 결합도를 낮추기 위한 방법.

   • 클래스가 변경되는 이유는 하나여야 한다.

   • 테스트가 용이하도록 만들어야 한다.

    

2. OCP : 개방 패쇄의 원칙

    

   • 개방 폐쇄의 원칙은 확장에는 열려있고 수정에는 닫혀있다.

   • 중요한 것은 코드 변경없이 클래스의 추가만으로 확장 가능해야한다.

      

      

3. LSP : 리스코프 치환 원칙

    

   • 자식은 부모의 인스턴스로 치환 가능해야 한다.

      

   • 부모 객체가 쓰이는 곳을 자식으로 모두 바꾸어도 바뀌는 것 없이 작동해야 한다.

    

4. ISP: 인터페이스 분리 원칙

    

   • SRP를 지킬 수 있도록 거대 인터페이스를 만들지 말고 기능별 분리한다.

   • 응집도를 높이며 결합도를 낮춘다.

    

5. DIP: 의존성 역전 원칙

    

   • 기존 고수준 모듈이 저수준 모듈을 의존하는 것을 모두 추상화에 의존하게 만든다.

   • 결과적으로 서로의 결합도를 낮추고 책임과 메시지만 남는다.

미션을 진행하며 배운점.

: 혼자서 객체지향관련 책들을 읽고 프로젝트에 적용해보았지만 정리가 안된 느낌이 강했습니다. 그런데 강의를 들으면서 한번 더 복습하게 되고 멘토님은 어떤 방법이 유용하였고 중요한지 정리해 주셔서 좋다고 생각했습니다. 강의를 들을 수록 이전의 코드들을 되돌아 보게 되네요. 실습을 해보면서 복습도 되고 또 고민했던 부분들에 대해 인사이트를 얻게 되어서 좋습니다. 특히 이번 과제에서는 객체의 책임을 나눌때 "기능적으로 분리"를 해도 되는지 이전 개인 프로젝트에서도 고민이 많았는데 이번 과제를 하면서 어떻게 해야 될지 인사이트가 생겨서 그렇게 개인 프로젝트도 리팩토링 해 보았네요 ㅎㅎ