#조영호

의존성 주입 Dependency Injection : 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법 의존성 주입 기법 생성자 주입 Setter 주입 메서드 주입 SERVICE LOCATOR 패턴 서비스를 사용하는 코드로부터 서비스가 누구인지 (서비스를 구현한 구체 클래스의 타입이 무엇인지), 어디에 있는지(클래스 인스턴스를 어떻게 얻을지)를 몰라도 되게 해준다. 사용처에서 특정 인스터스에 의존하기 원한다면 아래와 같이 사용해야 한다. Movie 생성자 만으로 의존성이 해결되지

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

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

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

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

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

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

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