GRASP: General Principles in Assigning Responsibilities 란? 객체 설계와 책임 할당의 9가지 원칙을 설명한다. 도메인 내에서 어떻게 하면 적절하게 모듈을 나누고 책임을 할당할지에 대한 설계 철학이라고 할 수 있다. 1. Creator 문제 인식 : 누가 객체 A를 생성할 책임을 가질 것인가? 해결책 : 아래의 조건을 만족하는 클래스가 그 책임을 가져갈 후보가 된다. - A 객체를 포함하고 있다.(contain, aggregate) - A 객체의 정보를 기록(Record)하고 있다. - A 객체를 사용하고 있다. - A 객체가 초기화에 필요한 정보를 가지고 있다. 예를들어 아래와 같은 관계인 경우 SmartPhoneFactory가 SmartPhone객체를 생성할..
Dependency Inversion Principle 의존관계 역전 원칙 정의 : 상위 모듈이 하위 모듈에 의존하는게 아니라 상위모듈과 하위모듈 모두 인터페이스(추상화)에 의존해야 한다. 의존관계 역전이란 말이 처음에는 와닿기 힘들다. 따라서 아래의 그림을 비교해서 보면 이해가 조금더 쉬울것 같다. 아래의 그림과 같이 상위모듈이 하위모듈에 의존하는 경우 하나의 하위모듈만 수정을 해도 상위모듈은 영향을 받게 되는 문제점이 있다. 따라서 인터페이스(추상화)를 통해 의존성을 상위모듈->하위모듈 에서 하위모듈->인터페이스 로 역전시켜준다. 이런 식으로 디자인을 변경하면 상위모듈에서 인터페이스를 가지고 있기 때문에 ownership도 가지게 된다. 왜냐하면 인터페이스란 "변하지 않는 것"의 다른말이기 때문에 하..
Interface Segregation Principle 인터페이스 분리 원칙 정의 : 클라이언트는 자신이 사용하지 않는 메소드에 의존하지 않아야 한다. 즉, 인터페이스를 구체적으로 잘게 짤라서 만들어야 한다. 아래와 같이 디자인 된 시스템을 보면 ISP원칙을 적용하면 좋을것 같다. InfoApplication은 getName(), getID()메소드만 사용하고 나머지는 필요 없으며 CareereApplication은 getJobLevel()메소드만 사용한다. 이러한 상황에서 getAge()라는 메소드를 추가하게 되면 Employee클래스에 연관된 모든 클래스가 영향을 받는다. 따라서 아래와 같이 인터페이스를 분리해보자 EmployeeInfo와 EmplyeeCareere로 인터페이스를 분리함으로써 서로간..
Liskov Substitution Principle 리스코프 치환 원칙 정의 : Derived class는 Base class로 반드시 대체 될 수 있어야 한다. 예를 들어 아래와 같은 관계의 클래스가 있을 때 Base myBase = new Derived(); myBase.funcA(); myBase.funcB(); myBase.funcC(); myBase.funcD(); 리스코프 치환 원칙을 위반한 예 Base로 치환된 new Derived가 코드가 문제 없이 모든 메소드를 호출할 수 있어야 한다. 위의 코드가 안되는 경우가 있을까? 아마 java나 c++에서는 컴파일 에러를 발생시키기 때문에 코드 실행이 안되는 경우는 없을 것이다. 그러나 논리적으로 안되게 하는 방법이 있는데 그 예는 java.u..
Open Closed Principle 개방-폐쇄 원칙 정의 : SW entities(클래스, 모듈, 함수등)의 확장에는 열려있고 코드 수정에는 닫혀있어야 하는 원칙 조금 더 직관적으로 말하면 기존의 코드 수정없이 새로운 클래스등을 프로그램에 추가하는 것을 의미한다. 개방-폐쇄 원칙을 지키지 않은 경우에는 클래스가 추가 될 때마다 기존 코드의 수정이 발생하게 되는 문제가 있다. 클래스가 한두개 추가된다면 문제가 없겠지만 수십개가 추가되는 경우라면 OCP 원칙을 기억하면 좋겠다. 개방-폐쇄 원칙을 위반한 예 예를들어 HRManager에서 모든 Employee의 Salary를 계산해야 한다고 가정하자. 아래와 같이 디자인한 경우 각자의 Employee(Developer, Staff, Marketer)의 sa..
OOP에서 SOLID와 같은 원칙은 왜 필요할까? 원칙이 필요한 이유는 바록 나쁜 디자인을 예방하거나 고치기 위함이다. 그러면 나쁜 디자인이란 어떤것일까? 여러가지가 있겠지만 우선 아래와 같은 항목들로 정리해볼 수 있다. 유연하게 변화하지 못하는 경직성(Rigidity), 코드를 수정할 때 다른 코드까지 영향을 주는 취약성(Fragility), 모듈간 커플링이 높아 재사용이 어려운 부동성(Immobility), 나쁜 코드가 쉽게 추가될 수 있는 점착성(Viscosity), 불필요한 복잡성(Needless Complexity), 불필요한 반복(Needless Repetition), 불투명성등이 있겠다. 따라서 위와 같은 문제를 예방하거나 고치기 위해서는 개발 원칙을 준수하며 설계를 하는게 바람직하다. 그 ..
객체지향 패러다임 패러다임이란 한 시대의 사람들의 견해나 사고를 근본적으로 규정하고 있는 인식의 체계. 또는, 사물에 대한 이론적인 틀이나 체계. 을 의미한다. 그러면 객체지향 패러다임은 객체지향적인 사고의 틀을 의미하는데 프로그래밍에서 객체지향은 프로그램의 각 기능과 데이터를 객체로 바라보는 사고를 의미한다. 객체의 기본이 되는 단위는 Class인데 Class는 아래와 같이 정의 된다. Class = ADT(Abstract Data Type) + Inheritance + Polymorphism ADT(Abstract Data Type) ADT 즉, 추상 자료형을 한마디로 정의하면 관련된 데이터와 오퍼레이션을 모은 것이다. 이렇게 했을 때 장점은 1. 관리, 수정 용이 2. 캡슐화로 해당 ADT를 사용하..
