본문 바로가기

Develop/소프트웨어 설계

[SOLID] Dependency Inversion 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Dependency Inversion (의존관계 역전) 원칙 상위 모듈과 하위 모듈은 추상적인 약속을 기반으로 소통해야 한다. 자세한 구현은 추상적인 개념에 기반해야 한다. Dependency Inversion (의존관계 역전) 원칙은 객체지향 설계의 핵심인 모듈 간 의존관계 해소를 강조하는 원칙이다. 모듈 간의 의존 관계가 낮아져야 모듈 세부사항을 변경하더라도, 전체 코드에 미치는 영향을 최소화하고 적은 양의 코드로 최대의 효과를 누릴 수 있다. 구체적으로 이야기하자면, 상위 모듈이 하위 모듈의 함수..
[SOLID] Interface Segregation 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Interface Segregation (인터페이스 분리) 원칙 인터페이스를 구현하는 클래스는 필요한 함수만 구현할 수 있도록 설계하자. 원칙에 따라 인터페이스는 최소한의 크기로 설계해야 한다. 그래야 클래스가 필요한 부분만 구현할 수 있다. 예제 청바지 가게에서 아래와 같이 상품을 구현한다고 하자. public interface IProduct { int ID { get; set; } double Weight { get; set; } int Stock { get; set; } int Inseam { ..
[SOLID] Liskov Substitution 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Liskov Substitution (리스코프 치환) 원칙 자식 클래스를 부모 클래스처럼 사용할 수 있도록 설계해야 한다. Liskov Substitution 법칙는 상속과 관련된 규칙이다. 자식 클래스가 만약 부모 클래스에서 기대하는 기능과 달리 동작한다면, 같은 부모 클래스를 상속하더라도 자식 클래스마다 기대하는 결과가 달라지는 어처구니없는 사태가 발생한다. 따라서 자식 클래스는 사용자가 부모 클래스로부터 기대하는 정도에서 너무 멀어지지 않도록 구현해야 한다. 예제 아래 예제 코드는 Circle-e..
[SOLID] Open/Closed 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Open/Closed (개방-폐쇄) 원칙 기능의 확장 가능성은 열려 있는 반면, 기능의 변경 가능성은 닫혀있어야 한다. 반드시 필요한 경우가 아니라면 기존 클래스의 기능을 변경하는 작업은 피해야 한다. 기존 코드가 어디에 어떤 방식으로 사용되고 있는지 모두 파악하기 어렵기 때문에 기존 코드의 변경이 어떠한 결과를 초래할지 정확히 예상할 수 없다. 그러므로 기능의 변경이나 확장이 요구될 때는 기존 클래스를 상속하는 방법으로 기존 코드는 유지하면서 요구사항을 만족시킬 수 있도록 설계해야 한다. 그래야 요구..
[SOLID] Single Responsibility 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Single Responsibility (단일 책임) 원칙 모든 클래스는 하나의 책임만을 부여받으며, 단 하나의 이유만을 바탕으로 변경되어야 한다. 클래스가 제공하는 모든 기능은 클래스가 부여받은 책임에 기반하여 작성되어야 한다. 만약 모든 기능을 하나의 클래스가 책임진다면, 접근하지 말아야 할 변수에 엉뚱한 함수가 접근하여 내부를 부패시킬 수 있다. 반대로 여러 클래스가 하나의 기능을 책임진다면, 기능에 변경이 있을 때마다 각각의 클래스를 변경에 맞추어 완벽하게 작업해야 하는 부담이 발생한다. 특히 ..
[SOLID] SOLID 원칙이란 SOLID 원칙이란 로버트 마틴의 다섯가지 기본 원칙에서 알파벳을 합쳐 만들어진 객체 지향 설계론이다. 원칙의 목적은 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 설계하기 위함이다. Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Exception Not Found 블로그를 참고하여 시리즈를 손쉽게 작성할 수 있었다.
[리팩토링] 제6장 메서드 정리 리팩토링 제6장 메서드 정리 리팩토링의 주된 작업은 코드를 포장하는 메서드를 적절히 정리하는 것이다. 거의 모든 문제점은 장황한 메서드로 인해 생긴다. 장황한 메서드에는 많은 정보가 들어 있는데 마구 얽힌 복잡한 로직에 정보들이 묻혀버린다. 메서드 추출 Extract Method 어떤 코드를 그룹으로 묶어도 되겠다고 판단될 땐 그 코드를 빼내어 목적을 잘 나타내는 직관적인 이름의 메서드로 만들자. 메소드 추출 기법은 제일 많이 사용되는 리팩토링 기법이다. 메서드가 너무 길거나 코드에 주석을 달아야만 의도를 이해할 수 있을 때 코드를 빼내어 별도의 메서드로 만든다. 메서드 추출로 코드의 명료성이 향상되기만 한다면, 메서드명이 추출한 코드보다 길어도 메서드 추출을 실시해야 한다. 메서드가 적절히 잘게 쪼개져..
[리팩토링] 제3장 코드의 구린내 리팩토링 제3장 코드의 구린내 리팩토링을 언제 적용할지 파악하는 능력은 리팩토링 기법을 적용하는 방법만큼 중요하다. 중복코드 Duplicated Code 중복코드는 반드시 리팩토링을 통해 개선할 필요가 있다. 똑같은 코드 구조가 두 군데 이상 있을 때는 그 부분을 하나로 통일해서 개선한다. 중복된 코드는 코드를 관리하기 어렵게 한다. 장황한 메서드 Long Method 메서드가 길면 길수록 코드를 이해하기 이려워지고, 메서드를 재사용하기 힘들어 진다. 리팩토링으로 코드의 재사용성을 높이고 메서드를 이해하기 쉽도록 나누어서 개선한다. 특히 기능 설명이 주석으로 처리된 코드 구간을 메서드로 만들 수 있다면 좋다. 방대한 클래스 Large Class 코드 분량이 너무 방대하거나 기능이 지나치게 많은 클래스는 ..

티스토리툴바