클린 코드(Clean Code)/클린 아키텍처요약
-
12장 - 컴포넌트클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 13. 00:01
SOLID와 컴포넌트 SOLID가 벽과 벽돌의 어떻게 배치하는지 알려준다면 컴포넌트는 빌딩에 어떻게 방을 배치하는지 설명합니다. 컴포넌트란? 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위입니다. 자바의 경우 jar파일이 컴포넌트입니다. 또한 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있습니다. 잘 설계된 컴포넌트는 독립적으로 배포 가능하고 개발 가능한 능력을 갖추어야 합니다. 역사 소프트웨어 개발 초장기에는 프로그램의 시작부에 프로그램이 로드될 주소를 선언하는 구문이 필요했습니다. 한번 위치가 결정되면 재배치가 불가능했습니다. 이런 구시대에 라이브러리 함수에 접근하기 위해서는 소스 코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일했습니다. 이 시대의 장치는 ..
-
11장 - DIP: 의존성 역전 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 27. 00:01
의존성 역전 원칙 추상화에 의존하며 구체에는 의존하지 않음을 의미합니다. 하지만 소프트웨어의 시스템은 많은 구체화에 의존합니다. 예를 들어 String은 구체 클래스이며 추상 클래스로 만들려는 시도는 현실성이 없습니다. String 클래스는 매우 안정적으로 변경되는 일은 거의 없으며, 있더라도 엄격하게 통제됩니다. 따라서 DIP를 논할 때 OS나 플랫폼과 같이 안정성이 보장된 환경에 대해서는 무시하는 편입니다. 우리가 중요하게 생각해야 할 것은 열심히 개발중이라 자주 변경될 수밖에 없는 모듈들입니다. DIP를 지키는 매우 구체적인 코딩 실천법 - 변동성이 큰 구체 클래스를 참조하지 말아야 한다. - 변동성이 큰 구체 클래스로부터 파생하지 말아야 한다. - 구체 함수를 오버라이드 하지 말아야 한다. (추상..
-
10장 - ISP: 인터페이스 분리 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 26. 00:01
인터페이스 분리 원칙 책의 예제에서는 op1, op2, op3 메서드를 포함하고 있는 ops 인터페이스를 소개합니다. 이때 user1은 op1 만 user2는 op2 만 user3는 op3 만 사용한다고 하더라도 3가지 추상 클래스를 모두 구현해야 합니다. 또한 정적 타입 언어로 작성된 클래스라 하였을 때 op2의 소스 코드가 변경되면 user1도 다시 컴파일한 후 새로 배포해야 합니다. 따라서 op1, op2, op3를 각각의 인터페이스로 분리하여 사용하게 된다면 이런 문제를 해결할 수 있습니다. ISP와 언어 사실 동적 언어 타입의 언어라면 런타임에 추론을 하기 때문에 소스 코드 의존성이 아예 없어져 재컴파일과 재배포가 필요 없습니다. 따라서 ISP를 아키텍처보다는 언어와 관련된 문제라고 결론 내릴 ..
-
9장 - LSP: 리스코프 치환 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 25. 00:01
리스코프 치환 원칙 간단하게 인터페이스 하나를 두고 2개의 구현 클래스가 o1, o2가 존재할 때 o2자리에 o1을 치환하더라도 행위가 변하지 않아야 합니다. 인터페이스와 상속 License라는 인터페이스가 존재하며 calcFee라는 메서드를 가집니다. 이때 PersonalLicense와 BusinessLicense라는 2가지의 License 인터페이스를 구현하는 클래스가 존재합니다. 두 클래스는 서로 다른 알고리즘을 이용해서 라이선스 비용을 계산합니다. 이때 프로그램이 License 인터페이스에 의존하고 있다면 이들 하위 타입 중 무엇을 사용하는지는 중요하지 않습니다. 정사각형/직사각형 문제 : LSP 위반 정사각형은 직사각형의 하위 타입으로는 적절하지 않습니다. 직사각형은 높이와 너비가 서로 독립적인..
-
8장 - OCP: 개방-폐쇄 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 24. 00:01
개방 폐쇄 원칙 개방 폐쇄 원칙이라는 용어는 버트란트 마이어가 만들었습니다. 확장에는 열려있어야 하고 변경에는 닫혀 있어야 한다라는 뜻입니다. 소프트웨어를 확장할 때 수정이 엄청나게 발생한다면 시스템을 설계한 아키텍트는 엄청난 실패를 한 것입니다. 우선 2가지의 책임이 있다면 책임을 분리하는 것에서 시작합니다. 2가지의 책임 중 하나가 변경되더라도 다른 하나의 책임에 대한 코드는 변경하지 않도록 소스 코드 의존성을 확실히 조직화해야 합니다. 이런 목적을 달성하기 위해서는 인터페이스와 구현 클래스를 활용합니다. A컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 A 컴포넌트가 B컴포넌트에 의존해야 합니다. 따라서 가장 높은 수준의 정책을 포함하는 Interactor가 최상위에 존재하여 다른 컴포넌트..
-
7장 - SRP : 단일 책임 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 23. 00:01
단일 책임 원칙의 오해 모듈이 단 하나의 일만 해야 한다는 의미로 받아들이기 쉽습니다. 하지만 역사적으로 다음과 같은 의미를 가집니다. 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다. 변경의 이유는 사용자와 이해관계자를 가리킵니다. 사용자나 이해관계자가 여러 명일 수 있기 때문에 이런 의미보다는 변경을 요청하는 한 명 이상의 사람들을 가리키며 이러한 집단을 엑터라 합니다. 다시 말해 하나의 모듈(소스 파일)은 하나의 액터에 대해서만 책임져야 합니다. SRP 위반 예시 중복을 허용하자 Employee 클래스는 calculatePay(), reportHours(), save()를 가집니다. 세 가지 메서드는 매우 다른 세명의 액터를 책임집니다. calculatePay - 회계팀에서 기능을 정의 r..
-
4장,5장,6장클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 22. 00:01
4,5,6장에 대해서는 인상 깊은 내용에 대해서만 정리하고자 합니다. 4장 - 구조적 프로그래밍 다익스트라는 "테스트가 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다"라고 말했습니다. 다시 말해 프로그래밍이 잘못되었음은 증명할 수 있지만 프로그래밍이 맞다고 증명할 순 없습니다. 5장 - 객체지향 프로그래밍 캡슐화 데이터와 함수가 응집력있게 구성된 집단을 서로 구분 지을 수 있습니다. 하지만 기존의 C언어에 비해서 완벽한 캡슐화가 약화되었습니다. 상속 이전에도 상속을 구현할 수 있었습니다. 다만 더 편리해졌을 뿐입니다. 다형성 다형성을 이용하면 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력을 갖게 됩니다. (인터페이스를 활용한 DI) 이로 인해 저수준의 세부사항은 중요도가 낮은 플러..
-
3장 - 패러다임 개요클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 21. 00:01
구조적 프로그래밍, 객체 지향 프로그래밍, 함수형 프로그래밍에 대해 설명합니다. 구조적 프로그래밍 최초로 적용된 패러다임은 구조적 프로그래밍으로, 1968년 에츠허르 비버 데이크스트라가 발견했습니다. 무분별한 점프는 프로그램 구조에 해롭다는 사실을 제기하였으며 if/then/else와 do/while/until과 같이 더 익숙한 구조로 대체했습니다. 객체지향 프로그래밍 요한 달과 크리스덴 니가드에 의해 구조적 프로그래밍보다 2년 앞서 등장했습니다. 함수 호출 스택 프레임을 힙으로 옮기면 return 후에도 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견했습니다. 이런 함수자 클래스의 생성자가 되었고 지역 변수는 인스턴스 변수, 중첩 함수는 메서드가 되었습니다. 함수형 프로그래밍 최근이 들어서야 겨우 ..