Hi yoahn 개발블로그

고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 세부사항이 정책에 의존해야 한다. 유연성이 극대화된 시스템이란? 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서, use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안된다. 루비나 파이썬과 같은 동적 타입 언어에도 동일한 규칙이 적용된다. 소스코드 의존 관계에서 구체 모듈은 참조해서는 안된다. 하지만 구체 모듈이 무엇인지를 정의하기가 다소 어렵다. 소프트웨어 시스템이라면 구체적인 많은 장치에 의존한다. java 의 String 클래스는 구체 클래스이다. 이를..

소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다. 가정: user1 은 op1 을, user2 는 op2 를, user3 는 op3 만을 사용한다 OPS 가 정적 타입 언어 클래스라면, User 는 사용하지 않는 메서드에 의존하게 된다. 이러한 의존성으로 인해 사용하지 않는 메서드가 변경되면 User 도 다시 컴파일한 후 새로 배포해야 한다. 위와 같이 구성하면, 자신과는 관계없는 변경이라면, 다시 컴파일하고 배포하는 상황은 생기지 않는다. 위의 사례는 정적 타입 언어에 해당하는 사례. 동적 타입 언어(루비, 파이썬)에서는 소스 코드에 이러한 선언문이 존재하지 않는다. 대신 런타임에 추론이 발생한다. 따라서 소스 코드 의존성이 아예 없다. 재컴파일과 재배포가 필요없다. 정적 타입 언어보다 유..

하위 타입에 관한 원칙 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성 요소는 반드시 서로 치환 가능해야 한다. S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2 가 있고, o2 자리에 o1 을 치환하더라도 프로그램의 행위가 변하지 않는다면 S 는 T 의 하위 타입이다. 예제 Billing 애플리케이션에서 License의 calcFee() 호출 LSP 준수 설계 → Billing 애플리케이션의 행위가 License 의 하위 타입 중 뭘 사용하는지에 대해 의존하지 않음 정사각형/직사각형 문제 → LSP 위반 Rectangle 의 높이와 너비는 서로 독립적으로 변경될 수 있는 반면, Square의 높이와 너비는 반드시 함께 변경됨 LSP 위반을 막기 위해 실제 타입..

소프트웨어 개체는 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다. 개체의 행위는 확장할 수 있어야 하지만, 개체를 변경해서는 안된다. 기존 코드를 수정하기 보다는 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야 소프트웨어 시스템을 쉽게 변경할 수 있다. 기능이 추가되는 경우 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 최소화될 것이다. (이상적인 변경량을 0이다.) How? SRP: 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고, DIP: 요소 사이의 의존성을 체계화함으로써 변경량을 최소화할 수 있다. A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 A 컴포넌트가 B 컴포넌트에 의존해야한다. Presenter 에서 발생한 변경으로부터 Cont..

콘웨이 법칙에 따른 따름정리: 소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조에 영향을 받는다. 각 소프트웨어 모듈은 변경의 이유가 단 하나여야 한다. 단일 책임 원칙은 객체 지향 설계 원칙 중 하나로, 하나의 클래스는 하나의 책임만 가져야 한다는 것을 의미합니다. 즉, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다는 것입니다. 이를 통해 클래스의 응집도(cohesion)가 높아지고 결합도(coupling)가 낮아져 유지보수와 확장성이 증가하게 됩니다. SRP를 준수하는 코드는 각 클래스가 자신의 책임에 충실하고 다른 클래스와 관련 없는 기능이 없는 것이 특징입니다. 이를 위해서는 클래스의 책임을 명확히 분리하고, 각각의 책임이 변경될 때 다른 책임에 영향을 ..

깔끔하지 않은 코드를 쓰면 아키텍처가 좋아도 의미가 없고, 깔끔한 코드를 사용하더라도 아키텍처가 나쁘면 의미가 없다. SOLID 좋은 코드로 좋은 아키텍처를 정의하기 위한 원칙 목적 중간 소프트웨어의 구조가 변경에 유연하다. 이해하기 쉽다 많은 SW 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. 중간수준 모듈 수준에서 작업할 때 적용할 수 있다는 것 코드 수준보다는 상위 수준에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움 2023.08.20 - [Computer Engineering] - 7장 SRP: Single Responsibility Principle 단일 책임 원칙 7장 SRP: Single Responsibility Principle 단일 책임 원칙 콘웨이..