[JAVA 객체지향 디자인 패턴] 1장 : 객체지향 모델링

1.1 모델링

소프트웨어 개발에서 모델의 역할

• 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토
• 현재의 시스템 또는 앞으로 개발할 시스템의 원하는 모습을 가시화
• 시스템의 구조와 행위를 명세할 수 있으며 시스템을 구축하는 틀을 제공

모델은 추상화에 기반을 둔다.

특정 관점에서 관련이 있는 점은 부각시키고 관련 없는 면은 무시한다.

ex) 대학교 학사 지원 업무

-> 학생의 머리카락 수, 머리 색깔은 학사 지원과 전혀 무관하기 때문에 관심있는 영역에서 제외 (추상화에서 제외)

-> 학생의 "학번, 이름, 수강과목"은 학사 지원 필수적이므로 관심영역에 포함시킨다.

 

사람의 모든 속성을 가져가는 것이 아닌 관심있는 영역의 필요한 속성만 가지고 가는 것 (추상화)

1.2 UML

모델링 언어 : 원하는 시스템을 모델로 표현해주는 언어 ex) UML

• UML은 요구분석, 시스템 설계, 구현 등의 시스템 개발 과정에서 개발자 사이의 의사소통이 원활하게 이루어지도록 표준화하는 통합 모델링 언어이다.

UML은 시스템의 "구조"와 "동작"을 표현하는 13개 다이어그램을 제공한다.

이를 통해 다양한 관점에서 시스템을 모델링 할 수 있다.

 

1.3 클래스 다이어그램

시간에 따라 변하지 않는 시스템의 "정적"인 면을 보여주는 UML 구조 다이어그램

 

클래스 다이어그램은 "시스템을 구성하는 클래스와 그들 사이의 관계를 보여준다"

주요 구성 요소 : 클래스 와 관계

 

클래스

• 동일한 속성과 행위를 수행하는 객체의 집합 

철수와 미미는 각자의 나이를 물어볼 수 있으므로 실체가 있는 객체이다. 클래스는 이러한 객체를 만들기 위한 설계도이다.

 

=> 클래스는 공통의 `속성`과 `책임`을 갖는 객체들의 집합이자 실제 객체를 생성하는 설계도이다.

 

UML로 표현한 클래스

https://blog.naver.com/1ilsang/221104669002

가장 위는 클래스 이름을 중간 부분에는 클래스의 특징을 나타내는 속성을 마지막 부분에는 클래스가 수행하는 책임, 즉 연산을 기술한다.

 

---

+ : public

- : private

# : protected

~ : package

---

기호로 접근 제어자를 나타낸다.

 

1.3.2 관계

클래스 하나로만 시스템을 구성할 순 없다.

 

객체지향 시스템에서는 여러 개의 클래스가 서로 관계를 맺어 기능을 수행한다.

이러한 클래스 간 "관계"를 표현할 수 있다.

https://kyoun.tistory.com/100

관계	설명
연관 관계 (association)	클래스들이 개념상 서로 연결되었음을 나타냄. 실선이나 화살표로 표시하며 보통 한 클래스가 다른 클래스에 기능을 제공할 때 사용.
일반화 관계 (generalization)	객체 지향의 상속 관계를 나타냄. 한 클래스가 다른 클래스를 포함하는 IS-A관계 시 사용.
집합 관계 (composition,  aggregation)	클래스들 상의 전체 또는 부분 같은 관계를 나타냄
의존 관계 (dependency)	연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때를 나타냄. 둘의 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같은, 매우 짧은 시간만 유지된다는 점이다.
실체화 관계 (realization)	책임들의 집합인 인터페이스와 이 책임을 구현한 구현 클래스 사이의 관계를 나타낸다.

다중성 표기

https://blog.naver.com/1ilsang/221104669002

선에 아무런 숫자가 없으면 연관관계가 1대1 관계인 것이다.

교수와 학생은 보통 한명의 교수에 여러명의 학생이 연관되므로 1대다 관계이다. 이를 다중성 표기할 수 있다.

 

위 다이어그램은 Student클래스와 Course 클래스가 "수강하다"라는 연관관계로 이어져있다.

 

여기서 학생은 과목을 사용하지만 과목은 학생을 사용하지 않는다. (학생은 과목을 알지만 과목은 학생을 몰라도 된다)

--> 단방향 연관관계 

 

학생이 자신이 수강하는 과목을 알고 과목도 자신을 수강하는 학생을 안다면 -> 양방향 연관관계

 

1..* 이므로 학생은 반드시 1개 이상의 과목을 수강해야 한다.

 

위 그림의 문제는 한 과목이 하나의 학생만 수강할 수 있다는 점이다. 이를 일반적인 수강 관계로 개선하려면 다중성을 수정해야만 한다.

[Student]1..*-------------------1..*[Course]

 

-> 양방향 연관관계

다 대 다 연관 관계는 자연스레 양방향 연관관계가 된다.

이를 해결하기 위해 "연관 클래스"를 알아야 한다.

 

두 개의 객체가 서로 연관되어 나타나야 하는 정보가 있다. 예를 들어 성적 정보이다.

이는 "학생"이나 "과목"에만 속하는 것이 아니라서 둘 중 어디에도 둘 수 없다. (두 클래스 객체가 존재해야만 의미 있는 정보임)

 

즉, 성적 정보는 클래스의 속성이 아닌 '수강하다'라는 연관관계의 속성으로 다뤄져야한다!!

 

연관 관계가 있는 두 클래스 사이에 위치한다.

 

연관 클래스

연관 클래스는 연관 관계에 추가할 속성이나 행위가 있을 때 사용한다.

 

우리는 성적 클래스에 추가적으로 필요한 "과목 개설년도, 성적 정보"를 포함시킬 수 있다.

 

이때 학생은 여러 과목에 대한 성적을 받을 수 있고 과목 또한 여러 개의 성적을 만들어 내야 하므로

일 대 다 (성적) 다 대 일 관계가 성립된다.

 

연관 클래스 -> 일반 클래스로 변환

 

일반화 관계

일반화 관계는 상속과 같다. 이 관계는 'is a kind of' 관계로 나타낼 수 있다.

https://blog.naver.com/1ilsang/221104669002

 

가전 제품은 세탁기, TV, 식기세척기의 "공통속성, 연산"을 제공하는 틀이다.

 

추상 메서드는 클래스 다이어그램에서 기울임체로 표현한다.

 

집합 관계

집합 관계는 UML 연관 관계의 특별 경우로 전체와 부분의 관계를 명확하게 명시할 때 사용한다.

"집약(aggreagation)과 합성(composition)의 두 종류가 존재한다"

 

집약 관계는 한 객체가 다른 객체를 포함하는 것을 나타내는 것 -> 빈 마름모로 표시
부분을 나타내는 객체를 다른 객체와 공유할 수 있는 경우에 집약 관계로 나타냄. (부분 객체를 객체 생성 시 주입할 때)

// 집약 관계 코드
public class Computer{
  private MainBoard mb;
  private CPU c;
  private Memory m;

  public Computer(MainBoard mb, CPU c, Memory m){
    this.mb = mb;
    this.c = c;
    this.m = m;
  }
}

합성 관계는 부분 객체가 전체 객체에 속할때 나타내는 것으로 -> 채워진 마름모
전체 객체가 사라지면 부분 객체도 사라지는 것을 뜻함. (부분 객체를 객체 안에서 생성할 때)

//합성 관계 코드
public class Computer{
  private MainBoard mb;
  private CPU c;
  private Memory m;

  public Computer(){
    this.mb = new MainBoard();
    this.c = new CPU();
    this.m = new Memory();
  }
}

 

집약 관계와 합성 관계를 구분하려면 전체 객체와 부분 객체의 라이프타임 의존성을 살펴봐야한다.

 

의존 관계

한 클래스가 다른 클래스를 사용하는 경우

• 클래스의 속성에서 참조할 때
• 연산의 인자로 사용될 때
• 메서드 내부의 지역 객체로 참조될 때

앞에서 의존 관계에 대해 "짧은 시간 맺어지는 관계"라고 정의하였다.

 

위 그림에서 사람과 자동차는 오랜 기간 협력 관계를 통해 기능을 수행한다. 따라서 'owns'라는 연관 관계가 성립하게 된다.

public class Car{
  ...
  public void fillGas(GasPump p){
    p.getGas(amount);
  }
}

하지만, GasPump(주유기)는 자동차가 특정 주유소만 가는 것이 아니라 여러 주유소를 이용하므로 매번 달라질 수 있다.

따라서 객체지향에서는 이러한 "주유기"를 인자 또는 지역 객체로 생성해 구현한다.

인터페이스와 실체화 관계

인터페이스란 "책임"이다.

-> 어떤 객체의 "책임"이란 [객체가 해야하는 일]로서 해석할 수 있으며 어떤 경우엔 [객체가 할 수 있는 일]로도 해석할 수 있다.

 

즉, 객체가 외부에 제공하는 서비스나 기능은 객체가 수행하는 책임이다.

 

볼륨을 끄거나 높이거나 줄이거나 같은 책임을 수행하는 것(기능)은 TV 뿐만 아니라 핸드폰, 컴퓨터 등도 가능하다.

 

공통된 책임을 인터페이스를 통해 정의할 수 있다.

인터페이스는 실제 책임을 수행하는 객체가 아니고 실제 수행 객체는 따로 존재한다.

 

UML에서는 이 관계 표현을 '점선'으로 표현한다.

https://blog.naver.com/1ilsang/221104669002

 

일반화 관계는 'is a kind of' 관계' 지만 실체화 관계는 'can do this 관계'이다.