옵저버패턴이란?

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의한다. 예시로 들어보자면, 신문사 자체는 하나면 되는데 객체가 만들어질 때마다 신문사가 여러 개이면 안된다. 이러한 문제점을 해결하기 위해서 나온 것이 옵저버 패턴이다.

 

SOLID 의 OCP원칙과 DIP원칙을 준수한다.

 

SOLID :: 객체지향 설계 5원칙
>> https://jinn-o.tistory.com/68?category=976564

 

 

 

 

 

옵저버패턴의 대략적 구조

 

 

 

 

 

단점

모든 Observer 들에게 동일한 데이터를 뿌리는 풀 형식에서는 subset of events, 쓸데없는 정보까지 알아야한다는 것

 

 

 

 

 

ObserverPattern 코드보기 (구현 완료)

https://github.com/SMJin/JAVA-DesignPattern/tree/master/ObserverPattern

 

GitHub - SMJin/JAVA-DesignPattern

Contribute to SMJin/JAVA-DesignPattern development by creating an account on GitHub.

github.com

 

시퀀스 다이어그램이란?

 시퀀스 다이어그램은 시계열(시간 순서)로 정렬된 객체 상호작용을 보여준다. 시나리오 기능을 수행하는데 필수적인 객체들 간에 교환되는 일련의 메시지들과 시나리오에 수반되는 객체와 클래스를 표현한다. 시퀀스 다이어그램은 일반적으로 개발 중인 시스템의 논리적 뷰의 유즈 케이스 실현화와 관련된다. 시퀀스 다이어그램은 이벤트 다이어그램, 이벤트 시나리오라고도 부른다. [위키백과]

 

 특정 Use Case에 대한 상세한 흐름이나 심지어는 특정 Use Case의 일부분까지도 보여준다. 시퀀스에서 다른 객체들 간의 호출관계를 보여주고 있고, 다른 객체들로의 다른 호출까지 상세하게 보여줄 수 있다.

시퀀스 다이어그램은 2차원으로 표현되며, 수직은 발생 시간 순서로 메시지/호출 시퀀스를 보여주고 수평은 메시지가 전송되는 객체 인스턴스를 나타내고 있다. 시퀀스 다이어그램은 매우 간단하며, 다이어그램의 상단에 각 클래스의 인스턴스를 박스 안에 놓아 클래스 인스턴스(객체)를 구분한다.

박스 안에 클래스 인스턴스 이름과 클래스 이름을 스페이스/콜론/스페이스 “:”로 분리시킨다. 클래스 인스턴스가 메시지를 또 다른 클래스 인스턴스로 보내면 클래스 인스턴스를 받는 곳을 가리키는 화살표를 긋고, 그 라인 위에 메시지/메소드 이름을 적는다. 중요한 메시지의 경우는 원래의 클래스 인스턴스를 다시 향하도록 점선 화살표를 그릴 수 있다. 점선 위에 리턴 값을 표기한다. 리턴 값을 포함하면 상세한 부분을 읽기 쉬운 장점이 있다. [네이버 지식백과]

 

 

 

시퀀스 다이어그램의 구성요소

 

객체와 생명선(Lifeline)

생명선이 하강할 수록 시간이 경과한다는 의미이다.

 

활성 박스(Activation Box)

객체가 특정한 활동을 하고 있음을 의미한다.

 

메시지(Message)

동기 메시지
(Synchronous message)
응답을 기다리는 일반적인 함수 호출 같은 메시지 (포그라운드)
비동기 메시지
(Async message)
응답을 기다리지 않는 전송객체의 호출만을 표시하는 메시지 (백그라운드)
자체 메시지
(Self message)
자신에게 보내는 메시지
반환 메시지
(Replay/Return message)
호출에 대한 응답을 반환하는 메시지

 

동기 메시지

 

비동기 메시지

 

자체 메시지

 

반환 메시지

 

Guard 가드 (IF문)

 

Fragment 프래그먼트 : 옵션

Option 옵션

 

반복(Loop)

 

대안(Alternative)

 

병렬(Parallel)

 

정리

예제

독서회원이 서가에 있는 책을 대출해간다.

독서회원이 서가에 없는 책을 예약한다.

독서회원이 책을 반납한다.

클래스 다이어그램이란?

서로 다른 Entity들(사람, 제품, 데이터 등)이 어떻게 서로 관계를 맺고 있는지를 표현하는 다이어그램이다. 소프트웨어 공학에서 클래스 다이어그램(class diagram)은 통합 모델링 언어(UML)에서 시스템의 클래스, 클래스의 속성, 동작 방식, 객체 간 관계를 표시함으로써 시스템의 구조를 기술하는 정적 구조 다이어그램의 일종이다. 객체지향형 시스템 설계에서, 시스템의 논리 설계를 위한 클래스들의 존재와 그들의 관계를 도식으로 정리한 것이다. 단일 클래스 다이어그램은 시스템 클래스의 구조를 보여준다.

 

좋은 클래스 다이어그램은, 세세하게 모든 요소들을 다 적기보다 전체적인 구조를 쉽게 이해할 수 있게 목적에 맞게 필요한 부분만을 보여주는 것입니다.

 

 

 

클래스 다이어그램의 구성요소

 

Class 클래스

접근 제한자(Access Modifier), 필드/메서드명, 데이터 타입, 파라미터(parameter), 리턴 타입 등을 표현할 수 있다. 이 때 접근 제한자는 다음과 같다.

접근 제한자
(Access Modifier)
+ public
# protected
- private

 

Interface 인터페이스 (스테레오 타입 << >>)

인터페이스는 스테레오 타입 <<>> 으로 표현되는 것 중 하나이며, 스테레오 타입으로 많이 사용되는 것은 <<interface>>, <<utility>>, <<abstract>>, <<enumeration>> 등이 있다.

추상 클래스/메서드

일반적으로 추상클래스는 이탤릭체로 표기하긴 하지만, 칠판이라던가 이탤릭체가 힘든 상황에서는 스테레오타입 <<>> 이나 대괄호 {} 를 이용해서 표현하기도 한다.

 

클래스와의 관계

출처 : https://www.nextree.co.kr/p6753/

Generalization 일반화 (상속)

 

Realization 실체화 (인터페이스 오버라이딩 구현)

 

Dependency 의존 (클래스 참조)

A references B (as a method parameter or return type)

public class A {
    public void myMethod(B b) {
        b.callMethod();
    }
}

 

Association 연관

A has-a C object (as a member variable)

public class A {
    private C c;
}

대여 클래스가 바로 Association Class 이다.

 

Aggregation 집합 VS Composition 합성

학교와 학생은 집합관계이다. 그 이유는 학생들은 학교에 속하긴 하지만, 학교가 없어진다고 해서 학생들이 사라지지 않기 때문이다. 그러나 학교 내부에 존재하는 화장실은 학교가 철거되면 함께 없어지기 때문에 합성관계이다.

 

 

 

 

예제

시스템을 만들려고 한다. 이 도서관 에서는 독서회원을 가지고 있으며 독서회원은 책을 6권까지 빌릴 수 있는 권한을 가진다. 도서관이 소장하고 있는 책은 빌릴 수 있는 일반도서와 빌릴 수 없는 지정도서 두 종류로 나뉘며 같은 책이 여러 카피 있을 수 있다. 독서회원은 책이 모두 대출되어 없으면 예약을 할 수 있다.

>> 잘 정리 되어있는 참고 문서
https://velog.io/@hanblueblue/UML-UML-%EA%B8%B0%EC%B4%88

UML(통합 모델링 언어) 이란?

간단하게 말하자면, 프로그래머들끼리 코드에 대한 의사소통을 원활하게 하기 위함이 목적이다. 프로그래밍에서 협업은 필수적인 만큼, 서로 짠 코드에 대해서 잘 이해할 필요성이 있다. 그러나 대뜸 코드만을 들이밀면 이해하기 힘든 것이 사실이다. 그런 이유로 나온 것이 바로 UML 이다.

 

 

 

UML 다이어그램의 종류

출처 : https://www.nextree.co.kr/p6753/

총 7개의 구조다이어그램과 7개의 행동 다이어그램이 존재한다.

 

# 구조 다이어그램 알아보기

>> 클래스 다이어그램
https://jinn-o.tistory.com/85

>> 시퀀스 다이어그램
https://jinn-o.tistory.com/86
 

결론부터 말하자면,

Strategy Pattern (스트래티지 패턴) 에서는 알고리즘 군을 정의 하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 이를 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

 

>>자세한 내용 알아보기

https://github.com/SMJin/JAVA-DesignPattern/tree/master/StrategyPattern

 

GitHub - SMJin/JAVA-DesignPattern

Contribute to SMJin/JAVA-DesignPattern development by creating an account on GitHub.

github.com

 

프로그래밍에서 객체란? 필요한 역할에 대한 책임을 지는 것이 객체이다.

 

일반적으로 좋은 코드란 높은 응집도(cohesion)를 가지며 낮은 결합도(coupling)를 유지하는 코드를 말한다.

먼저 응집도란, 하나의 클래스 내부의 요소들이 서로 잘 관련되어 있는 정도를 말한다. 하나의 클래스가 독립적인 하나의 기능을 중심으로 책임이 잘 뭉쳐있을 수록 높은 응집도를 지닌다고 말한다.

다음으로 결합도란, 서로 다른 클래스가 서로 의존하는 정도를 말한다. 서로 많이 연관되어있는 클래스일 수록 코드를 재사용하기 어려워지고 그렇게되면 객체지향의 의미가 사라진다.

 

>> 응집도와 결합도 참조문서
https://madplay.github.io/post/coupling-and-cohesion-in-software-engineering

 

SRP ; Single Responsiblility Principle 단일 책임 원칙

어떠한 클래스를 변경해야 하는 이유는 한 가지 뿐이어야 한다.

" 모든 클래스는 하나의 책임만을 가진다. "

 

OCP ; Open/Close Principle 개방 폐쇄 원칙

Software entities should be open for extension, but closed for modification.

소프트웨어 객체는 확장에 대해 열려있어야 하지만, 수정에 대해서는 닫혀있어야 한다.

자신의 변화에 대해서는 폐쇄적이지만, 외부의 변화에 대해서는 확정에 개방적이어야 한다.

 

LSP ; Liskov Subs

Subtypes must be substitutable for their base type.

서브 타입은 언제나 자신의 상위 타입으로 교체할 수 있어야 한다.

 

예를들어, 남자는 사람이고, 여자도 사람이지만, 사람은 남자이지 않다.

이러한 관계는 is-a 관계이어야 한다.

is-a relationship : 상속관계

has-a relationship : 연관관계

 

ISP ; Interface Segregation Principle 인터페이스 분리 원칙

Clients should not be forced to depend upon methods that they do not use.

많은 클래스를 포함한다고 좋은 인터페이스가 아니다.

자신이 책임을 지고 있는 클래스들을 잘 분류해서 묶어주는 것이 좋은 인터페이스이다.

 

DIP ; Dependency Inversion Principle 의존 역전 원칙

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

의존의 역전이 일어나는 현상을 방지하기 위한 원칙이다. 자신보다 변하기 쉬운 것에는 의존하지 않아야 한다.

+ Recent posts