Study/오프젝트 (14) 썸네일형 리스트형 14) 일관성 있는 협력 객체는 협력을 위해 존재한다. 협력은 객체가 존재하는 이유와 문맥을 제공한다. 객체지향 패러다임의 장점은 설계를 ㅠ할 수 있다는 것이다. 재사용을 위해서는 객체들의 협력 방식을 일관성 있게 만들어 야한다. 비일관성은 두 가지 상황에서 발목을 잡는다. 하나는 새로운 구현을 추가해야 하는 상황이고, 또 다른 하나는 기존의 구현을 이해해야 하는 상황이다. 유사한 요구사항이 서로 다른 방식으로 구현돼 있다면 요구사항이 유사하다는 사실 자체도 의심하게 될 것이다. 따라서 유사한 기능을 서로 다른 방식으로 구현해서는 안 된다는 것이다. 유사한 기능은 유사한 방식으로 구현해야 한다. 객체지향에서 기능을 구현하는 유일한 방법은 객체 사이의 협력을 만드는 것뿐이므로 유지보수 가능한 시스템을 구축하는 첫걸음은 협력을 일관.. 부록 A) 계약에 의한 설계 1. 협력과 계약 계약은 협력을 명확하게 정의하고 커뮤니케이션할 수 있는 범용적인 아이디어다. 각 계약 당사자는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무를 이행한다. 여기서 중요한 부분은 한쪽의 의무가 반대쪽의 권리가 되는 것이다. 예를 들어 이사를 하기 위해 '이삿짐센터'에 작업을 위탁하고 계약을 체결할 것이다. 여기서 '나'의 입장에서 의무는 '이사짐센터'에 이사비용을 지불하는 것이다. 반대로 '이삿짐센터'의 입장에서 의무는 '나'의 이삿짐을 옮겨주는 것이다. 둘 중 계약서에 명시된 내용을 위반한다면 계약은 정상적으로 완료되지 않는다. 2. 계약에 의한 설계 아래의 예를 들어보자. 음식을 구매를 한다고 가정해 보자. 음식 클래스를 보면 name, calory라는 속성을 가진다. 그런데 만약.. 12) 다형성 11장 에서는 코드 재사용을 목적으로 상속을 사용하면 변경하기 어렵고 유연하지 못한 설계가 될 확률이 높다. 상속의 목적은 코드 재사용이 아니라 타입 계층을 구조화하기 위해 사용해야 한다. 이번 장에서는 상속의 관점에서 다형성이 구현되는 기술적인 메커니즘을 살펴보자. 1. 다형성 다형성이란 이름 그대로 '다양한 형태'를 가질 수 있다는 것을 의미한다. 즉 다양한 타입의 객체를 하나의 인터페이스나 클래스를 통해 처리할 수 있게 된다는 말이다. 다형성은 그림과 같이 분류할 수 있다. 오버로딩 다형성 : 하나의 클래스 안에 메서드 이름이 같지만 매개변수의 타입이나 개수가 다른 경우 강제 다형성 : 특정 타입의 값을 다른 타입으로 자동 변환하는 것 ex ) 정수를 실수로 변환 매개변수 다형성 : 일반적으로 제네.. 11) 합성과 유연한 설계 1. 상속과 합성의 차이 상속 부모 클래스와 자식 클래스 사이의 의존성은 컴파일 타임에 해결된다. is-a 관계 클래스 사이의 정적인 관계 코드 작성 시점에 상속 관계 변경 불가 부모 클래스 안에 구현된 코드 자체를 재사용 합성 의존성은 런타임에 해결되며 구현에 의존하지 않고 퍼블릭 인터페이스에 의존한다. has-a 관계 객체 사이의 동적인 관계 실행 시점에 동적으로 변경 가능 객체의 퍼블릭 인터페이스를 재사용 2. 상속 관계를 합성 관계로 변경하기 이번 장에서는 10장에서 구현했던 코드를 통해 상속의 문제점을 알아보고 상속으로 구현한 코드를 합성을 통해 변경에 유연한 코드로 전환하는 장을 설명한다. 우선 상속을 통해 코드를 구현을 하면 안 되는 이유를 알아보자. 중복 코드의 덫에 걸린다. 만약 부가 정.. 10) 상속과 코드 재사용 이번장에서는 상속에 대해서 배우고 중복코드의 치명적인 단점을 학습하는 장이다. 책의 예시로는 전화통화 요금을 예로 들어서 설명한다. 나는 택시로 예를 들어서 따라 학습할 예정이다. 우선 택시의 클래스를 작성했다. 탑승시간과 하차시간을 저장하는 Ride 클래스를 정의했다. public class Ride { private final LocalDateTime boardingTime; private final LocalDateTime gettingOffTime; public Ride(LocalDateTime boardingTime, LocalDateTime gettingOffTime) { this.boardingTime = boardingTime; this.gettingOffTime = gettingOffTi.. 09) 유연한 설계 1. 개방-폐쇄 원칙(OCP) OCP란 확장에는 열려있어야 하고 수정에는 닫혀있어야 한다는 원칙이다. 이전 장에서의 영화예매와 할인정책에서 알 수 있다. 만약 중복할인이라는 기능을 추가하면 기존코드를 손대지 않은 채 정상적으로 작동한다. 이에 따라 애플리케이션의 동작을 확장했다. 따라서 '확장에는 열려있다'. 또한 기존 코드를 수정없이 새로운 클래스(중복할인)를 추가하는 것만으로 할인 정책을 확장하였으므로 '수정에는 닫혀 있다'. 의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조라고 할 수 있다. 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다. 2. 생성 사용 분리 결합도가 높아질수록 OCP를 따르는 구조를 설계하기가.. 08) 의존성 관리하기 1. 의존성 어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다. 의존성은 변경에 의한 영향의 전파 가능성을 암시한다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다. 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는데 있다. 1.1 의존성 전이 영화예매에서의 코드를 떠올려보자. 만약 할인조건이 예매에 의존할경우 할인조건은 예매가 의존하는 대상에 대해서도 자동적으로 의존하게 된다. 다시 말해 예매에 영화정보, 날짜, 고객수가 의존할 경우 할인조건 역시 간접적으로 영화정보, 날짜, 고객수에 의존하게 된다. 할인조건 ---> 예매 ----> 영화.. 07) 객체 분해 1. 추상화 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라고 한다. 가장 일반적인 추상화 방법은 한 번에 다뤄야 하는 문제의 크기를 줄이는 것이다. 프로그래밍 패러다임은 프로그래밍을 구성하기 위해 사용하는 추상화의 종류와 이 추상화를 이용해 소프트웨어를 분해하는 방법의 두 가지 요소로 결정된다. 따라서 모든 프로그래밍 패러다임은 추상화와 분해의 관점에서 설명할 수 있다. 현대적인 프로그래밍 언어를 특징짓는 추상화 메커니즘으로 두 가지가 있다. 프로시저 추상화 : 소프트웨어가 무엇을 해야 하는지를 추상화 기능분해, 알고리즘 분해 데이터 추상화 : 소프트웨어가 무엇을 알아야 하는지를 추상화 데이터를 중심으로 타입을 추상화 - 추상 데이터 타입 데이터를 중심으로 프로시저를 .. 이전 1 2 다음
