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

  • 변수를 비공개(private)로 정의하는 이유가 있다.
    => 남들이 변수에 의존하지 않게 만들고 싶어서다.
    => 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다.

  • 자료 추상화
    => 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.
    => 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다.
    => 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다.
    => 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다.
    아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.

  • 자료/객체 비대칭
    객체: 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
    자료 구조: 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.​
    => 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.
         반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
    => 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다.
         객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.
  • 분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다.
    때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.

  • 디미터 법칙
    => 디미터 법칙은 잘 알려진 휴리스틱(heuristic)으로, 모듈은 자신이 조작하는 객체의 속사정을
         몰라야 한다는 법칙이다.

    => 기차 충돌 코드
    final String = outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();​
     리팩터링 전 기차 충돌 코드(위)

    Options opts = ctxt.getOptions();
    File scratchDir = opts.getScratchDir();
    final String outputDir = scratchDir.getAbsolutePath();​
    리팩터링 후(위)

  • 자료 전달 객체(DTO)
    => 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다.
         이런 자료 구조체를 때로는 자료 전달 객체(Data Transfer Object, DTO)라 한다.
    => DTO는 데이터베이스에 저장된 가공되지 않은 정보를 애플리케이션 코드에서 사용할 객체로
         변환하는 일련의 단계에서 가장 처음으로 사용하는 구조체다.

  • 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.
    => 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다.
    => 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.

 

 

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

  1. 롬복(Lombok)이라는 라이브러리가 있는데 @Data를 엔티티에 무분별하게 사용하는 코드를 봤었다.
    => @Data는 getter, setter 등 반복적인 것을 추가하는 번거로움을 줄여주는 어노테이션이다.
    하지만 이 책을 읽고 이것을 무분별하게 사용하면 독이 된다는 것을 알게 되었습니다.
    => 책에서 나오는 '아무 생각 없이 조회(Getter) / 설정(Setter)를 추가하는 방법이 가장 나쁘다' 부분에 해당

  2. 혹시 내 코드가 잡종 구조?
    => 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다고 한다.
    => 양쪽 세상에서 단점만 모아놓은 구조라고 한다.
    => 우선 강의에 나오는 패턴을 거의 비슷하게 따라하면서 작성을 해서 설계를 크게 고려하지 않았기 때문이다.

  3. 기차 충돌코드 어디서 본 것 같은데?
            if (!userDetails.getUsername().equals(dictQuestion.getUser().getUsername())) {
                throw new IllegalArgumentException(NOT_MY_QUESTION);
            }​
    => 웹사이트에 접속해 로그인한 유저와 질문 게시글 작성자의 아이디가 같은지 확인하는 if문 입니다.
    => dictQuestion.getUser().getUsername()이 예시로 보여준 기차 충돌코드와 똑같다.
    => 우선 엔티티 설계가 이렇게 되어 있어서 이 부분을 어떻게 수정 해야 할 지 지금은 감이 안잡힌다.
         다음에 엔티티를 설계 할 때는 이런 문제가 발생하지 않도록 해야겠다.

 

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

  • 6장은 객체와 자료구조에 대해 알고 있는 게 적어서 다른 분이 작성한 것을 참고했습니다.
    => 객체지향 파트는 어느정도 읽기는 할 수 있었는데 자료구조라는 파트가 어려웠습니다.
    => 객체지향과 절차지향의 차이를 설명하는 것 같았습니다.

 

 

 

👀 소감 3줄 요약

  • 객체지향을 예전에 책으로 공부 했지만 아직도 한참 부족하다는 걸 느꼈습니다.
  • 객체는 동작을 공개하고 자료를 숨긴다.
  • 자료 구조는 별다른 동작 없이 자료를 노출한다.

 

 

 
반응형

+ Recent posts