본문으로 건너뛰기

FundamentalOOP

26
FundamentalOOP

오브젝트; 개방-폐쇄 원칙

개방 폐쇄 원칙 Open-Closed Principle : 소프트웨어 개체 (클래스, 모듈, 함수) 는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 이는 다음의 관점을 반영한다. 확장 -> 동작 확장에 대해 열려 있다 : 어플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 어플리케이션의 기능을 확장할 수 있다. 수정 -> 코드 수정에 대해 닫혀 있다 : 기존의 코드를 수정하지 않고도 어플리케이션의 동작을 추가하거나 변경할 수 있다. 인터페이스, 추상화는 컴파일타임 의존성을 고정기키게 한
FundamentalOOP

오브젝트; 추상화에 의존하기

모든 의존성이 나쁜것은 아니다. 의존성은 객체들의 협력을 가능하게 만드는 매개체라는 관점에서 자연스러운 것. 바람직한 의존성 = 재사용성 어떤 의존성이 다양한 환경에서 클래스를 재사용할 수 없도록 제한한다면 그 의존성은 바람직하지 못한 것. 즉, 컨텍스트에 독립적인 의존성은 바람직하다. 의존성에 대한 정도 = 결합도 (약한 결합도, 강한 결합도) 의존성과 결합도 일반적으로 의존성과 결합도를 동의어로 사용하지만 사실 두 용어는 서로 다른 관점에서 관계의 특성을 설명하는 용어다. 의존성은 두 요소 사이의 관계 유무를 설명한다. 따라서
FundamentalOOP

오브젝트; 의존성과 전이

작고 응집도 높은 객체란 책임의 초점이 명확하고 한가지 일만 잘 하는 객체를 의미한다. 작은 객체들은 단독으로 수행할 수 있는 작업이 거의 없기 때문에 기능을 구현하기 위해 다른 객체와 협력해야 한다. 그러나 과도한 협력은 다른 객체에 대해 의존하게 된다. 객체지향 설계는 의존성을 관리하는 것이다. 또한 객체가 변화를 받아들일 수 있게 의존성을 정리하는 기술이다. 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다. 실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 한다.
FundamentalOOP

오브젝트; 절차 추상화와 타입 추상화

타입 : 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미. 안타깝게도 프로시저만으로는 충분히 풍부한 추상화의 어휘집을 제공할 수 없다. 이것은 언어 설계에서 가장 중요한 추상 데이터 타입의 개념으로 우리를 인도한다. 추상 데이터 타입은 추상 객체의 클래스를 정의한 것으로 추상 객체에 사용할 수 있는 오퍼레이션을 이용해 규정된다. 이것은 오퍼레이션을 이용해 추상 데이터 타입을 정의할 수 있음을 의미한다. 추상 데이터 객체를 사용할 때 프로그래머는 오직 객체가 외부에 제공하는 행위에만 관심을 가지며
FundamentalOOP

오브젝트; 하향식 기능 분해

STM LTM 인지 과부하 추상화 분해 프로시저 추상화 Procedure abstraction : 소프트웨어가 무엇을 해야 하는지 추상화 기능 분해 Functional decomposition 또는 알고리즘 분해 Algorithm decomposition 데이터 추상화 Data abstraction : 소프트웨어가 무엇을 알아야 하는지 추상화 데이터를 중심으로 타입을 추상화 Type abstraction : 추상 데이터 타입 Abstract data type 데이터를 중심으로 프로시저를 추상화 Procedure abstraction
FundamentalOOP

오브젝트; 명령-쿼리 분리

퍼블릭 인터페이스에 오퍼레이션을 정의할때 참고할 수 있는 지침을 제공. 루틴 Routine : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 프로시저 Procedure : 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 종류. 부수효과를 발생시킴 함수 Function : 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 종류. 부수효과가 없다. 명령 Command : 객체의 상태를 변경하는 명령은 반환값을 가질 수 없다. 쿼리 Query : 객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다. 질문이 답변을 수정해서
FundamentalOOP

오브젝트; 디미터 법칙

퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법 디미터 법칙 묻지 말고 시켜라 의도를 드러내는 인터페이스 명령-쿼리 분리 디미터 법칙 낯선 자에게 말하지 마라. 오직 인접한 이웃하고만 말하라. 오직 하나의 도트만 사용하라. 클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍해야 한다. this 객체 메서드의 매개변수 this의 속성 this의 속성인 컬렉션의 요소 메서드 내에서 생성된 지역 객체 부끄럼타는 코드 Shy code : 불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체
FundamentalOOP

오브젝트; 메시지와 인터페이스

객체지향 프로그래밍에서 어플리케이션이 클래스의 집합으로 구성된다는것은 오해다. 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이를 수 있다. 좋은 객체지향 코드를 얻기 위해서 클래스가 아닌 객체를 지향해야 한다. 이는 곧 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 책임은 객체가 수신할 수 있는 메시지의 기반이 된다. 메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐이다. 협력 안에서 메시지를 전송하는 객체를 클라이언