필자의 해석이 포함되어 있습니다!
실제로 책에서 의도한 의미와는 다를 수 가 있습니다
주의 부탁드립니다 !!

1장 : 객체지향 모델링

모델링

모델을 만드는 과정을 모델링이라 한다

이때 모델은 추상화(abstraction)에 바탕을 두고 만든다

추상화는 대상의 모든 면을 상세히 보여주지 않는다,

다시 말해!! 특정 관점에서 불필요한 부분은 무시하고 필요한 부분만을 부각하여 보여준다

UML

Unified Modeling Language

모델링을 하는 언어. 클래스 다이어그램 등이 있다

객체 지향 시스템을 가시화한다

클래스 다이어그램

클래스의 관계들을 보여준다

시간에 따라 변하지 않는 정적인 면을 보여준다

관계

다대다 연관관계

예를들어 Student(학생)와 Course(과목) 클래스가 있다고 할 때, 또 그 둘의 관계가 N:M 다대다 일때

성적 정보는 이 둘 중 어디에 넣을 수 없다

예를들어 철수가 A+을 받았다고 할 때 Student에 넣으면 누가 받았는지를 모르고 Course에 넣으면 어떤 학생이 받았는지를 모른다

이럴 때 중간 매핑테이블과 같은 연관 클래스를 사용하는 것이 좋다

연관 테이블을 통해서 1:N 구조로 바꿀 수 있다

일반화 관계

상속관계이다

아래는 책에 적혀 있는 예이다

• 세탁기 is a kind of 가전제품
• TV is a kind of 가전제품
• 식기세척기 is a kind of 가전제품

이때 가전제품은 부모클래스고 세탁기 등 3종 셋뚜셋뚜는 서브 클래스이다

우리가 친숙히 아는 관계이니 넘어가자!

집합관계

• 합성 Composition

public class Computer {
	private Mainboard mainboard;
	private CPU cpu;
	private Memory memory;
	private PowerSupply powerSupply;

	public Computer(Mainboard mainboard, CPU cpu, Memory memory, PowerSupply powerSupply) {
		this.mainboard = mainboard;
		this.cpu = cpu;
		this.memory = memory;
		this.powerSupply = powerSupply;
	}
}

• 집약 Aggregation

public class Computer {
	private Mainboard mainboard;
	private CPU cpu;
	private Memory memory;
	private PowerSupply powerSupply;

	public Computer(Mainboard mainboard, CPU cpu, Memory memory, PowerSupply powerSupply) {
		this.mainboard = new Mainboard();
		this.cpu = new CPU();
		this.memory = new Memory();
		this.powerSupply = new PowerSupply();
	}
}

• 이떄 집약같은 경우는 객체를 외부에서 주입받은 것이기 때문에 Computer 객체가 소멸한다고 해서 부품 객체들이 소멸되지 않는다 !! 결합이 좀더 느슨하다고 볼 수 있다 !

용어 정리

인스턴스 변수 : 속성 메서드 : 책임 혹은 연산

2장 : 객체지향 원리

추상화

위에서 언급한 정리를 다시 써본당

특정 관점에서 불필요한 부분은 무시하고 필요한 부분만을 부각하여 보여준다!

캡슐화

객체 지향 설계 원리 중 하나이며 외부에 불필요한 정보를 감춘다

좀더 설명하면

정보 은닉을 통해 높은 응집도와 낮은 결합도를 갖도록 한다

정보 은닉(information hiding): 외부에서 알 필요가 없는 정보를 접근하지 못하도록 막는다

응집도(cohesion): 한 클래스의 기능들이 얼마나 밀접하게 관련되어 있는지를 나타냄

• SRP와 관련. 클래스가 하고자 하는 일과 책임들의 관계

결합도(coupling): 어떤 기능을 실행할 때 다른 클래스에 얼마나 의존적인지를 나타낸다

응집도는 높고 결합도는 낮아야 요구사항 변경에 유연하게 대처할 수 있다

일반화과 캡슐화

일반화(상속관계)와 캡슐화의 관계를 보자

본인은 이것을 다형성과 관계가 있다고 보았다

void somethingDoo(Car car) {
  car.move();
}

Car를 구현한 것에는 도요타, 람보르기니 등의 클래스가 있다고 할 때

이것은 구현체 자체를 캡슐화했다고 본다고 책에서 그랬다

코드가 사용하는 곳에서 드러나지 않아서 그런 것일까? 싶다 ..

책에서의 요약
일반화 관계는 자식 클래스를 외부로부터 은닉하는 캡슐화의 일종
본인피셜: 다형성으로 받아들이자 !

일반화 관계와 위임

만일 나만의 Custom Stack 을 만드는데 기능을 다 만들기 힘들어서 기존의 ArrayList를 상속받아 구현하면 문제가 다소 생긴다

• 원치 않는 기능들도 상속된다

기본적으로 일반화 관계는 is a kind of 관계가 성립해야 한다

스택과 리스트의 경우

• Stack is a kind of ArrayList

가 성립하지 않기 떄문에 일반화 관계(상속)로 구현하면 아니 된다.

안티패턴

public class MyStack<String> extends ArrayList<String> {
	public void push(String element) {
		add(element);
	}

	public String pop() {
		return remove(size() - 1);
	}
}

위임을 이용한 리펙터링

public class MyStackByDelegation<String> {

	private ArrayList<String> arList = new ArrayList<String>();

	public void push(String element) {
		arList.add(element);
	}

	public String pop() {
		return arList.remove(arList.size() - 1);
	}

	public boolean isEmpty() {
		return arList.isEmpty();
	}

	public int size() {
		return arList.size();
	}
}

집합론 관점으로 본 일반화 관계

• 이 소주제는 도저히 이해가 안간다…

다형성

Polymorphism 내가 생각하기에 객체지향을 지탱하는 기술 원탑 !

• 서로 다른 객체가 같은 메시지를 받았을 때 각자의 방식으로 동적하는 능력

• 일반화 관계와 함께 자식 클래스를 개별적으로 다룰 필요 없이 한 번에 처리할 수 있게 하는 수단 제공