개발 다이어리

의도는 "메시징"이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다. -앨런 케이

자율적인 책임

설계의 품질을 좌우하는 책임

자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체

적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 낳는다.

협력에 참여하는 객체가 얼마나 자율적인지에 따라 애플리케이션 품질이 결정된다.

너무 추상적인 책임

추상적인 것도 정도가 있다. 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것은 문제다.

추상적인 책임은 재사용성과 유연성을 가진다. 다만 협력에 참여하는 의도는 명확하게 설명할 수 있는 수준이야 한다.

'어떻게'가 아니라 '무엇'을

책임을 어떻게는 질지가 중요한게 아니라. 책임이 무엇인지가 중요하다.

어떻게는 구체적인 방법이라 객체의 행동에 자율성을 제한한다.

다형성을 떠올려보자. 무엇을 제공해주는 지가 중요하지 그 방법 따위는 중요치 않다.

이는 결국 결합도와도 연결된다. 

책임을 자극하는 메시지

객체가 자신에게 할당된 책임을 수행하도록 만드는 것은 외부에서 전달되는 요청이다.

사실 객체 간 소통은 요청뿐이다.

요청=메시지

메시지와 메서드

메시지

메시지를 전송함으로써 다른 객체에 접근한다.

메시지는 이름과 인자 두 부분으로 구성(메서드나 함수)

메시지 전송은 수신자, 메시지 이름, 인자로 구성됨

메시지 수신을 통해서만 자신의 책임을 수행할 수 있다.

메시지는 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다. 객체가 메시지를 수신할 수 있다는 것은 객체가 메시지에 해당하는 책임을 수행할 수 있다는 것을 의미한다. 객체가 유일하게 이해할 수 있는 의사소통 수단은 메시지뿐이며 객체는 메시지를 처리하기 위한 방법을 자율적으로 선택할 수 있다. 외부 객체는 메시지에 관해서만 볼 수 있고 객체 내부는 볼 수 없기 때문에 자연스럽게 객체의 외부와 내부가 분리된다.

메서드

메시지 수신을 처리하기 위해 내부적으로 선택하는 방법을 메서드라 한다.

다형성

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것

무엇이 실행될 지는 명시했지만 어떻게 실행할 것인지는 수신자가 결정한다.

다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것

송신자의 관점에서 다형성은 수신자들을 구분할 필요없다. 저 마다 방법이 다를지라도 다 동일한 책임을 수행하기 때문이다.

더 나아가 수신자가 무엇인지 관심도 없다. 역할만 알면된다.(대체 가능성)

따라서 유연하고 재사용성이 높아진다.

송신자-수신자 사이 객체 타입에 대한 결합도를 메시지에 대한 결합도를 낮춤으로써 달성한다.

유연하고 확장 가능하고 재사용성이 높은 협력의 의미

메시지 송신자는 수신자가 메시지를 이해할 수 있다는 사실만 알고 있는 상태에서 협력에 참여한다.

매우 작은 정보만 알고 있더라도 상호 협력이 된다는 것은 설계의 품질에 큰 영향을 미친다.

첫째, 협력이 유연해진다. 수신자가 대체 되더라도 상관이 없고, 송신자는 변경 사실을 알 수 조차 없다.

둘째, 협력이 수행되는 방식을 확장할 수 있다. 송신자에게 아무런 영향 없이 수신자를 교체할 수 있기 때문에 세부 수행 방식을 쉽게 수정할 수 있다.

셋째, 협력이 수행되는 방식을 재사용할 수 있다. 수신자가 교체가 가능하기 때문에 문맥에 맞게 재사용할 수 있다.

송신자와 수신자를 약하게 연결하는 메시지

메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다.

송신자의 관점에서 송신자는 메시지만 바라본다. 수신자의 정확한 타입을 모르더라도 상관없다. 단지 잘 처리해 줄 것이라는 사실만 알면 그만이다.

수신자는 메시지를 처리할 방법을 자유롭게 선택하며, 구체적인 방법은 송신자에게 노출하지 안는다.

송신자와 수신자 사이 약하게 연결하는 메시지는 낮은 결합도를 보장한다.

이에 따라 유연하고, 대체가능하며, 재사용 가능하며, 확장까지 가능하다.

코드

import java.util.*;
//마구간 정하기(결정알고리즘)
/*
5 3
1 2 8 4 9
*/
class 마구간정하기_ {

	private int count(int[] arr, int mid) {
		System.out.println("======"+mid+"======");
		int cnt = 1; // 맨 처음을 당연히 배치하니 1을 둔다.
		int position = arr[0];
		
		System.out.print(position+",");
		for(int i = 1 ; i < arr.length ; i++){
			if(arr[i]-position >= mid ) {
				System.out.print(arr[i]+",");
				cnt++;
				position = arr[i];
			}
		}
		System.out.println();
		
		return cnt;
	}

	public static void main(String[] args){
		
		마구간정하기_ T = new 마구간정하기_();
		int[] arr = new Random().ints(1, 30)
				                .distinct()
				                .limit(10)
				                .sorted()
				                .toArray();
		int c = 5;
		
		System.out.println(Arrays.toString(arr));
		int answer = 0;
		int lt = 1; // 주의할 것 arr[0]로 하면 답이 안 나올 수 있음
		int rt = arr[arr.length-1];
		
		while(lt<=rt) {
			int mid = (lt+rt)/2;
			if(T.count(arr, mid) >= c ) {
				//가능하니 거리를 넓여본다.
				answer = mid;
				lt = mid+1;
			}else {
				//불가능하니 거리를 좁혀본다.
				rt = mid-1;
			}
			
			
		}
		System.out.println(c+" 배치 가능한 적절한 거리 = "+answer);
		
	}
}

결과

[1, 5, 7, 11, 15, 18, 19, 23, 28, 29]
======15======
1,18,
======7======
1,11,18,28,
======3======
1,5,11,15,18,23,28,
======5======
1,7,15,23,28,
======6======
1,7,15,23,29,
5 배치 가능한 적절한 거리 = 6

결정알고리즘은 기본이 이진 검색이다. 따라서 정렬이 필수

역할

책임의 집합이 의미하는 것

어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다.

역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소다.

재사용 관점을 중심 예시

김 의사가 진료를 하다, 박 의사와 교대를 해도 의사 역할 수행에는 문제가 없다.

즉, 역할 관점에서는 변화된 것이 하나도 없다.(인터페이스라 생각해보자)

역할이 답이다

역할을 사용하면 하나의 협력으로 추상화할 수 있다.

역할은 협력 내에서 다른 객체로 대체할 수 있다

단, 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정 된다.

메시지는 책임을 의미한다.

동일한 역할을 수행한다는 것은 협력 내에서 동일한 책임의 집합을 수행한다는 것이다.

이 부분은 객체지향에서 매우 중요한 개념이다.

역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있다.

다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.

역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(resuability)을 뒷받침하는 핵심 개념이다.

협력의 추상화

역할의 큰 가치는 협력을 추상화할 수 있다는 것이다.

협력의 개수를 줄여 보다 추상적인 역할로 단순화해 이해하기 쉬워진다.

협력의 추상화는 근본적으로 역할의 대체 가능성에서 비롯된다.

대체 가능성

객체가 역할에 주어진 책임 이외에 다른 책임을 수행할 수도 있다.

증인 역할에 모자장수는 추가 책임으로 모자 판매를

요리사도 추가 책임으로 요리를 한다.

객체는 역할이 암시하는 책임보다 더 많은 책임을 가질 수 있다.

따라서 대부분의 경우 객체의 타입과 역할 사이에는 일반화/특수화(추상화/구체화) 관계가 성립한다.

역할의 대체 가능성은 행위 호환성을 의미한다.

행위 호환성은 동일한 책임의 수행을 의미한다.

객체의 모양을 결정하는 협력

흔한 오류

데이터를 저장하기 위해 객체가 존재한다는 선입견

데이터는 객체가 행동(책임)을 수행하는 데 필요한 재료일 뿐이다.

객체지향이 클래스와 클래스 간의 관계를 표현하는 정적인 측면에 중점을 둔다는 오류

중요한 것은 협력에 참여하는 동적인 객체이다.

클래스는 단지 객체를 표현하고 생성하기 위한 프로그래밍 매커니즘이다.(실제로 클래스가 없는 객체지향 언어 자바스크립트)

데이터나 클래스 중심으로 애플리케이션을 설계하는 오류

협력이라는 문맥을 고려하지 않고 각 객체를 독립적으로 보면 안된다.

협력을 따라 흐르는 객체의 책임

협력이라는 문맥 속에서 객체가 수행하게 될 책임(행동)결정

이후 필요한 데이터를 고민

데이터와 행동이 결정된 후 클래스 구현 방법 결정(책임 할당)

클래스와 데이터는 협력과 책임의 집합이 결정된 후 고려

객체지향 설계 기법

역할, 책임, 협력의 관점에서 애플리케이션 설계하는 유용한 세 가지 기법

책임 주도 설계(Responseibility-Driven Design) 방법

협력에 필요한 책임들을 식별, 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션 설계

디자인 패턴(Design Pattern)

전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음

특정 문제를 해결하기 위해 이미 식별해 놓은 역할, 책임, 협력의 모음

베스트 프렉티스

테스트 주도 개발(Test-Driven Development)

테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식

책임-주도 설계

객체지향 시스템은 역할과 책임을 수행하는 자율적인 객체들의 공동체다.

레베카 워프스브록-책임주도설계 방법을 말한다.

시스템의 기능은 더 작은 규모의 책임으로 분할

각 책임은 책임을 수행할 적절한 객체에게 할당

이제 객체가 책임을 수행하는 도중 스스로 처리 못할 시 적절한 객체를 찾아 필요한 작업 요청(협력)

디자인 패턴

책임 주도 설계는 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차를 제시한다.

반면 디자인 패턴은 책임-주도 설계의 결과를 표현한다.

모범이 되는 설계

앨리스터 코오번에 따르면 효과적으로 일하는 사람들의 한 가지 특징은 아무것도 없는 상태에서 작업을 시작하지 않고 이전의 훌륭한 결과물을 모방하고 약간의 수정을 거쳐 원하는 결과물을 만들어 낸다는 것이다.

패턴은 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험이다.

디자인 패턴은 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍으로 정의된다.

해결하려고하는 문제가 무엇인지 서술하고, 패턴을 적용할 수 있는 상황과 없는 상황을 함께 설명한다.

패턴은 반복해서 일어나는 특정한 상황에서 어떤 설계가 왜(why) 더 효과적인지에 대한 이유를 설명한다.

테스트-주도 개발

애자일 방법론의 한 종류인 XP의 기본 프랙티스로 소개되며 주목받음

기본 흐름은 실패하는 테스트를 작성하거, 테스트를 통과하는 가장 간단한 코드를 작성한 후 (이 과정에서 중복은 허용된다) 리팩터링을 통해 중복을 제거하는 것이다.

테스트-주도 개발을 통해 '작동하는 깔끔한 코드'를 얻을 수 있다.

테스트 주고 개발이 응집도 높고 결합도 낮은 클래스로 구성된 시스템을 개발할 수 있게 하는 최상의 프랙티스이지만 객체지향 초보에게는 테스트를 어떤 식으로 작성해야하는지 결정하는데 어렵다.

테스트-주도 개발은 다양한 설계 경험과 패턴에 대한 지식이 없는 사람들의 경우에는 온전한 혜택을 누리기가 어렵다.

객체지향에 대한 깊이 있는 지식을 요구한다.

See the Pen Untitled by rkwhr0010 (@rkwhr0010) on CodePen.

객체지향에 갓입문한 사람들의 가장 흔한 실수는 협력이라는 문맥을 고려하지 않은 채 객체가 가져야할 상태와 행동부터 고민하기 시작한다는 것

중요한 것은 개별 객체가 아니라 객체들 사이에 이뤄지는 협력이다.

객체지향 설계의 품질을 결정하는 것은 개별 객체의 품질이 아닌 객체들 간 협력의 품질이다.

협력은 행동으로만 이뤄진다.

객체들을 따로따로 봤을 때 이상하더라도 객체들 간 적극적인 상호작용이 중요하다.

어떤 협력에 참여하나가 객체에 필요한 행동을 결정

필요한 행동이 객체의 상태를 결정한다.

협력

요청하고 응답하며 협력하는 사람들

일반적으로 혼자만의 힘으로는 해결하기 어려운 것이 많다.

이것이 협력의 중요성

협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다.

앨리스 이야기 예시

재판 속의 협력

요청과 응답의 관점에서 왕이 모자 장수로부터 증언을 듣는 과정

• 누군가가 왕에게 재판을 요청함으로씨 재판이 시작된다.
• 왕이 하안 토끼에게 증인을 부를 것을 요청한다.
• 왕의 요청을 받은 토끼는 모자 장수에게 증인석으로 입장할 것을 요청한다.
• 모자 장수는 증인석에 입장함으로써 토끼의 요청에 응답한다.
• 모자 장수의 입장은 왕이 토끼에게 요청했던 증인 호출에 대한 응답이기도 하다.
• 이제 왕은 모자 장수에게 증언할 것을 요청한다.
• 모자 장수는 자신이 알고 있는 내용을 증언함으로써 왕의 요청에 응답한다.

어떤 등장인물들이 특정한 요청을 받아들일 수 있는 이유는 그 요청에 대해 적절한 방식으로 응답하는 데 필요한 지식과 행동 방식을 가지고 있기 때문이다.

요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.

책임

객체가 받은 요청에 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다.

어떤 대상에 대한 요청은 그 대상이 요청을 처리할 책임이 있음을 암시하는 것

책임의 분류

책임은 객체에 의해 정의되는 응집도 있는 행위의 집합

객체의 책임은 객체가 무엇을 알고 있는가(knowing)와 무엇을 할 수 있는가(doing) 두 가지로 분류된다.

크레이그 라만의 분류법

하는 것

• 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
• 다른 객체의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

아는 것

• 개인적인 정보에 관해 아는 것
• 관련된 객체에 관해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소

적절한 객체에게 적절한 책임을 할당, 책임이 불분명한 객체는 안된다.

외부에서 접근 가능한 공용 서비스의 관점에서 책임

책임은 객체의 외부에 제공해 줄 수 있는 정보(아는 것)

외부에 제공해 줄 수 있는 서비스(하는 것) 의 목록이다.

따라서 책임은 객체의 공용 인터페이스를 구성한다.

책임과 메시지

객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것을 메시지 전송이라한다.

메시지는 객체 간 협력을 위한 유일한 방법이다.

책임은 협력이라는 문맥 속에서 한 쪽 객체 관점에서 무엇을 할 수 있는지를 나열하는 것이라면 메시지는 협력에 참여하는 두 객체 사이의 관계를 강조한 것이다.

책임과 메시지 수준이 같지는 않다

책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것이다.

따라서 책임을 결정한 후 실제로 협력을 정제하면서 이를 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는 것이 일반적이다.

See the Pen Untitled by rkwhr0010 (@rkwhr0010) on CodePen.

그리드가 따로 존재하고 거기서 명확히 어떤 행이 중복인지 알려주는 코드,

단순히 중복만 판단하는 것은 더 간단하다.

어떤 행이 중복인지 알아야하는 이유는 해당 그리드 행으로 포커스를 가도록 처리하는 경우가 많기 때문

다음에는 이 코드를 함수화.

코드

import java.util.*;
//원래 키순으로 정렬된 배열에서 한 친구가 자리를 바궜다.
//그래서 배열이 뒤틀어져 있다. 
// 이 상황에서 자리를 바꾼 친구 두 친구 번호를 찾기
class 장난꾸러기_ {	
	public static void main(String[] args){
		int[] arr=new int[] {120 ,125, 152, 130, 135, 135, 143, 127, 160};
		ArrayList<Integer> answer=new ArrayList<>();
		int[] arr2 = new int[arr.length];
		
		for(int i=0;i<arr.length;i++) {
			arr2[i] = arr[i];
		}
		for(int i=0;i<arr.length;i++) {
			for(int j=i+1;j<arr.length;j++) {
				if(arr[i]>arr[j]) {
					int tmp = arr[i];
					arr[i] = arr[j];
					arr[j] = tmp;
				}
			}
		}
		for(int i=0;i<arr.length;i++) {
			if(arr[i]!=arr2[i]) answer.add(i+1);
		}
		
		System.out.println(answer);
	}
}

결과

[3, 8]

타입의 계층

트럼프 계층

트럼프는 트럼프 인간을 포괄하는 좀 더 일반적인 개념이다.

트럼프 인간은 트럼프보다 좀 더 특화된 행동을 하는 특수한 개념이다.

이 두 개념 사이의 관계를  일반화/특수화(generalization/specialization)관계라고 한다.

부분 집합

일반화/특수화 관계

일반적이라는 말은 더 포괄적이라는 의미를 내포한다.

특수하다는 것은 일반적인 개념보다 범위가 더 좁다는 것을 의미한다.

객체지향에서는 행동이 중요하다고 했다.

내부의 상태가 더 일반적인지 특수한지가 중요하지 않다.

일반화/특수화 개념을 대입하면 더 일반적인 행동을 하느냐 더 특수한 행동을 하느냐가 될 것이다.

즉, 객체의 일반화/특수화 관계에 있어서도 중요한 것은 객체가 내부에 보관한 데이터가 아니라 객체가 외부에 제공하는 행동이다.

그렇다면 행동의 관점에서 일반적 타입과 특수한 타입은 무엇일까?

일반적 타입이란 특수한 타입이 가진 모든 행동들 중에서 일부 행동만을 가지는 타입이다.

특수한 타입이란 일반적인 타입이 가진 모든 타입을 포함하지만 거기에 더해 자신만의 행동을 추가하는 타입을 가리킨다.

따라서 일반적인 타입은 툭수한 타입보다 더 적은 수의 행동을 가지고

특수한 타입은 일반적인 타입 행동을 포함하며 보다 더 많은 수의 행동을 가진다.

여기서 주의할 점은 타입의 내연을 의미하는 행동의 가짓수와 외연을 의미하는 집합의 크기는 서로 반대라는 사실이다.

일반화/특수화 관계에서 일반적인 타입은 특수한 타입보다 더 적은 수의 행동을 가지지만 더 큰 크기의 외연 집합을 가진다. 특수한 타입은 일반적인 타입보다 더 많은 수의 행동을 가지지만 더 적은 크기의 외연 집합을 가진다.

슈퍼타입과 서브타입

일반화/특수화 관계를 타입으로 바꾼 것

일반적인 타입을 슈퍼타입(Supertype), 특수한 타입을 서브타입(Subtype)이라 한다.

역시나 슈퍼타입과 서브타입에서 중요한 것은 두 타입 간의 관계가 행동에 의해 결정된다는 것이다.

어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행위적 호환성을 만족시켜야 한다.

서브타입은 슈퍼타입을 대체할 수 있어야 한다.

일반화는 추상화를 위한 도구다

추상화 두 번째 원칙, 중요한 부분 강조를 위해 불필요한 세부 사항을 제거해 단순화

일반화/특수화 계층은 두 번째 원칙의 예시가 된다.

거의 대부분의 경우에 분류와 일반화/특수화 기법을 동시에 적용하게 된다.

정적 모델

타입의 목적

인간의 인지 능력으로 시간에 따라 동적으로 변하는 객체의 복잡성을 극복하기가 너무 어렵기 때문에 타입을 사용한다.

앨리스가 어떤 음식을 먹을 때 마다 키와 팔,다리 길이가 시시각각 달라진다. 하지만 모든 경우에 앨리스는 단지 앨리스일 뿐이다.

앨리스라고 하는 객체의 상태는 변하지만 앨리스를 다른 객체와 구별할 수 있는 식별성은 동일하게 유지된다.

타입은 시간에 따라 동적으로 변하는 앨리스의 상태를 시간과 무관한 정적인 모습으로 다룰 수 있게 해준다.

아래 그림과 같이 앨리스의 상태에 복잡성을 부과하는 시간이라는 요소를 제거함으로써 시간에 독립적인 정적인 모습으로 앨리스를 생각할 수 있게 해준다.

그래서 결국 타입은 추상화다

어떤 시점에 앨리스에 관해 생각할 때 불필요한 시간이라는 요소와 상태 변화라는 요소를 제거하고 철저하게 정적인 관점에서 앨리스의 모습을 묘사하는 것을 가능하게 해준다.

타입은 추상화다. 타입을 이용하면 객체의 동적인 특성을 추상화할 수 있다. 결국 타입은 시간에 따른 객체의 상태 변경이라는 복잡성을 단순화할 수 있는 효과적인 방법인 것이다.

동적 모델과 정적 모델

객체를 생각할 때 두 가지 모델

첫째, 객체가 특정 시점에 구체적으로 어떤 상태를 가지느냐.

이를 객체의 스냅샷(snapshot)이라고 한다.

UML에서 스냅샷은 객체 다이어그램이라고도 불린다.

스냅샷처럼 실제로 객체가 살아 움직이는 동안 상태가 어떻게 변하고 어떻게 행동하는지를 포착하는 것을 동적 모델(dynamic model)이라고 한다.

둘째, 객체가 가질 수 있는 모든 상태와 모든 행동을 시간에 독립적으로 표현하는 것이다.

이를 타입 모델(type diagram)이라고 한다.

이 모델은 동적으로 변하는 객체의 상태가 아니라 객체가 속한 타입의 정적인 모습을 표현하기 때문에 정적모델(static model)이라 한다.

클래스를 만드는 행위가 정적인 모델링

디버그를 위해 상태 변경을 추적하는 것은 동적 모델링을 탐험하는 것

클래스

객체지향 프로그래밍 언어에서 정적인 모델은 클래스를 이용해 구현된다.

따라서 타입을 구현하는 가장 보편적인 방법은 클래스를 이용하는 것이다.

타입을 구현한다고 표현한 것은 클래스와 타입은 동일한 것이 아니라는 뜻이다.

타입은 객체를 분류하기 위해 사용하는 개념이다.

반면 클래스는 단지 타입을 구현할 수 있는 여러 구현 메커니즘 중 하나일 뿐이다.

실제로 자바스크립트와 같은 프로토타입 기반 언어에는 클래스가 존재하지 않는다.

객체를 분류하는 기준은 타입이며, 타입을 나누는 기준은 객체가 수행하는 행동이다.

객체지향에서 중요한 것은 동적으로 변하는 객체의 상태와 상태를 변경하는 행위다.

클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘이다.

코드

import java.util.*;
//Least Recently Used
class LRU {	
	public static void main(String[] args){
		int[] arr = new Random().ints(20, 1, 11)
		            .toArray();
		int size = 5; //캐시 사이즈
		int[] cache = new int[size];
		
		System.out.println(Arrays.toString(arr));
		//전체 작업을 순회
		for(int i=0;i< arr.length;i++) {
			int tmpIndex = -1;
			int value = arr[i];
			//캐시에 이미 존재하는지
			for(int j=0;j<cache.length;j++) {
				if(cache[j] == value) {
					tmpIndex=j;
					break;
				}
			}
			//캐시에 존재할 경우 그 자리를 제외하고 뒤로 밀기
			int j = tmpIndex != -1 ? tmpIndex : cache.length-1;
			for(; 0<j;j--) {
				cache[j] = cache[j-1];
			}
			cache[0] = arr[i];
			System.out.println(Arrays.toString(cache)+"입력값 =" + arr[i]);
		}
	}
}

결과

[4, 2, 3, 8, 4, 9, 8, 5, 8, 10, 3, 10, 9, 7, 6, 5, 9, 3, 10, 8]
[4, 0, 0, 0, 0]입력값 =4
[2, 4, 0, 0, 0]입력값 =2
[3, 2, 4, 0, 0]입력값 =3
[8, 3, 2, 4, 0]입력값 =8
[4, 8, 3, 2, 0]입력값 =4
[9, 4, 8, 3, 2]입력값 =9
[8, 9, 4, 3, 2]입력값 =8
[5, 8, 9, 4, 3]입력값 =5
[8, 5, 9, 4, 3]입력값 =8
[10, 8, 5, 9, 4]입력값 =10
[3, 10, 8, 5, 9]입력값 =3
[10, 3, 8, 5, 9]입력값 =10
[9, 10, 3, 8, 5]입력값 =9
[7, 9, 10, 3, 8]입력값 =7
[6, 7, 9, 10, 3]입력값 =6
[5, 6, 7, 9, 10]입력값 =5
[9, 5, 6, 7, 10]입력값 =9
[3, 9, 5, 6, 7]입력값 =3
[10, 3, 9, 5, 6]입력값 =10
[8, 10, 3, 9, 5]입력값 =8

최근 사용한 데이터를 캐시에 저장하는 등의 수정이 자주 발생한다,  배열보단 LinkedList 같은 자료구조가 좋다.

개념의 세 가지 관점

일반적으로 객체의 분류 장치로서 개념을 이야기할 때는 아래의 세 가지 관점을 함께 언급한다[Martin 1998, Larman 2004]

• 심볼 : 개념을 가리키는 간략한 이름이나 명칭
• 내연 : 개념의 완전한 정의를 나타내며 내연의 의미를 이용해 객체가 속하는지 여부를 확인할 수 있다.
• 외연 : 개념에 속하는 모든 객체의 집합

심볼은 예시에서 '트럼트' '토끼'

내연 예시 몸이 납작하고 두 손과 두 발이 네모난 몸 모서리에 달려 있다는 트럼프 설명이 예시다.

외연 예시 실제 개념에 일치해 개념에 속한 객체들

개념이 심볼, 내연, 외연으로 구성돼 있다는 사실보다는 개념을 이용해 객체를 분류할 수 있다는 사실이 더 중요하다.

객체지향 패러다임이 복잡성을 극복하는 데 사용하는 가장 기본적인 인지 수단이기 때문이다.

객체지향의 세계에서 Class를 사용한다는 사실을 감안하면

분류(Classification)라는 개념이 얼마나 중요한지 실감할 수 있다.

객체를 분류하기 위한 틀

분류란 객체에 특정한 개념을 적용하는 작업이다. 객체에 특정한 개념을 적용하기로 결심했을 때 우리는 그 객체를 특정한 집합의 멤버로 분류하고 있는 것이다.

분류는 객체지향의 가장 중요한 개념 중 하나다.

분류가 적절치 않다면 애플리케이션 유지보수가 어렵고 변화에 쉽게 대처하지 못한다.

분류는 추상화를 위한 도구다

추상화 두 가지 차원

첫 번째, 구체적인 사물 간의 공통점을 취하고 차이점을 버리는 일반화를 통한 단순화

두 번째, 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거해 단순화

개념을 통한 객체 분류는 추상화의 두 가지 차원을 모두 사용한다.

개념은 객체들의 복잡성을 극복하기 위한 추상화 도구다.

추상화를 사용함으로써 우리는 극도로 복잡한 이 세상을 그나마 제어 가능한 수준으로 단순화할 수 있는 것이다.

타입

타입은 개념이다

개념을 대체할 수 있는 용어를 수학에서 차용, 그것은 바로 타입(Type)

타입은 개념과 동일하다. 따라서 타입이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미한다. 어떤 객체에 타입을 적용할 수 있을 때 그 객체를 타입의 인스턴스라고 한다. 타입의 인스턴스는 타입을 구성하는 외연인 객체 집합의 일원이 된다.

데이터 타입

실제로 컴퓨터는 01로만 이루어져 있다. 이 비트배열이 숫자인지 문자인지 구분이 안간다.

그래서 메모리 안에 데이터에 특정한 의미를 부여하기 시작했다. 그것이 타입 시스템(Type System)이다.

타입 시스템의 목적은 메모리 안의 모든 데이터가 비트열로 보임으로써 야기되는 혼란을 방지하는 것이다.

타입에 관련된 두 가지 중요한 사실

첫째, 타입은 데이터가 어떻게 사용되느냐에 관한 것이다.

숫자형 데이터는 연산을 할 수 있다.

둘째, 타입에 속한 데이터를 메모리에 어떻게 표현하는지는 외부로부터 철저하게 감춰진다.

데이터 타입의 표현은 연산 작업을 수행하기에 가장 효과적인 형태가 선택되며, 개발자는 해당 데이터 타입의 표현 방식을 몰라도 데이터를 사용하는 데 지장이 없다.

단지 데이터 타입을 사용하기 위해 연산자만 알고 있으면 된다.

숫자형 데이터에 산술 연산자를 알고 있다면 메모리 내부에 숫자가 어떤 방식으로 저장되는지를 모르더라도 숫자형 데이터를 사용할 수 있다.

이 책에서는 프로그래밍 언어 관점에서 데이터 타입을 다음과 같이 정의한다.

데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.

객체와 타입

객체지향 프로그램에서 객체를 일종의 데이터처럼 사용한다.

객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다.

객체는 행위에 따라 변할 수 있는 상태를 가지고 있다는 사실을 기억하라

그렇다면 객체는 데이터인가? 그렇지 않다.

다시 한번 강조하지만 객체에서 중요한 것은 객체의 행동이다.

상태는 행동의 결과로 초래된 부수효과를 쉽게 표현하기 위해 도입한 추상적인 개념일 뿐이다.

객체가 협력을 위해 어떤 책임을 지녀야 하는지 결정하는 것이 객체지향 설계의 핵심이다.

협력은 객체간 행동으로만 이루어진다.

데이터 타입 두 가지 조언을 객체의 타입에 적용

첫째, 어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동이다.

어떤 객체들이 동일한 행동을 수행할 수 있다면 그 객체들은 동일한 타입으로 분류될 수 있다.

둘째, 객체의 내부적인 표현은 외부로부터 철저하게 감춰진다. 객체의 행동을 가장 효과적으로 수행할 수만 있다면 객체 내부의 상태를 어떤 방식으로 표현하더라도 무방하다.

행동이 우선이다

객체의 내부 표현 방식이 다르더라도 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다.

결과적으로 동일한 책임을 수행하는 일련의 객체는 동일한 타입에 속한다고 말할 수 있다.

객체가 어떤 데이터를 보유하고 있는지는 타입을 결정하는 데 아무런 영향도 미치지 않는다.(인터페이스, 다형성)

위 원칙을 다르게 해석해보자

동일한 타입에 속한 객체는 내부의 데이터 표현 방식이 다르더라도 동일한 메시지를 수신하고 이를 처리할 수 있다. 다만 내부의 표현 방식이 다르기 때문에 동일한 메시지를 처리하는 방식은 서로 다를 수밖에 없다.

이것은 다형성에 의미를 부여한다.

다형성은 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 뜻한다.

데이터의 내부 표현 방식과 무관하게 행동만이 고려 대상이라는 사실은 외부에 데이터를 감춰야 한다는 것을 의미한다.

좋은 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다.

이 원칙을 흔히 캡슐화라고 한다.

행동에 따라 객체를 분류하기 위해서는 객체가 내부적으로 관리해야 하는 데이터가 아니라 객체가 외부에 제공해야 하는 행동을 먼저 생각해야 한다. 이를 위해서는 객체가 외부에 제공해야 하는 책임을 먼저 결정하고 그 책임을 수행하는 데 적합한 데이터를 나중에 결정한 후, 데이터를 책임을 수행하는 데 필요한 외부 인터페이스 뒤로 캡슐화해야 한다.

책임-주도 설계(Responsibility-Driven Design)는 데이터-주도 설계(Data-Driven Design)방법의 단점을 개선하기 위해 고안됐다.

객체를 결정하는 것은 행동이다. 데이터는 단지 행동을 따를 뿐이다. 이것이 객체를 객체답게 만드는 가장 핵심적인 원칙이다.