본문 바로가기
Study/Book

[Clean Architecture] 2부를 읽고 정리하며 생각해보기

by 겸 2022. 6. 20.

1. 구조적 프로그래밍

제어흐름의 직접적인 전환에 대한 규칙 부과

  • 최초로 적용된 패러다임이다.
  • goto문을 제거하며 점프들을 if, then, else, do, while, until로 대체한다.
  • 모듈 기반 알고리즘에 활용한다.

프로그래밍에도 과학적, 수학적원리를 적용할 수 있을까?

유클리드 계층 구조는 증명 없이 참으로 받아들이는 명제이다.

이 구조를 코드와 결합시켜 코드가 올바르다는 사실을 스스로 증명하는 방식으로 프로그램에 적용했다.

단, 이러한 제어구조는 순차적으로 실행되어야 한다.

이를 통해 모든 프로그램을 순차, 분기, 반복 3가지 구조로 표현할 수 있다는 것을 증명했다.


2. 객체 지향 프로그래밍

제어흐름의 간접적인 전환에 대해 규칙 부과

  • 함수 포인터를 제거하며 객체로 대체한다.
  • 함수 호출 스택 프레임을 힙으로 옮기면 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견하여 함수가 클래스의 생성자가 되고, 지역변수는 인스턴스 변수, 중첩함수는 메서드가 되었다.
  • 아키텍처 경계를 넘나들기 위한 메커니즘으로 활용한다.

객체 지향의 3가지 요소?

  1. 캡슐화 encapsulation
  2. 상속 inheritance
  3. 다형성 polymorphism

캡슐화

데이터와 함수가 응집력 있게 구성된 집단에 대해, 집단 바깥에서는 데이터를 볼 수 없으며 일부 함수만을 통해서만 접근 가능

C언어의 경우 헤더 파일을 활용하며, 다른 객체 지향 언어보다 오히려 가장 강력한 캡슐화를 제공한다..

상속

어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의

다형성

하나의 객체가 여러가지 타입을 가질 수 있는 것

이를 구현하는 대표적인 방법으로 오버로딩, 오버라이딩, 함수형 인터페이스 사용이 있다.

활용

  • 의존성 역전 : 인터페이스 사이의 상속관계과 제어흐름과 반대인 것
    • 이는 소스코드 사이에 인터페이스를 추가함으로써 가능하다.
    • 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한하지 않으며 원하는 방향으로 설정할 수 있다.
  • 배포 독립성 : 의존성의 역전을 잘 활용한다면 컴포넌트를 개별적이고 독립적으로 배포 가능하다.
  • 개발 독립성 : 시스템의 모듈을 독립적으로 배포할 수 있게되면, 서로 다른 팀에서 각 모듈을 독립적으로 개발할 수 있다.

객체 지향은 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력이다.

💡 1. 안드로이드를 개발하면서도 이 원리를 적용해볼 수 있었다.
clean architecture를 적용한 간단한 멀티 모듈앱을 구현한 경험이 있다.
모듈별로 빌드를 따로하여 빌드 소요시간이 줄어들고, 독립적으로 개발 가능하다는 장점이 있었다.

2. 캡슐화, 상속, 다형성의 특징들을 객체지향언어가 아닌 경우에도 적용 가능하다는 사실을 처음 알게되었다

3. 함수형 프로그래밍

변수 할당에 대해 규칙 부과

  • 3가지 패러다임 중 가장 먼저 만들어졌지만 최근에 들어서 겨우 도입되었다.
  • 할당문을 대신하여 람다 계산법의 ‘불변성’ 개념을 사용한다. 변수의 값이 변경되지 않는다.
  • 데이터 관리에 활용
💡 안드로이드 개발자인 내가 쓰는 Kotlin언어도 함수형 프로그래밍을 지원한다~~! (자랑)
하지만 아직 함수형 프로그래밍에 익숙지 않아,, 순수함수 및 함수형 규칙을 따르는 것이 낯설다.
코틀린으로 배우는 함수형 프로그래밍이라는 책을 소장하고 있는데, 아키텍처에 대한 이해를 완료한 뒤 그 중요성을 더욱 깨우치고 나서 읽어봐야겠다.
*Kotlin은 함수형 프로그래밍과 객체 지향 프로그래밍을 모두 지원하는 다중 패러다임 언어이다.

불변성이 아키텍처에 왜 필요할까?

가변 변수로 인해 발생할 수 있는 문제

  1. Race condition : 여러 프로세스가 공용 자원을 사용하려고 동시 접근할 때, 실행 순서에 따라 결괏값이 달라질 수 있는 상황.
    • Mutual exclusion : 경합 조건을 막기위해 두 개 이상 프로세스가 공용 데이터에 동시 접근하는 것을 막는 것으로 요청한 자원이 해제될 때까지 기다려야 한다.
  2. Deadlock condition : 여러 프로세스가 다른 프로세스가 점유하고 있는 자원을 무한 대기하는 상황
  3. concurrent update : 여러 프로세스가 하나의 자원을 동시에 업데이트 하는 상황.
    • Lock : 여러 개의 프로세스가 하나의 자원에 동시에 접근하려할 때 이를 제어해줌.

만약 가변 변수가 없다면? 위와 같은 복잡한 문제가 발생하지 않을 것이다.

💡 아키텍처를 이해하기 위해서도 운영체제의 개념이 나온다. ( 운영체제를 공부해야하는 이유 ++ )
이러한 운영체제상의 문제를 해결하기 위한 방안으로도 아키텍처가 설계된다는 사실을 알게되었다.

이벤트 소싱

상태가 아닌 트랜잭션을 저장. 상태가 필요해지면 모든 트랜잭션을 처리한다.

이를 사용하기 위해 트랜잭션을 저장할 데이터 저장소가 필요하다.

💡 토스 앱을 이용하면서 ‘잔액 내역 조회 점검’ 시간을 꽤 자주 마주했다. 이를 보면서 단순 은행 전산 시스템 점검이 아니라 잔액 내역 조회라는 구체적인 단어에 궁금증이 생겼었다. “잔액.. 그냥 기존 값에 더하고, 빼는게 아니었어?”

이 시간에 트랜잭션을 처리하고 있을 수도 있겠다..?

 

반응형

'Study > Book' 카테고리의 다른 글

[Clean Architecture] 1부를 읽고 정리하며 생각해보기  (0) 2022.06.20