담백한 웹 개발 이야기

DIP: 의존성 역전 원칙 (Dependency Inversion Principle) 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하여 구체에는 의존하지 않는 시스템이다. 이 아이디어를 규칙으로 보기는 확실히 비현실적이다. 소프트웨어 시스템이라면 구체적인 많은 장치에 반드시 의존하기 때문이다. DIP를 논할 때 운영체제나 플랫폼같이 안전성이 보장된 환경에 대해서는 무시하는 편이다. 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소이다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수밖에 없는 모듈들이다. 인터페이스는 구현체보다 변동성이 낮다. 그래서 실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동..

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle) Ops 클래스 그리고 op1, op2, op3 오퍼레이션이 있고 사용자 클래스인 User1, User2, User3가 있다고 가정하겠다. User1은 op1만 사용하고, User2은 op2만 사용하고, User3은 op3만 사용한다. Ops의 오퍼레이션이 하나라도 수정되면 사용자 클래스는 모두 수정되어야 한다. 각 사용자 클래스는 사용하지 않는 오퍼레이션에 의존하고 있다. 오퍼레이션의 의존성을 분리하기 위해서는 op1, op2, op3의 인터페이스를 분리하여 해결할 수 있다. ISP를 아키텍처가 아니라 언어와 관련된 문제라고 결론 내일 여지가 있다. 정적 타입언어는 사용자가 타입선언문을 사용하도록 강제한다. 선언문..

LSP: 리스코프 치환 원칙 (Liskov Substitution Principle) 리스코프 치환 원칙는 바바라 리스코프가 정의한 원칙으로 바바라 리스코드는 하위 타입을 다음과 같이 정의했다. 여기에서 필요한 것은 다음과 같은 치환(substitution) 원칙이다. S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다. SOLID 원칙 시리즈 - 리스코프 치환 원칙 LSP: 리..

OCP: 개방-패쇄 원칙 (Open-Closed Principle) 개방 폐쇄 원칙은 "소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀있어야 한다."를 의미한다. 다시 말해 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안 된다. 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문이다. 만약 요구사항을 살짝 확장하는 데 수정사항이 많다면 설계한 아키텍트는 엄청난 실패에 맞닥뜨린 것이다. 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화될 것이다. 이상적인 변경량은 0이다. 어떻게 하면 될까? 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일 책임 원칙, SRP), 이들 요소 사이의 의존성을 체계화함으..

SRP: 단일 책임 원칙 (Single Responsibility Principle) 역사적으로 SRP는 "단일 모듈은 변경의 이유가 하나. 오직 하나뿐이어야 한다."로 기술되어 있다. 변경의 이유는 무엇을 의미하는 할까? 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 변경의 이유는 바로 이들 사용자와 이해관계자를 가리킨다. 단일 모듈은 무엇을 의미하는 할까? 가장 단순한 정의는 소스파일이다. 대부분의 경우 이 정의는 잘 들어 맞는다. 하지만 일부 언어와 개발 환경에서는 코드를 소스파일에 저장하지 않는다. 이러한 경우 모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다. 응집된이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바..