[Week] 3주차 진도

[minSW]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @minSW

진도

• chapter 5 : 형식 맞추기
• chapter 6 : 객체와 자료구조

발표자료

• 발표자료 링크는 여기에!

[ChoMk]

5장 형식 맞추기

정리

• 절절한 행 길이(큰 파일 보다 작은 파일이 이해하기 쉽다.)
• 신문 기사처럼 작성하라(고차원 설명부터 저차원 설명으로..)
• 개념은 빈행으로 분리(무리한 행분리는 별로..)
• 의미가 비스할 수록 밀집하게...(IDE가 쉽게 찾을 수 있게 도와주는데 꼭 그래야할까?)
• 변수는 위쪽에 두자...(팀 컨벤션에 맞게 설정하면 될 듯.. 우리 코틀린에서 compaion object 변수는 전부 최하단에 위치 시킴(static))
• 가로 길이도 유지..(팀에 컨벤션을 정하는 것도 좋은 듯 우리팀은 120 하드랩으로 설정해서 사용 중...)

마음에 드는 말

• 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다.

6 객체와 자료구조

정리

• 절차적인 코드는 새로운 함수를 추가할 때 도형클레스로 가서 수정할 필요는 없다. 하지만 가형적인 도형은 새로운 함수를 추가하면 도형 클래스를 전부 고쳐야한다.(코틀린에서는 data class, class의 차이 같다. 상황에 맞게 어떨 때는 data class를 어떨 때는 class를..)
• 기차 충돌은 피하자.. 조잡해 보인다.

디미터 법칙

• 객체는 그것이 내부적으로 보유하고 있거나 메시지를 통해 확보한 정보만 가지고 의사 결정을 내려야 한다

질문

• 기차 충돌 안에 체이닝도 포함이 될까?(이 책에서는 단순히 다음 클레스 호출을 늘어지게하여 불러오지 말라고 표현한거 같은데...)

[KimYealynn]

Chapter 05. 형식 맞추기

기억에 남는 부분

• String pageName = getPageNameOrDefault(request, "FrontPage"); : 상수를 적절한 수준에 두는 좋은 예, getPageNameOrDefault 안에서 "FrontPage"를 상수로 사용할 수 있지만, 그러면 잘 알려진 상수가 적적하지 않은 저차원 함수에 묻힌다. 상수를 알아야 마땅한 함수에서 함수로 상수를 넘겨주는 방법이 더 좋다. → 앞서 나왔던 저/고 추상화 수준처럼 코드를 특정한 레벨(우리가 이해하는 단계?)에 따라 잘 나누는 게 중요한 듯.

• 세로 순서 : 함수 호출 종속성을 아래방향으로 유지함으로서(중요한 개념을 앞에, 세세한 것을 뒤에) 첫 함수 몇 개만 읽어도 개념을 파악하기 쉬워진다. → 이런 코드 짜본 적도 본적도 잘 없는 것 같지만 ㅜㅜ 노력하기

• 가로 정렬 : 정렬이 필요할 정도로 (선언부)목록이 길다면 문제는 목록 길이(→클래스를 쪼개야 한다는 의미)이지 정렬 부족이 아니다. → ㅎㅎ.. 너무 길어지는 경우가 많던데.... 클래스를 쪼개진 못 하더라도 적어도 세로 공백을 적절히 줘서 이해하기 쉽도록 해야겠다.

Chapter 06. 객체와 자료구조

기억에 남는 부분

• 변수가 private 이더라도 각 값마다 get/set 을 제공한다면 구현을 외부로 노출하는 셈 (==변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지는게 아님). 추상화가 필요하다! 추상 인터페이스를 통해 구현을 모른 채 함수를 조작할 수 있어야 진정한 의미의 클래스이다! → 뼈때리는 말.... ㅎ..... private만 해놓고 안심하지 말고 한 번 더 고민해보기

• 객체에게는 뭔가를 하라고 해야하지 속을 드러내라고 하면 안된다. → 하려는 일의 의미를 파악해서 어떠한 값을 받아서 내가 하려하지 말고 객체가 그 일을 하도록 만들자.

[DaehunGwak]

느낀점

• getter, setter 를 무조건하는게 아니라, 추상화해서 인스턴스를 감추는 노력을 습관해 해보자...
• 장고의 Model은 Active Record Pattern은 베이스로 한다는 것을 이번에 깨달음
  • 하지만 여기에선 비즈니스 규칙을 모델이 추가하지말라 함... (장고 메인 레퍼런스에선 비즈니스모델을 Model에 추가하는 것을 권장함)
  • 고민을 해보고 어디에 배치할지 고민해봐야 할 듯
  • 장고 메인 레퍼런스에선 Big model, small view 를 지향하긴 하나 서비스로 따로 분리해야하진 않을까 늘 고민했었음
  • 장고의 MTV 에선 비즈니스 로직을 어디에 두지? <- 꼭 한번 정리하기
  • https://americanopeople.tistory.com/304

요약

05. 형식 맞추기

• 형식 맞추기: 일관적인 코드 형식으로 의소소통을 원할히 가능 -> 유지보수성 증가
• 세로 순서
  • 빈 행으로 개념 구분
  • 고차원에서 저차원 순서로
  • 변수 선언은 사용하는 곳에 가까이
  • 종속 함수는 가까이
  • 개념적으로 유사한 것 끼리 가까이
• 가로 순서
  • 공백으로 의미 구분 (ex. 수식 항)
  • 그냥 띄우기 많이하지말고 나란히 적기
  • 들여쓰기 무시 X -> 한 줄로 짧게 줄이려는 유혹 뿌리치기

06. 객체와 자료 구조

• 자료 타입을 추가하는 유연성이 필요하다면 객체지향으로
• 새로운 동작을 추가하는 유연성이 필요하다면 절차지향(자료구조)으로
• private 인스턴스에 해당하는 getter, setter를 제공한다면 public과 다르지 않음
• 추상 인터페이스를 제공해 구현체를 모른 채, 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다
• 디미터 법칙: 클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다
  • 클래스 C
  • f가 생성한 객체
  • f의 인수로 넘어온 객체
  • C의 인스턴스 변수에 저장된 객체
• DTO (Data Transfer Object, 자료 전달 객체)
  • 자료 구조체의 전형적인 형태
  • public instance 만 있고 함수가 없는 클래스
• Active Record
  • DTO + save, find 같은 함수 제공
  • DB 테이블이나 다른 소스에서 자료를 직접 변환한 결과

[jin5335]

5.형식 맞추기

형식을 맞추는 목적

• 돌아가기만 하는 코드를
  • 오늘 구현한 기능이 다음 버전에서 변경될 확률을 매우 높으므로, 오늘 구현한 기능의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 끼친다.
• 원래 코드는 사라져도, 개발자의 스타일과 규율은 사라지지 않는다.

적절한 행 길이를 유지하라

• Tomcat, Ant etc 프로그램을 살펴보면, 약 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. (물론 수천줄이 넘어가는 파일도 존재한다.)
• 작은 파일이 큰 파일보다 이해하기 쉽다.

신문기사처럼 작성하라

• 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단 가능하게 할 정도로 신경쓰자.
• 소스파일의 첫 부분은 고차원 개념과 알고리즘 -> 아래로 내려갈수록 의도를 세세하게 표현.

개념은 빈 행으로 분리하라

• 줄바꿈 = 개념 분리

세로 밀집도

• 세로 밀집도 = 연관성
  • 서로 밀집한 코드 행은 세로로 가까이 놓여야 한다는 뜻.

수직 거리

• 연관성: 한 개념을 이해하는데 다른 개념이 중요한 정도.
  • 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.

변수 선언

• 변수는 사용하는 위치에 최대한 가까이 선언한다.
  • 다소 긴 함수의 경우, 블록 상단이나 루프 직전에 변수를 선언하기도 한다.

인스턴스 변수

• 클래스 맨 처음에 선언하며, 변수간에 세로로 거리를 두지 않는다.
  • C++: 맨 아래, Java: 맨 위에 -> 위치는 중요하지 않고 모아두는 것이 중요하다.

종속 함수

• 함수가 다른 함수를 호출하면, 두 함수는 세로로 가까이 배치 한다.
  • 호출하는 함수를 호출되는 함수보다 먼저 배치해서 가독성을 높여라.

• 추가: 상수를 알아야 할 마땅한 함수에서 실제로 사용하는 함수로 상수를 넘겨주는 방법으로,\ 사용하지 않으면 잘 알려진 상수가 적절하지 않은 저차원 함수에 묻힌다.

  • 
    public Response makeResponse(...){
    String pageName = getPageNamedOrDefault(request, "FrontPage");
    
    ...

  }

  private String getPageNamedOrDefault(Request request, String defaultPageName){ String pageName = request.getResource(); if(StringUtil.isBlank(pageName)) pageName = defaultPageName;

  return pageName; }

개념적 유사성

• 친화도가 높을 수록 코드를 가까이 배치한다.
  • 친화도가 높은 요인
  • 종속성(한 함수가 다른 함수를 호출해서 생기는 것)
  • 변수와 그 변수를 사용하는 함수.
  • 비슷한 동작을 수행하는 함수

세로 순서

• 일반적으로 함수 호출 종속성은 아래 방햐을 유지한다.
  • 호출되는 함수를 호출하는 함수보다 나중에 배치한다.(고차원 -> 저차원)

가로 형식 맞추기

• 개인적인 작가의 사견: 120자 정도.

가로 공백과 밀집도

• 가로 공백을 잘 활용하면 밀접한 개념과 느슨한 개념을 표현할 수 있다.
  • 밀접한 개념인 경우에는 붙여쓰고, 느슨한 개념인 경우에는 띄어쓴다. ex) 수식에서 연산 우선순위 표현.

가로 정렬

• TMI
• 요즘 가로정렬을 누가하지..?

들여쓰기

• 들여쓰기 안하는 프로그래머가 누가 잇찌..? (난 아니겠지....)

들여쓰기 무시하기

• 간단한 if문, 짧은 while문의 경우 들여쓰기를 무시하고 싶은 경우가 생기는데, 들여쓰기 하자

가짜 범위

• 빈 while문, for문의 경우 1줄로 끝내지말고 빈줄을 한줄 더 추가해줄 것.

  • while(dis.read(buf, 0, readBufferSize) != -1)
    ;

팀 규칙

• 프로젝트 시작 전에 맞추고 시작하고, 룰을 자동으로 적용시켜주는 툴을 활용하면 좋음.

밥 아저씨의 형식 규칙.

• 예시 - 한번 참고하면 좋음.

6. 객체와 자료구조

자료 추상화

• 위에서 아래로, 추상화 단계를 낮춰가자.
• 변수를 private으로 선언하더라도 각 값의 get, set 함수를 public으로 제공한다면, 이는 구현을 외부로 노출하는 셈이다.
• 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지는 것은 아니다.
• 구현을 감추기 위해서는 추상화가 필요하다.
  • 추상 인터페이스를 제공해 사용자가 구현을 모른 책 자료의 핵심을 조작할 수 있어야 한다.
  • ex) getFuelTankCapacityInGallons() / getGallonsOfGasoline(): 거의 변수를 읽어서 반환.\ getPercentFuelRemaining(): 변수를 읽고, 추상화를 거치고 반환하여 정보의 출처를 알 수 없다.

자료/객체 비대칭

• 객체(Object): 추상화 뒤로 자료를 숨긴 채 자료를 다르는 함수만 제공.
• 자료구조(Data Structure or struct): 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.

	객체(Object)	자료구조(Data Structure or struct)
정의	추상화 뒤로 자료를 숨긴 채 자료를 다르는 함수만 제공.	자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.
장점	새로운 클래스를 추가하기 쉽다.	새로운 함수를 추가하기 쉽니다.
단점	새로운 할수를 추가하기 어렵다.	새로운 자료구조를 추가하기 어렵다.

디미터 법칙

• 잘 알려진 heuristic, 모듈은 자신이 조작하는 개체의 속사정을 몰라야 한다는 법칙
• 자신이 몰라도 되는 객체의 속사정을 알게하지 마라.

가치 충돌(chaining ??)

잡종구조

• 객체 + 자료구조 형식 -> 새로운 함수는 물론이고, 자료구조 추가하기 어려움으로 최대한 지양한다.

구조체 감추기

• 임시 디렉토리의 경로를 가져오는 함수를 만들려고 했는데, 이 함수가 필요한 이유가 임시 디렉토리를 만들려고함이었음.
• 그래서 임시 디렉토리의 경로를 가져오는 함수를 만들지 말고, 임시 디렉토리를 만드는 함수를 생성하는 것으로 변경.
• 임시 디렉토리를 만드는 함수를 구현할 때, 자신의 아래에 객체를 호출하면서 추상화 단계를 낮춰가면서 구현할 수 있었음.

자료 전달 객체

• 자료구조체: 공개 변수만 존재하고, 함수가 없는 클래스.
  • ex) dto, bean(비공개 변수를 조회/설정 함수로 조작)
• 활성 레코드
  • DTO의 특수한 형태.
  • 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과

    결론

  • 어떤 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체사용.
  • 이외에, 새로운 동작을 추가하는 유연성이 필요하면 자료 구조 및 절차적인 코드 적합
  • 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.

[minSW]

Study Week3 (20.07.21)

PR #8

Chapter 5 형식 맞추기

• 가로 형식 맞추기

  • Intellij에서는 Hard wrap(가로 행 길이 가이드 라인)커스텀 설정 가능

• 최신 IDE

  • 요즘엔 Intellij가 너무 똑똑해서...
  • 줄 바꿈이나 람다로 변경 등의 추천이 너무 잘되어있음
  • but, IDE에서 확인할 때와 그냥 코드와의 가독성 갭이 생기는 것 같기도.
  • VScode에서는 저장할때마다 auto formatting해주는것도 있다고 함

Chapter 6 객체와 자료구조

• 객체? 자료구조?

  • jackson을 사용하거나 직렬화가 필요한 객체 (직렬화 객체?)도 자료구조

  • Getter/Setter가 있지만 DTO(활성 레코드)로 봐야하지 않은가

  • (Java말고) 다른 언어에서는..

  • Kotlin

    • data class => 자료구조
    • Getter, Setter, Hashcode 등 자동 생성
    • 다른 내부 로직은 X
    • 이외에도 class seal class object ...
    • 각각 디테일한 의미가 분리되어있음 (<-> Java는 다 class)

  • C

    • struct => 자료구조
    • class => 객체 (변수, 함수)
    • 그러나 버전이 올라가면서 struct에 함수를 추가할 수 있게되고.. class에 변수만 쓰기도하고..

  • 그럼 Java는 어떤가요? (as basis of 📖)

  • Java는 다 class로 두루뭉술...

    마! 이게 OOP다!

• 기차 충돌

  • 기차처럼 보여지는 긴 호출 체인 => 조잡하고 지양되는 코드 => 🤔Q/A 1

  기차 충돌 안에 체이닝도 포함이 될까?(이 책에서는 단순히 다음 클레스 호출을 늘어지게하여 불러오지 말라고 표현한거 같은데...)

  • build pattern / chaining 은 다 수평적인 호출 인 느낌 (순서도 무관)
  • 책에서 말하는 지양하는 케이스는 수직적으로 호출하는 것 (고차원 -> 저차원)

• 구조체 감추기로 기차 충돌 코드 개선한 예시

  • 일단 결론은 객체는 내부구조를 드러내지마라
  • 📌 갓갓 @jin5335 said
  • 예제는 저차원의 함수 (getAbsolutePath())를 맨 위까지 가져와서 처리하지말고, 밑에서 다 처리하고 가져오라는 의미로 이해했다 (createScratchFileStream())

• 활성 레코드

  • 활성 레코드에 비즈니스 규칙 메서드를 추가해 객체처럼 사용하는 경우 => 잡종 구조

  • 장고에서는 "모델 종속적인 기능에대해서는 활성 레코드 자체에 구현"

  • 사실 공통적으로 써서 유틸로 분리할거 아니면..

  • 책 자체가 Java (OOP)를 기준으로 작성

  • 최신의 함수형 프로그래밍과의 갭..

  • 언어에 따라 차이 존재할 듯