4주차 - 2.10 직교성

[DaehunGwak]

진도

2.10 직교성

일시

• 2022.12.04.(일) 21:00

[donghoon-song]

Topic10 직교성

하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.

우리가 설계하고 싶은 것은 자족적인(단일하고 잘 정의된 목적을 가진) 독립적인 컴포넌트

직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다.(M x N)

‘특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?’ → 한개여야 한다.

불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성할 것.(shy)

직교적으로 설계하고 구현한 시스템 → 테스트하기 더 쉽다

모듈 수준의 테스트나 단위 테스트가 통합 테스트보다 테스트 케이스를 만들고 수행하기 훨씬 쉽다.

단위 테스트를 작성하는 행위는 직교성을 테스트해 볼 수 있는 기회

도전해 볼 것

• GUI가 있는 경우 여러 기능을 묶어서 사용하거나 할 때에는 수동으로 해야 함. 셸 프롬프트에서는 그걸 묶은 새로운 명령어를 만들어서 사용 가능.

연습 문제 1

• Split2가 직교적이라고 생각. Split1에는 다음 줄로 이동하는 역할이 포함. 하지만 바로 다음 줄이 아니라 한 줄씩 건너뛰는 등 요구사항이 변경되면 readNextLine을 변경해야 함.

[Edwin222]

대체로 너무나 맞는 말...

자신의 힘으로 제어할 수 없는 값에 의존하면 안된다. : 어렵긴 한데 유념은 해두어야 하는 가치 같다

도전해 볼 것

Q1. 배우긴 GUI툴이 쉽고, 여러 도구와 함께 동작해야 한다면 셸 스크립트가 쉽다.

사실 대부분의 툴들은 GUI와 셸 스크립트를 함께 제공한다.

셸 스크립트는 대체로 국소적이고 원자적인 수준의 여러 동작을 커맨드라인으로 지원하고, GUI 툴은 커맨드라인으로 일일히 라인마다 입력해야 하는 동작을 버튼 하나에 묶어서 처리할 수 있도록 해주는 방향의 설계가 정석이라 생각.

위와 같은 방식으로 만들면, 개별 기능들은 프로그램 내부에 한 벌씩만 존재하고, 접근하는 방법이 스크립트/GUI로 갈리는 형태가 된다.

Q2. 상속을 쓰면... 속상하지...

학교에서 상속을 가르칠 때 마치 이것이 모든 중복에 대한 답인 것 처럼 소개하지만 그래선 안된다... 신중하게 고르고 골라서 쓰지 않으면 격렬한 결합도 상승을 겪게 된다.. 특히 잘 모르고 쓰면 Composition 관계여야 하는 걸 상속으로 표현하게 된다.

상속을 사용하면 베이스 클래스의 변경이 모든 확장 클래스들에 여파를 주는데 심지어 그게 눈으로 잘 보이지 않는다.

그래서 깡 상속은 정말 어지간하면 피하는게 맞다 생각하고, 최소 추상 클래스, 가능하면 인터페이스를 쓰는게 좋다고 본다.

인터페이스는 뭐가 다르냐? 내부 구현이 없이 메소드나 프로퍼티의 모양만을 정의하기 때문에 상속에 비해 결합도를 덜 올리면서도 다형성의 이점을 얻을 수 있음.

연습 문제

Q1. Split2

입력이 들어오는 방법이 변해도 동일하게 사용 가능하다.

가령 파일에서 데이터를 읽는게 아니라 어떤 프로세스의 표준 출력을 읽어서 쪼개고 싶다거나..

아니면 네트워크 스트림을 읽어서 쪼개고 싶다거나 등등..

Q2.

객체지향은 상태의 관리 측면에서 직교적이다. 적절히 캡슐화되었다면 서로 다른 클래스 A와 B의 상태 변화는 서로에 대한 영향 없이 일어나고 관리된다는 것을 보장할 수 있다.

함수형은 각각의 기능들이 직교적이다. 사이드 이펙트가 없는 기능들로 잘 만들었다면 개별 기능들은 의도한 입력과 출력을 동일하게 유지할 수 있다는 전제 하에 어떻게 갈아끼우거나 고쳐도 상관이 없음.

어떤 언어는 무슨 패러다임으로 작성하기 좀더 쉬울 수 있다거나 할 수 있겠지만 결국 사용하는 방법의 차이라고 생각한다.

[minkukjo]

이야기 해볼 것

• 직교적인 것은 아무래도 CLI겠지만, 요즘은 IDE에서 CLI를 기본적으로 내장하고 있어서, 철저히 유저의 취향에 맞게 제공할 수 있는 부분이라 생각. 다만 어떤 것이 더 배우기 쉽냐에 대해서는 어느정도 의견 차이가 있을 듯 한데, 나는 GUI에 손을 들어주고 싶다.
• 자바의 인터페이스와 C++의 다중상속은 엄밀히 다르게 문제를 푼 케이스라 생각한다. 일단 C++는 다중 상속 다이아몬드를 피할 수 없는 반면, 자바의 인터페이스는 구현을 구현체에게 맡겨 다형성을 얻었다. 오죽했으면 자바를 만든 제임스 고슬랭 아저씨가 자바에 상속을 만든 것이 실수라고 말했겠는가? 해당 인터뷰 전문 A delegation-only language 부분 부터 보면 된다.

Venners:When asked what you might do differently 
if you could recreate Java, you've said you've wondered what it would be like to have a language that just does delegation.

Gosling:Yes.

연습문제

1

• Split2 직교성을 위해선 최대한 단순하게 만드는 것이 중요하다. 그래야 유연한 소프트웨어를 만들 수 있다. ( FOP의 Pure Fucntion과 High order fuction 같은 느낌 )

2

• 객체지향의 직교성은 어떤 동작의 수행과 상태를 하나의 객체 단위로 묶어서 하나의 함수 내에서 복잡한 로직이 수행되는 것을 막고 객체 간의 의존성을 분리하는 식으로 직교성을 얻고자 하였다.
• 그러나 함수형의 직교성은 함수 자체를 하나의 동작 단위로 보고, 불변성을 가지면서 작은 단위의 함수들을 호출하여 더 복잡한 로직을 수행하는 함수들을 만들어나가는 방식으로 전개되어 나간다.
• 요즘은 둘을 짬뽕한 메타가 유행이긴 하다.

[DaehunGwak]

• 직교성이란?
  • 직교한다 → 두개의 선은 독립적
  • 컴퓨터 과학에선 독립성, 디커플링을 의미
  • 비-직교적인 시스템: 모든 행동에 따라 다른 사이드 이펙트가 발생
• 직교성의 장점
  • tip17. 관련 없는 것들 간에 서로 영향이 없도록 하라
  • 우리가 설계하고 싶은것은 독립적인 컴포넌트
  • 직교적인 시스템은 생상선 향상과 리스크 감소가 있다
• 설계
  • 특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?
    • 직교적인 시스템은 답이 하나
  • 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는지도 확인 (전화번호, 주민 등록 번호 등)
    • 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라
• 도전해 볼것
  • GUI 프로그램 vs 셸 프로그램
    • 무엇이 직교적 → 셸
    • 의도한 목적을 정확히 수행하기 쉬운가 → 의도에 따라 다름
    • 처음 보는 작업을 할 때 다른 툴과 조합하여 사용하기 편리 → 사람에 따라 다름
    • 더 배우기 쉬운가? → GUI
  • 다중 상속, 인터 페이스, 믹스인이 직교성에 끼치는 영향
    • 위임과 상속의 차이
• 연습 문제
  • 연습 문제 1
    • My Answer: Split2 가 더 직교적 → 파일 읽기 모듈에 의존하지 않고 읽은 한 줄에 대해서만 getField 를 할 수 있으므로, 그리고 파일 읽기에만 국한되지 않음
  • 연습 문제 2
    • My Answer
      • 객체 지향언 언어는 만드는 설계에 따라 직교적일 수도 아닐 수도 있다
      • 반면 함수형은 Input 데이터의 변경 없이 새로운 Output 데이터를 생성하므로 객체 지향에 비해 직교적이라 할 수 있다.
    • Solution
      • 함수형도 모종의 결합이 생길 수 있음 → 현재 함수 output 과 다음 함수 input 의 타입 매칭에 대한 결합성이 존재

[DaehunGwak]

• 생각 나는 사례
  • 어떤 모듈에서도 사용할 수 있는 코어(유틸리티) 모듈은 어떻게 설계해야할까?
    • 재사용성을 위해 분리해서 이것저곳에서 다쓸 수 있는 코어 모듈을 설계하는 방법?
    • 이후 각 기능 별로 분리 될 수 있으므로 코어 모듈을 가져가지 말고 서비스 모듈에서 각자 개발하는 것은?
  • 클라이언트 to 서버 유입 되는 Ingoing-request DTO -> 서버 to 서버 Outgoing-request DTO 변환 시,
    • Ingoing-request DTO 가 변경이 많아지는 경우를 대비해 Ingoing-request DTO에서 Ougoing-request DTO 로 만들어야 할지
    • Outgoing-request DTO 가 자발적으로 스스로 행동하기 위해 Outgoing-request DTO에서 ingoing-request 를 받아 만들어야 할지

[DaehunGwak]

• 코어 모듈이 나쁘진 않다?
  • batch, api, consumer 공통적인 도메인 모델은 공통적으로 뺄 수 있음
  • 근본적으로는 코드 아키텍처 자체를 나눠야 한다 생각함 -> 헥사고날 아키텍처(?)
• 코어 모듈을 멀쩡하게 만들려면 모듈에 상태가 없는 케이스만 가능하지 않을까
  • 코어는 수학아니면 없지 않나
  • 의존성이 너무 많이 생겨 변경점이 너무 많아질 수 있음

// client -> server A
class IngoingRequest {
  public OutgoingRequest toOutgoingRequest() {
    // 1 번. 클라이언트를 고치는건 빌드에 영향이가서 서버에서만 고치는 방향이 좋을 수 있다. (클라이언트 빌드 및 심사 케이스)
    return new OutgoingRequest(this...);
  }
}

// server A -> server B
class OutgoingRequest { 
  public OutogingRequest(IngoingRequest request) {
    // 2 번. 이것 보단
  }

  public OutogingRequest(필요한 값만 적기) {
    // 2 번. 필요한 파라미터만 생성자로 가져가고 비즈니스로직에서 풀어헤치면 생성자가 많아지는 것을 방지할 수 있을 것이다.
  }
}