검색결과 리스트
Architecture에 해당되는 글 29건
- 2018.01.05 Aho corasick 알고리즘
- 2017.06.27 메시지큐에 대해 알아보자.
- 2017.05.26 PlaybackController Interface
- 2017.05.26 Understanding Alerts
- 2017.05.25 Alerts Interface
- 2017.05.24 AudioPlayer Interface
- 2017.04.18 Apache Mesos
- 2016.03.30 Aho–Corasick string matching algorithm란?
- 2014.02.26 SOLID (object-oriented design)
- 2014.01.27 [DesignPattern] Decorator Pattern (2)
- 2014.01.20 [DesignPattern] Chain of responsibility pattern
- 2014.01.11 [DesignPattern] Visitor pattern
- 2014.01.06 [DesignPattern] Iterator pattern
- 2014.01.06 [DesignPattern] flyweight pattern
- 2013.12.31 [DesignPattern] state pattern
- 2013.12.16 [DesignPattern] memento pattern
- 2013.12.09 [DesignPattern] mediator pattern
- 2013.12.03 [DesignPattern] command pattern
- 2013.11.24 [DesignPattern] observer pattern
- 2013.11.24 [소프트웨어 아키텍처 이론과 실체] 아키텍트로 가기 위한 필독서!!
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
읽어보도록 하자.
논문 : https://pdfs.semanticscholar.org/3547/ac839d02f6efe3f6f76a8289738a22528442.pdf
문제 풀이 : https://www.acmicpc.net/problem/9250
참고 : 슬라이드쉐어 ( https://www.slideshare.net/ssuser81b91b/ahocorasick-algorithm )
'Architecture > algorithm' 카테고리의 다른 글
Aho corasick 알고리즘 (0) | 2018.01.05 |
---|---|
Aho–Corasick string matching algorithm란? (0) | 2016.03.30 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
- 발행/구독(publish - and - subscribe) 모델
- 지점간 연결(point - to - point) 모델
- 클라이언트가 NATS 서버와의 TCP / IP 소켓 연결을 설정.
- nc, _ := nats.Connect(nats.DefaultURL)
- 발행
- nc.Publish("foo", []byte("Hello World"))
- 구독 (subject가 구독대상 : foo)
- 구독 해제(Sync Subscriber 일 경우에만)
// Unsubscribe
func TestNatsWorking(t *testing.T) {
nc, _ := nats.Connect(nats.DefaultURL)
defer nc.Close()
// Simple Publisher
nc.Publish("foo", []byte("Hello World"))
// Simple Async Subscriber
nc.Subscribe("foo", func(m *nats.Msg) {
fmt.Printf("Received a message: %s\n", string(m.Data))
})
}
|
'Architecture > AA' 카테고리의 다른 글
메시지큐에 대해 알아보자. (0) | 2017.06.27 |
---|---|
SOLID (object-oriented design) (0) | 2014.02.26 |
[소프트웨어 아키텍처 이론과 실체] 아키텍트로 가기 위한 필독서!! (0) | 2013.11.24 |
DTP(Distribution Transaction Processing) 관련 자료 (0) | 2013.06.08 |
ACE-T의 아키텍트 이야기 (0) | 2013.01.28 |
AA란? (0) | 2012.11.12 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
그림은 무관합니다. 최강두산 화이팅! ㅋㅋ
- Overview
- PlayCommandIssued Event
- PauseCommandIssued Event
- NextCommandIssued Event
- PreviousCommandIssued Event
- Additional Interfaces
- Resources
Overview
PlayCommandIssued Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
PauseCommandIssued Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
NextCommandIssued Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
PreviousCommandIssued Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
'Architecture > A.I' 카테고리의 다른 글
PlaybackController Interface (0) | 2017.05.26 |
---|---|
Understanding Alerts (0) | 2017.05.26 |
Alerts Interface (0) | 2017.05.25 |
AudioPlayer Interface (0) | 2017.05.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
- Overview
- Scenario 1: Set a Timer with Voice
- Scenario 2: Cancel an Alarm Using the Amazon Alexa App
- Scenario 3: Set a Recurring Alarm
- Scenario 4: Snooze a Sounding Alarm
- Lifecycle Events
- Next Steps
- Resources
Overview
- 지난 30 분 내에 alert가 예정된 경우 제품에서 alert를 트리거하고 모든 해당 이벤트를 보내야합니다.
- alert가 예정된 수행에서 30 분 이상 경과하면 이를 폐기해야하며 제품은 각 폐기 alert에 대해 AVS에 AlertStopped 이벤트를 보내야합니다.
- 인터넷 연결이 끊어지면 이전에 설정된 alert를 처리 할 수 있어야합니다.
- 네트워크 시간 프로토콜을 사용하여 제품의 시계를 관리하십시오.
- 제품의 전원이 꺼 지거나 재부팅되는 경우 이전에 설정된 alert를 처리 할 수 있어야합니다.
- 귀하의 제품은 사용자의 말을 처리하고 AVS로부터받은 지침에 따라 행동하도록 고안되었습니다.
- 귀하의 제품은 클라우드 기반 지시문을 수신하는 다운 채널을 구축했습니다.
- 이벤트가 발생하면 제품에서 AVS를 업데이트합니다.
- 모든 이벤트는 개별 이벤트 스트림으로 전송됩니다.
Scenario 1: Set a Timer with Voice
- 사용자가 타이머 설정을 요청하면 AVS는 Speak Directive를 보내 제품에 연결된 오디오를 재생하도록 지시합니다.
- Alexa speech의 재생이 완료되면 SpeechFinished 이벤트를 AVS에 보내야합니다.
- 또한 AVS는 다운 채널 스트림에서 제품에 SetAlert 지정 문을 전송합니다. 제품 타이머는 5 분 동안 설정되어야하며 SetAlertSucceeded 이벤트는 AVS로 전송되어야합니다. 제품에는 타이머 설정 및 타이머 만료에 필요한 논리가 있어야합니다.
- 5 분이 경과 한 후 제품은 타이머가 만료되었음을 사용자에게 알리고 AlertStarted 이벤트를 AVS로 보내야합니다.
- 요청이 음성 또는 Amazon Alexa 앱을 통해 이루어지면 AVS는 제품에 DeleteAlert Directive를 보냅니다. 이 때 제품은 AlertStopped 이벤트와 DeleteAlertSucceeded 이벤트를 AVS에 보내야 합니다.
- button affordance 결과로 타이머가 중지되면 제품은 AlertStopped 이벤트를 AVS로 전송해야합니다.
Scenario 2: Cancel an Alarm Using the Amazon Alexa App
Scenario 3: Set a Recurring(순환하는) Alarm
Scenario 4: Snooze a Sounding Alarm
Lifecycle Events
User Action |
Server Behavior |
Alert is Active (Making Noise) |
Send AlertStarted |
Send AlertStopped |
Send DeleteAlertSucceeded / DeleteAlertFailed |
User says: “Stop Alert.” |
DeleteAlert를downchannel stream에서 전송. |
Y |
Y |
Y |
Y |
사용자는 실제 컨트롤 (버튼 또는 GUI)을 사용하여 활성 alert를 로컬에서 중지합니다. |
None |
Y |
Y |
Y |
N |
사용자가 음성 요청 또는 Amazon Alexa 앱을 통해 비활성 알림을 취소합니다. |
DeleteAlertdiretive 를 downchannel stream에서 전송. |
N |
N |
N |
Y |
재생하지 않고 알람이 만료되었습니다
(예 : 예정된 이행 시간에 기기의 전원이 켜지지 않음)
|
None |
N |
N |
Y |
N |
'Architecture > A.I' 카테고리의 다른 글
PlaybackController Interface (0) | 2017.05.26 |
---|---|
Understanding Alerts (0) | 2017.05.26 |
Alerts Interface (0) | 2017.05.25 |
AudioPlayer Interface (0) | 2017.05.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
- Overview
- State Diagram
- SetAlert Directive
- SetAlertSucceeded Event
- SetAlertFailed Event
- DeleteAlert Directive
- DeleteAlertSucceeded Event
- DeleteAlertFailed Event
- AlertStarted Event
- AlertStopped Event
- AlertEnteredForeground Event
- AlertEnteredBackground Event
- Additional Interfaces
- Resources
Overview
- Alerts State Diagram
- Alerts Directives and Events
State Diagram
SetAlert Directive
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
dialogRequestId |
Note: dialogRequestId is only sent in response to a speech request. dialogRequestId is not included in directives sent to your client on the downchannel stream.
|
string |
Parameter |
Description |
Type |
token |
An opaque token that uniquely identifies the alert. |
string |
type |
Identifies whether the alert is a timer or alarm.
Accepted values: TIMER or ALARM.
|
string |
scheduledTime |
The scheduled time for an alert in ISO 8601 format. |
string |
SetAlertSucceeded Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the SetAlert directive. |
string |
SetAlertFailed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the SetAlert directive. |
string |
DeleteAlert Directive
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
dialogRequestId |
Note: dialogRequestId is only sent in response to a speech request. dialogRequestId is not included in directives sent to your client on the downchannel stream.
|
string |
Parameter |
Description |
Type |
token |
An opaque token that uniquely identifies the alert. |
string |
DeleteAlertSucceeded Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the DeleteAlert directive. |
string |
DeleteAlertFailed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the DeleteAlert directive. |
string |
AlertStarted Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the SetAlert directive. |
string |
AlertStopped Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the SetAlert directive. |
string |
AlertEnteredForeground Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the SetAlert directive. |
string |
AlertEnteredBackground Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided in the SetAlert directive. |
string |
'Architecture > A.I' 카테고리의 다른 글
PlaybackController Interface (0) | 2017.05.26 |
---|---|
Understanding Alerts (0) | 2017.05.26 |
Alerts Interface (0) | 2017.05.25 |
AudioPlayer Interface (0) | 2017.05.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
- Overview
- State Diagram
- Play Directive
- PlaybackStarted Event
- PlaybackNearlyFinished Event
- ProgressReportDelayElapsed Event
- ProgressReportIntervalElapsed Event
- PlaybackStutterStarted Event
- PlaybackStutterFinished Event
- PlaybackFinished Event
- PlaybackFailed Event
- Stop Directive
- PlaybackStopped Event
- PlaybackPaused Event
- PlaybackResumed Event
- ClearQueue Directive
- PlaybackQueueCleared Event
- StreamMetadataExtracted Event
- Additional Interfaces
- Resources
- AudioPlayer State Diagram
- AudioPlayer directive 및 event
- AVS로 재생(playback) 진행보고
- AVS에 stream metadata 보내기
- 클라이언트는 Play directive를 받습니다.
- 재생 대기열의 next stream이 재생을 시작합니다 (PlaybackStarted event 다음).
Parameter |
Description |
Type |
messageId |
특정 메시지를 나타내는 데 사용되는 고유 ID입니다. |
string |
dialogRequestId |
특정 Recognize event에 응답하여 전송 된 directive를 상호 연관시키는 데 사용되는 고유 ID입니다.
Note: dialogRequestId는 음성 요청에 대한 응답으로 만 전송됩니다. dialogRequestId는 downchannel stream에서 클라이언트로 전송 된 directive에 포함되어 있지 않습니다.
|
string |
Parameter |
Description |
Type |
playBehavior |
재생 힌트를 제공합니다. 허용되는 값 : REPLACE_ALL, ENQUEUE, REPLACE_ENQUEUED.
|
string |
audioItem |
audioItem의 키 / 값 쌍을 포함합니다. |
object |
audioItem.audioItemId |
audioItem을 식별합니다. |
string |
audioItem.stream |
stream의 키 / 값 쌍을 포함합니다. |
object |
audioItem.stream.url |
오디오 내용의 위치를 식별합니다.
오디오 콘텐츠가 이진 오디오 첨부 파일 인 경우이 값은 콘텐츠의 고유 식별자이며 "cid :"와 같이 형식이 지정됩니다. 그렇지 않으면 값은 원격 http / https 위치가됩니다.
|
string |
audioItem.stream.streamFormat |
play directive에 연결된 바이너리 오디오 첨부 파일이 있으면 streamFormat이 payload에 포함됩니다. 연결된 오디오가 스트림이면이 매개 변수가 표시되지 않습니다.
Accepted Value: AUDIO_MPEG
|
string |
audioItem.stream.offsetInMilliseconds |
스트림에서 클라이언트가 재생을 시작해야하는 위치를 나타내는 타임 스탬프. 예를 들어, offsetInMilliseconds를 0으로 설정하면 스트림 재생이 0 또는 스트림 시작 부분에서 시작되어야 함을 나타냅니다. 다른 값은 재생이 제공된 오프셋에서 시작해야 함을 나타냅니다. |
long |
audioItem.stream.expiryTime |
스트림이 유효하지 않은 경우의 ISO 8601 형식의 날짜와 시간. |
string |
audioItem.stream.progressReport |
progress reports의 키 / 값 쌍을 포함합니다. |
object |
audioItem.stream.progressReport. progressReportDelayInMilliseconds |
ProgressReportDelayElapsed 이벤트를 AVS로 보낼 시간 (밀리 초)을 지정합니다. ProgressReportDelayElapsed는 지정된 간격으로 한 번만 보내야합니다.
참고 : 일부 음악 제공 업체는이 보고서를 요구하지 않습니다. 보고서가 필요하지 않은 경우에는 progressReportDelayInMilliseconds가 페이로드에 표시되지 않습니다.
|
long |
audioItem.stream.progressReport. progressReportIntervalInMilliseconds |
ProgressReportIntervalElapsed 이벤트를 AVS로 내보내는 시간을 밀리 초 단위로 지정합니다. ProgressReportIntervalElapsed는 지정된 간격으로 주기적으로 보내야합니다.
참고 : 일부 음악 제공 업체는이 보고서를 요구하지 않습니다.
보고서가 필요하지 않은 경우에는 progressReportIntervalInMilliseconds가 페이로드에 표시되지 않습니다.
|
long |
audioItem.stream.token |
현재의 스트림을 나타내는 opaque token 입니다. |
string |
audioItem.stream.
expectedPreviousToken
|
예상되는 이전 스트림을 나타내는 opaque token 입니다. |
string |
PlaybackStarted Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
트랙의 현재 오프셋 (밀리 초)을 나타냅니다. |
long |
PlaybackNearlyFinished Event
- next stream을 포함하는 Play Directive
- HTTP 204 응답 코드
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
ProgressReportDelayElapsed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
ProgressReportIntervalElapsed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
PlaybackStutterStarted Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
PlaybackStutterFinished Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
stutterDurationInMilliseconds |
stutter의 지속 시간을 밀리 초 단위로 나타냅니다. |
long |
PlaybackFinished Event
- 재생이 중지됩니다 (로컬로 또는 Stop 지시문의 결과로).
- 스트림 간 이동 (다음 / 이전)
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
PlaybackFailed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
재생에 실패한 스트림을 나타내는 Play Directive에서 제공하는 opaque token입니다. |
string |
currentPlaybackState |
playbackState 객체의 키 / 값 쌍을 포함합니다. |
object |
playbackState.token |
An opaque token provided by the Play directive. |
string |
playbackState.offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
playbackState.playerActivity |
Identifies the player state.
Accepted values: PLAYING, STOPPED, PAUSED, FINISHED, BUFFER_UNDERRUN, or IDLE.
|
string |
error |
Contains key/value pairs for error messages. |
object |
error.type |
특정 유형의 오류를 식별합니다. 아래 표는 각 오류 유형에 대한 세부 정보를 제공합니다. |
string |
error.message |
장치가 발생한 오류에 대한 설명. 이것은 기록 목적으로 만 사용됩니다. HTTP 관련 오류의 경우 오류 메시지에 HTTP 오류 응답 본문이 있어야합니다. |
string |
Value |
Description |
MEDIA_ERROR_UNKNOWN |
알 수없는 오류가 발생했습니다. |
MEDIA_ERROR_INVALID_REQUEST |
서버가 요청이 잘못된 것으로 인식했습니다
E.g. bad request, unauthorized, forbidden, not found, etc.
|
MEDIA_ERROR_SERVICE_UNAVAILABLE |
클라이언트가 서비스에 연결할 수 없습니다. |
MEDIA_ERROR_INTERNAL_SERVER_ERROR |
서버가 요청을 수락했지만 예상대로 요청을 처리하지 못했습니다. |
MEDIA_ERROR_INTERNAL_DEVICE_ERROR |
클라이언트에 내부 오류가 있습니다. |
Stop Directive
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
dialogRequestId |
Note: dialogRequestId is only sent in response to a speech request. dialogRequestId is not included in directives sent to your client on the downchannel stream.
|
string |
PlaybackStopped Event
- Stop directive
- REPLACE_ALL의 playBehavior가 포함 된 Play Directive
- clearBehavior가 CLEAR_ALL 인 ClearQueue Directive
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
PlaybackPaused Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided in the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
PlaybackResumed Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided in the Play directive. |
string |
offsetInMilliseconds |
Identifies a track's current offset in milliseconds. |
long |
ClearQueue Directive
- CLEAR_ENQUEUED - 대기열을 지우고 현재 재생중인 스트림을 계속 재생합니다.
- CLEAR_ALL은 전체 재생 대기열을 지우고 현재 재생중인 스트림을 중지합니다 (해당하는 경우).
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
dialogRequestId |
Note: dialogRequestId is only sent in response to a speech request. dialogRequestId is not included in directives sent to your client on the downchannel stream.
|
string |
Parameter |
Description |
Type |
clearBehavior |
대기열 동작을 결정하는 데 사용되는 문자열 값입니다.
Accepted values: CLEAR_ENQUEUED and CLEAR_ALL
|
string |
PlaybackQueueCleared Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
StreamMetadataExtracted Event
Parameter |
Description |
Type |
messageId |
A unique ID used to represent a specific message. |
string |
Parameter |
Description |
Type |
token |
An opaque token provided by the Play directive. |
string |
metadata |
Contains key/value pairs associated with the metadata received. |
object |
'Architecture > A.I' 카테고리의 다른 글
PlaybackController Interface (0) | 2017.05.26 |
---|---|
Understanding Alerts (0) | 2017.05.26 |
Alerts Interface (0) | 2017.05.25 |
AudioPlayer Interface (0) | 2017.05.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Mesos는?
아파치 프로젝트(http://mesos.apache.org/)
트위터, 에어비앤비, 미소스피어가 사용.
기본적으로 Docker 지원.
분산 시스템 커널.
모든 머신에서 동작.
실행 어플리케이션에 대해 리소스 관리와 스케줄링 api를 제공.
Mesosphere = Mesos + Marathon + Chrnons
Marathon : 작업(컨테이너) 관리 담당.
Chronos : 작업 스케줄러.
- Mesos 노드 추상화
- Mesos의 노드들은 모든 Task에 대해 공유 된다.
- Mesos 동작 구성도
- Docker는 작업의 Type중 하나이다.
- Zookeeper를 통해 HA를 구성한다.
- Scheduler는 Chronos을 사용하거나, 직접 개발이 가능하다.
- Mesos 구성도 1
- Marathon은 PaaS플랫폼.
- 향후 Kubernates(참고) 지원계획.
- Mesos 구성도2
- 하이브리드 Cloud 구성가능.
- Batch 작업은 Chronos로 지원.
- Mesos Framework
- Meta-Frameworks / HA Services : Aurora, Marathon
- Distributed Cron : Chronos
- Contailners : Docker
- Continuous Integration : Jenkins, GitLab, GoCD
- Big Data : Hadoop, Spark, Storm, Kafka, Cassandra, Hypertable, MPI
- Python workloads : DPark, Exelixi
- Mesos Architecture
위 그림은 Mesos의 주요 구성 요소를 보여줍니다.
Mesos는 각 클러스터 노드에서 실행되는 에이전트 데몬을 관리하는 마스터 데몬과 이러한 에이전트에서 Task를 실행하는
Mesos 프레임워크로 구성됩니다. 마스터는 리소스 제공을 통해 프레임 워크 전반에서 리소스 (CPU, RAM, ...)를 세밀하게 공유 할 수있게합니다.
각 리소스 오퍼에는 <agent ID, resource1 : amount1, resource2 : amount2, ...> 목록이 포함되어 있습니다
(참고 : 키워드 'slave'는 'agent'를 사용하지 않으므로 드라이버 기반 프레임 워크는 여전히 슬레이브 ID, v1 HTTP API를 사용하는 프레임 워크는 에이전트 ID가있는 오퍼를받습니다.)
마스터는 공정한 공유 또는 엄격한 우선 순위와 같이 주어진 조직 정책에 따라 각 프레임 워크에 제공 할 리소스의 수를 결정합니다.
다양한 정책을 지원하기 위해 마스터는 플러그인 메커니즘을 통해 새로운 할당 모듈을 쉽게 추가 할 수있는 모듈 식 아키텍처를 사용합니다.
Mesos에서 실행되는 프레임 워크는 리소스를 제공 받기 위해 마스터에 등록하는 스케줄러와 프레임 워크의 작업을 실행하기 위해 에이전트 노드에서 실행되는 executor 프로세스로 구성됩니다.
(프레임 워크 스케줄러 및 executors 의 더욱 더 자세한 내용은 App / Framework 개발 가이드 참조 )
마스터가 각 프레임 워크에 제공되는 리소스 수를 결정하는 동안 프레임 워크의 스케줄러는 제공된 리소스 중에서 사용할 리소스를 선택합니다. 프레임 워크가 제공된 자원을 받아들이면 프레임 워크에서 실행하려는 작업에 대한 설명을 Mesos로 전달합니다.
다음 step으로 Mesos는 해당 에이전트에서 Task를 시작합니다.
그림의 이벤트를 살펴 봅시다.
1 . 에이전트 1은 4 개의 CPU와 4GB의 메모리가 있음을 마스터에게보고합니다.
그런 다음 마스터는 할당 정책 모듈을 호출하여 프레임 워크 1에 사용 가능한 모든 리소스가 제공되어야 함을 알립니다.
2. 마스터는 에이전트 1에서 사용할 수있는 것을 프레임 워크 1에 설명하는 리소스 오퍼를 보냅니다. 3. 프레임 워크의 스케줄러는 첫 번째 작업에는 <2 CPU, 1GB RAM>, 두 번째 작업에는 <1 CPU, 2GB RAM>을 사용하여 에이전트에서 실행할 두 가지 작업에 대한 정보로 마스터에 응답합니다. 4. 마지막으로, 마스터는 작업을 에이전트로 보냅니다. 에이전트는 프레임 워크의 executor에게 적절한 자원을 할당하고 두 가지 작업 (그림에서 점선으로 표시)을 시작합니다. CPU 1 개와 RAM 1 개가 아직 할당되지 않았기 때문에 할당 모듈은 프레임 워크 2에 할당 할 수 있습니다. 또한 이 리소스 제공 프로세스는 작업이 완료되고 새 리소스가 해제 될 때 반복됩니다.
Mesos가 제공하는 thin 인터페이스는 확장이 가능하고 프레임 워크가 독립적으로 진화 할 수있게 해주지만 한 가지 질문이 남아 있습니다 : Mesos가 이러한 제약 조건을 안다면 프레임 워크의 제약 조건을 어떻게 만족시킬 수 있습니까?
예를 들어 프레임 워크가 프레임 워크에서 요구하는 데이터를 저장하는 노드를 알면 Mesos없이 어떻게 데이터 지역성을 얻을 수 있습니까?
Mesos는 단순히 프레임 워크에 오퍼를 거부 할 수있는 기능을 부여하여 이러한 질문에 답합니다.
프레임 워크는 제약 조건을 충족시키지 못하는 제안을 거부하고 이를 수용합니다.
특히 프레임 워크가 제한된 시간 동안 입력 데이터를 저장하는 노드를 확보하기 위해 대기하는 지연 스케줄링이라는 간단한 정책이 거의 최적의 데이터 지역을 산출한다는 것을 알게 되었습니다.
출처 : https://www.slideshare.net/songaal/paa-s-mesosmesosphere
https://abhishek-tiwari.com/post/building-distributed-systems-with-mesos
'Architecture' 카테고리의 다른 글
Apache Mesos (0) | 2017.04.18 |
---|---|
아키텍트 지침 15가지!! (0) | 2012.09.14 |
CBD방법론 (0) | 2012.06.04 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Aho–Corasick string matching algorithm




Aho–Corasick 알고리즘 시간 복잡도 : (k : 텍스트 내에 패턴의 발생 수)
Aho-Corasick 알고리즘을 구현하기 위하여 Keyword Tree, Failure link, Output link 자료구조를 사용하여야 한다.
음..대충 이런 알고리즘이라는 것을 알게 되었다.
좋은 오픈 되어진 소스를 발견!
https://github.com/robert-bor/aho-corasick
디펜던시를 넣고 개발을 하면 되겠다!
메이븐
<dependency> <groupId>org.ahocorasick</groupId> <artifactId>ahocorasick</artifactId> <version>0.3.0</version> </dependency> |
그래들
compile('org.ahocorasick:ahocorasick:0.3.0') |
- 끝 -
'Architecture > algorithm' 카테고리의 다른 글
Aho corasick 알고리즘 (0) | 2018.01.05 |
---|---|
Aho–Corasick string matching algorithm란? (0) | 2016.03.30 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
객체지향적으로 개발 할 때 OOD를 따져서 설계하고 개발한다면 더욱 더 좋은 소스가 될 수 있다.
한번 알아보도록 하자!
출처 : http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
추억의 솔리드..ㅋㅋㅋㅋㅋ 이밤에 끝을 잡고~
Initial | Stands for (acronym) |
Concept |
---|---|---|
S | SRP |
ex) Class에 오직 하나의 책임..그렇다면! 메소드도 있는데??? 그렇다! 하나의 Class에 여러가지 메소드가 있을 것이다. 그 메소드들이 Class들 마다 하는 역할을 구분하여 오직 하나의 역할(책임)을 줘야 한다는 뜻이다.
즉, public class acetData{ public void load(){ ......................... }
public void save(){ ......................... }
public void del(){ ......................... }
public void displayToUi(AcetVo acetVo){ ......................... } }
위의 클래스에서 Data와 관련 된 메소드는 데이터를 load 데이터를 save 데이터를 del 이렇게 3가지이며, 데이터 관련 책임이라고 볼 수 있으며, displayToUi는 UI 화면에 데이터를 뿌려주는 것! 즉, 화면에 보여주는 책임이라고 볼 수 있다. displayToUi는 UI Class로 빼줘야 한다.
|
O | OCP |
|
L | LSP |
1)은 Class기반의 상속을 생각하면 된다. 2)는 Interface 기반의 상속(구현)을 생각하면 된다.
1)은 말그대로 객체를 치환하여도 같은 동작을 하면 OK!! 2) 객체를 치환한다는 개념으로 접근하기보다 SubType의 기능 수행으로 생각하면 된다. ex) dataSave()면 데이터 저장인데 그 안에서 modify기능을 하면 안된다.
이 원칙은 OCP를 잘 구현하기 위해 체크하는 스펙 같은거라고 보면 될 것 같다. 반대로 말하면 리스코프 치환 원칙을 지키지 않으면 OCP를 지키지 않을 가능성이 커진다는 것이다.
특히 2번, 인터페이스 기반에서는 치환이라는 개념 자체가 이해가 가질 않았을 것이다..그러므로 기능, 리턴, 예외 등 올바른 작동을 하는지 봐야 한다.
|
I | ISP |
생각해보자! 기능 중심?????? 인터페이스를 분리해??? Why?? 인터페이스를 하나 만들려고 한다. 그 안에는 여러가지 메소드들이 많이 있을 것이다. 즉, ISP의 원칙을 잘모른다면..동작의 역할 인 메소드들이 뒤죽박죽 하나의 인터페이스에 얽혀있을 것이다. 하지만 ISP를 잘~~알고 인터페이스를 만든다고 하면! 바로 기능중심!!! 으로 나눠서 이쁘게 잘~~~쓰게 될 것이다.
참고문헌 : 개발자가 반드시 정복해야 할 객체지향과 디자인 패턴(최범균 저)
|
D | DIP |
DI(Dependency Injection)이라고 보면 된다. springframework의 특징
중인 IoC/DI 이다. 커플링을 최소화시키며(외부주입을 해주니깐!)
특히, 생성자 또는 setter로 주입을 시키는 특징이 있다.
|
- END -
'Architecture > AA' 카테고리의 다른 글
메시지큐에 대해 알아보자. (0) | 2017.06.27 |
---|---|
SOLID (object-oriented design) (0) | 2014.02.26 |
[소프트웨어 아키텍처 이론과 실체] 아키텍트로 가기 위한 필독서!! (0) | 2013.11.24 |
DTP(Distribution Transaction Processing) 관련 자료 (0) | 2013.06.08 |
ACE-T의 아키텍트 이야기 (0) | 2013.01.28 |
AA란? (0) | 2012.11.12 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Decorator Pattern
개요 |
클래스 다이어그램 |
예제(Java) |
같이보기 |
참고 사항 |
<< 개요 >>
Decorator Pattern 이란?
데코레이터 패턴(Decorator pattern)이란 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다.
(출처 : 위키피디아 - http://ko.wikipedia.org/wiki/%EB%8D%B0%EC%BD%94%EB%A0%88%EC%9D%B4%ED%84%B0_%ED%8C%A8%ED%84%B4)
의도
객체에 동적으로 새로운 서비스를 추가
기능 추가를 위해 서브클래스를 생성 하는 것 보다 융통성이 있음.
아래의 로봇 사진 출처 : http://blog.naver.com/PostView.nhn?blogId=romantico_q&logNo=50185115988
변신 합체 로봇!! 페가서스 라고 하네요^^;;
데코레이터 패턴을 학습 하면서 기억에 많이 남을만한 예제가 없을까? 라고 생각하던 차에..변신합체 로봇을 통해 학습하면 좋겠다고 생각하게 되었습니다..ㅋㅋㅋㅋ;;
우리의 변신합체 로봇들을 소개 합니다.
우리의 메인 로봇인 왼쪽 - 파랭이 로봇!!
그 외 몸통이 될 가운데 로봇, 다리가 되어줄 빨갱이 로봇ㅋㅋ
하일라이트로 다시 한번 변신을 시켜줄 우리의 독수리 로봇이 되겠습니다.
1) 머리(우리의 메인)
2) 몸통(합체 되어질)
3) 다리(합체 되어질)
쫘잔~~~+ㅁ+/
아래처럼 합체로봇으로 변신하게 됩니다.
여기서 다가 아닙니다!! 변신합체 로봇에서 다시 한번 독수리가 합체가 되어서
그 유명한!! 페가서스가 되어집니다!!!! 쫘잔~~~~~~+ㅁ+/
변신합체 로봇! 페가서스!!!! 두둥~
자! 데코레이터 패른!!! 시작 해볼까용?~~
개요는 마무리 하고, 먼저 패턴의 클래스 다이어그램을 먼저 살펴 보겠습니다.
<< 클래스 다이어그램 >>
그냥 한번 그려보았다..;;
아래와 비교해보면 인터페이스와 추상클래스간의 관계를 그리지 않은 것 같다. 참고하자!
<< 예제(Java) >>
1) 결과
아래의 결과와 같이 변신은 메인 로봇이 머리로! 그 다음엔 바디, 그 다음 다리, 그 다음 뒷다리로 변신이
되어집니다. ㅋㅋㅋ 전투력은 무려 10만이 넘어가네요+ㅁ+/
Change Center Robot -> Body Combine!! |
2) 테스트 코드
package kr.pe.acet.decorator; import org.junit.Assert; public class DecoratorPatternTest { @Test } |
3) Robot Interface(Decorator pattern에서 중요하게 봐야 할 부분 입니다.)
package kr.pe.acet.decorator; public interface Robot { |
4) MainRobot class
package kr.pe.acet.decorator; public class MainRobot implements Robot{ @Override @Override |
5) CombineDecorator class (Decorator pattern에서 중요하게 봐야 할 부분 입니다.)
package kr.pe.acet.decorator; public abstract class CombineDecorator implements Robot{ public int getPower() { |
6) BodyCombine class
package kr.pe.acet.decorator; public class BodyCombine extends CombineDecorator{ public BodyCombine(Robot newRobot) { public String getCombineAction() { public int getPower() { } |
7) LegCombine class
package kr.pe.acet.decorator; public class LegCombine extends CombineDecorator{ public LegCombine(Robot newRobot) { public int getPower() { } |
8) BacklegCombine class
package kr.pe.acet.decorator; public class BacklegCombine extends CombineDecorator{ public BacklegCombine(Robot newRobot) { public String getCombineAction() { public int getPower() { } |
<< 같이 보기 >>
https://www.youtube.com/watch?v=j40kRwSm4VE
정말 도움이 많이 된 동영상 입니다. 참고하세요~꼭 보세요~!!
내 책에 있던 소스 코드
또 다른 소스 참고! : https://github.com/colorbox/Gof/tree/master/java/Decorator
<< 참고 사항 >>
데코레이터 패턴은 객체에 동적으로 새로운 무엇인가를 하고자 할 때 사용 된다. 특히 상속으로 sub Class를 이용하는 것 보다 더 유연성 있게 추가 할 수 있다.
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Decorator Pattern (2) | 2014.01.27 |
---|---|
[DesignPattern] Chain of responsibility pattern (0) | 2014.01.20 |
[DesignPattern] Visitor pattern (0) | 2014.01.11 |
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
설정
트랙백
댓글
-
안녕하세요. 블로그 내용이 좋아서♡ 블로그모음 서비스인 블로그앤미[http://blogand.me] 에 등록했습니다. 원하지 않으시면 삭제하겠습니다. 좋은 하루 되세요. ^^
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Chain of responsibility Pattern
개요 |
예제(Java) |
같이보기 |
참고 사항 |
<< 개요 >>
Chain of responsibility Pattern 이란?
(참고 사이트 : 위키피디아 - http://ko.wikipedia.org/wiki/Chain_of_responsibility_%ED%8C%A8%ED%84%B4)
객체 지향 디자인에서 chain-of-responsibility pattern은 명령 오브젝트와 일련의 프로세스 오브젝트를 포함하는 디자인 패턴이다. 각각의 프로세스 오브젝트는 명령 오브젝트를 핸들할 수 있는 연산의 집합으로 이루어지고, 체인안의 프로세스 오브젝트가 핸들할 수 없는 행해진다. 이 작동방식은 새로운 프로세스 오브젝트에서 체인의 끝까지에도 포함된다.
표준 chain-of-responsibility model이 변화하면서, 몇몇 핸들러들은 다양한 방향으로 명령을 보내 책임을 트리 형태로 바꾸는 관제사 역할을 하기도 한다. 몇몇 경우에서는, 프로세스 오브젝트가 상위의 프로세스 오브젝트와 명령을 호출하여 작은 파트의 문제를 해결하기 위해 재귀적으로 실행된다. 이 경우 재귀는 명령이 처리되거나 모든 트리가 탐색될때까지 진행되게 된다. XML(파싱되었으나 실행되지 않은)인터프리터가 알맞은 예가 된다.
이 패턴은 결합을 느슨하게 하기 위해 고안되었으며 가장 좋은 프로그래밍 사례로 꼽힌다.
라고는 되어있는데 무슨 내용인지...처음에는 전혀 Feel을 느낄 수 가 없었다..:D
우선은 아래의 예제를 보고 어떤 녀석인지 감을 잡아보도록 하자.
아! 예제를 보기전에 클래스 다이어그램을 보도록 하자.
<< 예제(Java) >>
예제는 사칙연산에 대해서 구현을 해보겠다. 참고사항의 동영상에 나오는 소스이다.
이해 돕기에 좋은 소스 인 것 같아서 선택하였다! ㅋㅋ
위의 클래스 다이어그램 처럼 우선 Interface인 Handler를 구현하여 보자. 명명은 Chain으로 하겠다.
1) Chain Interface : 2가지로 구성 되어질 수 있는데 하나는 객체를 엮을 수 있는(Chain)
setNextChain()이고, 또 다른 하나는 구현하여 사용하게 되는 calculate() 이다.
package kr.pe.acet.chainOfResposibility; public interface Chain { public void setNextChain(Chain nextChain); public void calculate(Numbers req); } |
2) Chain의 구현부에서 사용 되어 질 Numbers.java를 만들어보자.
내부 구조는 계산 되어질 숫자형 2개, 어떤 작업인지를 뜻하는 String 으로 변수가 구성되어져있다.
그리고 생성자와 getter 들이 있다.
package kr.pe.acet.chainOfResposibility; public class Numbers { private int number1; private int number2;
private String calculationWanted;
public Numbers(int number1, int number2, String calWanted){ this.number1 = number1; this.number2 = number2; this.calculationWanted = calWanted; } public int getNumber1() { return number1; } public int getNumber2() { return number2; } public String getCalculationWanted() { return calculationWanted; }
} |
3) Chain Interface의 구현부들(
- AddNumbers.java
package kr.pe.acet.chainOfResposibility; public class AddNumbers implements Chain{
private Chain nextInChain; @Override public void setNextChain(Chain nextChain) { this.nextInChain = nextChain; } @Override public void calculate(Numbers req) { if(req.getCalculationWanted() == "add"){ System.out.println(req.getNumber1()+" + "+req.getNumber2()+"="+(req.getNumber1()+req.getNumber2())); }else{ nextInChain.calculate(req); } } } |
- SubtractNumbers.java
package kr.pe.acet.chainOfResposibility; public class SubtractNumbers implements Chain{
private Chain nextInChain; @Override public void setNextChain(Chain nextChain) { this.nextInChain = nextChain; } @Override public void calculate(Numbers req) { if(req.getCalculationWanted() == "sub"){ System.out.println(req.getNumber1()+" - "+req.getNumber2()+"="+(req.getNumber1()-req.getNumber2())); }else{ nextInChain.calculate(req); } } } |
- MultiNumbers.java
package kr.pe.acet.chainOfResposibility; public class MultiNumbers implements Chain{
private Chain nextInChain; @Override public void setNextChain(Chain nextChain) { this.nextInChain = nextChain; } @Override public void calculate(Numbers req) { if(req.getCalculationWanted() == "multi"){ System.out.println(req.getNumber1()+" * "+req.getNumber2()+"="+(req.getNumber1()*req.getNumber2())); }else{ nextInChain.calculate(req); } } } |
- DivideNumbers.java
package kr.pe.acet.chainOfResposibility; public class DivideNumbers implements Chain{
private Chain nextInChain; @Override public void setNextChain(Chain nextChain) { this.nextInChain = nextChain; } @Override public void calculate(Numbers req) { if(req.getCalculationWanted() == "div"){ System.out.println(req.getNumber1()+" / "+req.getNumber2()+"="+(req.getNumber1()/req.getNumber2())); }else{ System.out.println("Only works for add, sub, mult, div~!!"); } } } |
4) Test Code
package kr.pe.acet.chainOfResposibility; import static org.junit.Assert.*; import org.junit.Test; public class ChainOfResponsibilityTestCode { @Test public void chainOfResponsibilityTest() { Chain chainCal1 = new AddNumbers(); Chain chainCal2 = new SubtractNumbers(); Chain chainCal3 = new MultiNumbers(); Chain chainCal4 = new DivideNumbers();
chainCal1.setNextChain(chainCal2); chainCal2.setNextChain(chainCal3); chainCal3.setNextChain(chainCal4);
//Numbers request = new Numbers(10, 29, "add"); //Numbers request = new Numbers(10, 29, "multi"); Numbers request = new Numbers(10, 29, "acet");
chainCal1.calculate(request);
} } |
5) 결과
Numbers request = new Numbers(10, 29, "add"); 일 경우 : 10 + 29=39
Numbers request = new Numbers(10, 29, "multi"); 일 경우 : 10 * 29=290 Numbers request = new Numbers(10, 29, "acet"); 일 경우는??? 이 답을 대답 할 수 있다면 Chain of responsibility pattern을 이해가 된 것이라고 생각이 든다! [ Only works for add, sub, mult, div~!! ] => 답은 드래그~~~:D |
<< 같이 보기 >>
인터프리터 패턴과 비슷한 느낌을 받았다.
study :
굿택님 - 패턴정의 소개, 클래스 다이어그램 소개, 클라이언트에서 핸들러에게 책임을 주면 줄을 서있고 차레차레 일을 전달
Handler : Request를 처리 하기 위한 인터페이스를 정의, 다음 것의 링크를 정의
이 패턴의 목적은 객체간의 의존성을 약화시킨다.
예제 시연..
라낑님 : 위키피디아 개념 설명, 로그 관련 예제 시연, 스프링 시큐리티- 서블릿필터 예제
<< 참고 사항 >>
동영상 사이트 : https://www.youtube.com/watch?v=jDX6x8qmjbA
동영상에 외국인 아저씨가 코딩 한대로 했는데...틀린 부분이 있었다!!!!
if(req.getCalculationWanted() == "add"){
if(req.getCalculationWanted() == "div"){
요런 녀석들은...equals를 사용하는게 맞다^-^;
if(req.getCalculationWanted().equals("add")){
if(req.getCalculationWanted().equals("div")){
- END -
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Decorator Pattern (2) | 2014.01.27 |
---|---|
[DesignPattern] Chain of responsibility pattern (0) | 2014.01.20 |
[DesignPattern] Visitor pattern (0) | 2014.01.11 |
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Visitor Pattern
개요 |
예제(Java) |
같이보기 |
참고 사항 |
<< 개요 >>
Visitor Pattern - 구조안을 돌아다니면서 일을 한다.
네이버 어학사전
(software, design, ) A behavioural design pattern that separats an algorithm from an object structure on which it operates.
- 행위 디자인 패턴이고 객체 구조로부터 분리하는 하나의 방법이다. 이런 분리는 존재하고 있는 객체 구조에 그 구조를 수정하지 않고 새로운 동작을 추가 할 수 있도록 해준다. 이것은 open-closed principle에 따르는 하나의 방법이다.
또한, 오퍼레이션!! 동작이라고 생각하자.
비지터 패턴은 객체의 요소에 대해 수행하는 오퍼레이션을 나타낸다.
즉, visitor(방문자)는 자신의 오퍼레이션의 대상이 되는 요소를 갖는 클래스를 수정하지 않고 새로운 오퍼레이션을 정의하는게 가능케한다.
적용영역으로 객체의 구조를 정의하는 클래스가 잘 변하지는 않으나, 구조 상에서 새로운 오펄이션을 정의 하고자 하는 경우나 하나의 객체에 대해서 관련이 적은, 상이한 오퍼레이션을 수행 할 필요가 있는 경우, 이러한 오퍼레이션에 의해 클래스가 난잡하게 되는 것을 막기 위해 사용한다.
요약하자면
1) 새로운 오퍼레이션 추가가 용이.
2) Visitor는 관련 있는 오퍼레이션을 묶고, 관련이 적은 오퍼레이션을 분리 시킨다.(OCP)
3) Visitor의 사용은 ConcreteElement Interface가 내부상태에 접근 할 수 있는 공개된 오퍼레이션 제공을 요구하며, 캡슐화(encapsulation)를 약화 시킨다.(단점?)
위의 말들이 맞는지는 아래를 보면서 확인 해보자.(사실 위의 말들이...처음에는 뭔소린가? 할 것이다ㅋㅋ)
[클래스 다이어그램]
<< 예제 Java >>
어떤 예제가 좋을까...고민하다가 비지터니깐 베지터로 해야겠다는 생각을 했다 ㅋㅋ
즉, Visitor == 베지터(Vesiter)가 된다. 캬캬;
자! 그럼 재미있는 코딩을 해보자 ㅋㅋ
결과부터 보면..
[ 결과 ]
베지터가 손오공과 함께 나메크성에 방문 하였습니다. 베지터가 프리저에게 대항하여 지구에서 전투 중입니다. |
[테스트 코드]
package kr.pe.acet.visitor; import static org.junit.Assert.*; import org.junit.Test; public class VisitorTestCode { @Test public void visitorTest() {
Namek namekSung = new Namek("손오공"); namekSung.accept(new VisitPlanet()); Earth earth = new Earth("프리저"); earth.accept(new VisitPlanet());
} }
|
자 이제 클래스 다이어그램을 보고 소스를 짜보자!
우선 2개의 interface가 필요하다는 것을 알 수 가 있다.
Element, Visitor
1) Visitor(베지터) - 방문자
package kr.pe.acet.visitor; public interface Vesiter { public void visit(Namek namek); // 나메크행성 방문 public void visit(Earth earth); // 지구 방문 } |
2) Element는 Accepter(수용자)의 역할을 한다. 즉, Vesiter의 동작이 방문할 곳을 나타내는 동작을 한다. 방문자(베지터)를 받아들이는 accept 메소드를 선언한다. accept 메소드의 인수로는 베지터의 오퍼레이션(동작)을 넘겨진다.
Accepter(수용자)
package kr.pe.acet.visitor; public interface Accepter { public void accept(Vesiter v); } |
3) 베지터 구현 소스 - VisitPlanet
package kr.pe.acet.visitor; public class VisitPlanet implements Vesiter{ @Override public void visit(Namek namek) { // TODO Auto-generated method stub System.out.println("베지터가 "+namek.getName()+"과 함께 나메크성에 방문 하였습니다.");
} @Override public void visit(Earth earth) { // TODO Auto-generated method stub System.out.println("베지터가 "+earth.getName()+"에게 대항하여 지구에서 전투 중입니다."); }
} |
4) 수용자(Accepter) 구현 소스 - Namek
package kr.pe.acet.visitor; public class Namek implements Accepter{
String name;
public Namek(String name){ this.name= name; }
public String getName() { return name; } @Override public void accept(Vesiter v) { v.visit(this); } }
|
5) 수용자(Accepter) 구현 소스 - Earth
package kr.pe.acet.visitor; public class Earth implements Accepter{ private String name;
public Earth(String name) { this.name=name; } public String getName() { return name; } @Override public void accept(Vesiter v) { v.visit(this); } }
|
위에서 구조를 하나 더 넣어보면..!!
<< 같이 보기 >>
스터디 - 2014.01.13
라낑님 : 구조에서 분리 시키는 방법. 행위에 관련 된 것을 인터페이스로 뽑아 냄.
위키피디아 소스로 진행.
구조에 대한 정의는 미리 Visitor 인터페이스로 정의(Wheel, Engine, Body 등등)
굿택님 : 객체구조를 비지터가 방문하여 뭔가를 빼낸다고 이해 함.
내가 짠 소스를 비유하면 나메크성과 지구가 객체구조이고, 베지터가 방문을 한다고 보면 된다.
Acceptor가 받아줘야 함. 받아줬을 때만 방문을 허락 함. ppt 파일 소개, 예제 확인(야동관련).
<< 참고 사항 >>
다시 보도록 하자. 사실 위에서 말했던 "구조를 수정하지 않고 새로운 동작을 추가 할 수 있도록 해준다"에서 구조라는 것이 헷깔렸었다..스터디를 통해서 정확히 알 수 있었다.
여기에서 구조라는 것은 Visitor의 구조 이다. 즉, 베지터의 구조 이다.
베지터의 구조!!
public void visit(Namek namek); // 나메크행성 방문
public void visit(Earth earth);
이 구조를 가지고 새로운 동작을 추가!! 즉, VisitPlanet 와 같은 동작을 쉽게! 추가 할 수 가 있다.
AttackPlanet을 하나 추가 해보자!
- Attackplanet.java
package kr.pe.acet.visitor; public class AttackPlanet implements Vesiter{ @Override public void visit(Namek namek) { // TODO Auto-generated method stub System.out.println("베지터가 "+namek.getName()+"과 함께 나메크성에 공격 하였습니다.");
} @Override public void visit(Earth earth) { // TODO Auto-generated method stub System.out.println("베지터가 "+earth.getName()+"에게 대항하여 지구에서 전투 중입니다."); }
}
|
행위 디자인 패턴이고 객체 구조로부터 분리하는 하나의 방법이다. 이런 분리는 존재하고 있는 객체 구조에 그 구조를 수정하지 않고 새로운 동작을 추가 할 수 있도록 해준다. 이것은 open-closed principle에 따르는 하나의 방법이다.
필자는..구조가 너무 헷깔려서...Moon이라는 Class를 추가하여 새로운 동작을 추가 하고자 했었다..
" 자신의 오퍼레이션의 대상이 되는 요소를 갖는 클래스를 수정하지 않고 새로운 오퍼레이션을 정의하는게 가능케한다."
에서도 마찬가지이다. 클래스를 수정하지 않는다에서의 클래스는 Visitor 이며, 새로운 오퍼레이션이라는 것은 VisitPlanet같은 Visitor의 구현체인 것이다.
- END -
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Decorator Pattern (2) | 2014.01.27 |
---|---|
[DesignPattern] Chain of responsibility pattern (0) | 2014.01.20 |
[DesignPattern] Visitor pattern (0) | 2014.01.11 |
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Iterator Pattern
개요 |
예제(Java) |
같이보기 |
참고 사항 |
<< 개요 >>
Iterator Pattern - 하나씩 열거하면서 처리 한다.
<< 예제(Java) >>
1. 결과
실용주의 프로그래머 |
2. 테스트 코드
package kr.pe.acet.iterator;
public class AggregateTest { bookShelf.appendBook(new Book("실용주의 프로그래머")); Iterator it = bookShelf.iterator(); while(it.hasNext()){ System.out.println(book.getName()); } |
3.Aggregate
package kr.pe.acet.iterator; import java.util.Iterator; public interface Aggregate { |
4. BookShelf
package kr.pe.acet.iterator;
private Book[] books; private int last = 0; public BookShelf(int maxsize){ public Book getBookAt(int index){ public void appendBook(Book book){ |
5. BookShelfIterator
package kr.pe.acet.iterator; public class BookShelfIterator implements Iterator{ private int index; public BookShelfIterator(BookShelf bookShelf){ public boolean hasNext(){ Book book = bookShelf.getBookAt(index); |
6. Iterator
package kr.pe.acet.iterator; public interface Iterator { |
<< 같이 보기 >>
1. Visitor pattern
2. Composite pattern
3. Factory Method pattern
<< 참고 사항 >>
1.Java 언어로 배우는 디자인 패턴 입문
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Chain of responsibility pattern (0) | 2014.01.20 |
---|---|
[DesignPattern] Visitor pattern (0) | 2014.01.11 |
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
[DesignPattern] memento pattern (0) | 2013.12.16 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
Flyweight Pattern
개요 |
클래스 다이어그램 |
예제(Java) |
같이보기 |
참고 사항 |
<< 개요 >>
Flyweight - 동일한 것을 공유해서 낭비를 없앤다.
이 디자인패턴은 객체를 '가볍게' 하기 위함 이다. 여기에서의 가볍다라는 것은 메모리의 사용량을 말한다.
한마디로 인스턴스를 가능한 공유시켜서 쓸데없이 new를 하지 않는 것이다.
<< 클래스 다이어그램 >>
<< 예제(Java) >>
결과
객체 생성!? |
테스트 코드
package kr.pe.acet.flyweight; import static org.junit.Assert.*; import org.junit.Test; public class FlyweightTest { @Test } |
Flyweight 소스 - interface
package kr.pe.acet.flyweight; public interface Hunter { |
Flyweight 구현부
package kr.pe.acet.flyweight; public class HunterKind implements Hunter{ private int lv; public HunterKind(String shareObj) { @Override @Override }
|
Flyweight Factory 소스
package kr.pe.acet.flyweight; import java.util.HashMap; public class HunderVilage { public HashMap<String, HunterKind> hunterSchool = new HashMap<String, HunterKind>();
|
hunterSchool에 인스턴스를 종류별로 만들고, 같은 값을 사용하는 인스턴스를 Key 값으로 분류해 사용하면, 매번 new 하지 않아도 되고(new 를 할때 시간소요), 그만큼 메모리도 덜 소비 해서 퍼포먼스를 높일수 있다.
추가적으로
Intrinsic 상태 : Flyweight 객체의 내부에 저장 관리 되는 정보
Extrinsic 상태 : Flyweight 객체의 외부에 저장 관리 되는 정보
<< 같이 보기 >>
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
<< 참고 사항 >>
1. http://kimsunzun.tistory.com/entry/Flyweight-%ED%8C%A8%ED%84%B4-1
2. http://jmnote.com/wiki/Flyweight_%ED%8C%A8%ED%84%B4
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Visitor pattern (0) | 2014.01.11 |
---|---|
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
[DesignPattern] memento pattern (0) | 2013.12.16 |
[DesignPattern] mediator pattern (0) | 2013.12.09 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
2013/12/16 - [Architecture/DesignPattern] - [DesignPattern] memento pattern
2013/12/09 - [Architecture/DesignPattern] - [DesignPattern] mediator pattern
2013/12/03 - [Architecture/DesignPattern] - [DesignPattern] command pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] observer pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] Interpreter pattern
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] abstractFactory 패턴
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
참고 사이트 : https://www.youtube.com/watch?v=MGEx35FjBuo
<< State Design Pattern은 무엇인가?? >>
1) 내부의 상태가 변경되면 객체의 변경을 허용한다. 객체변경이란 무엇인지는 뒤에~
2) 구조
- Context : Concrete State의 구현 클래스의 현재 상태의 인스턴스를 유지한다.
- State : Context의 행동과 연관된 독특한 상태를 interface로 정의한다.
한마디로...상태를 나타내는 역할이다.
- Concrete State : State의 구현부 이다. 즉, 개개의 상태를 표현하는 역할이다.
3) 참고 그림
- 참고사이트 : http://en.wikipedia.org/wiki/State_pattern
[클래스 다이어그램]
소스 : 테스트 소스
package kr.pe.acet.state; import org.junit.Assert; import org.junit.Test; public class StateTest { @Test public void test() { final StateContext sc = new StateContext(); Assert.assertNotNull(sc); sc.writeName("Monday"); sc.writeName("Tuesday"); sc.writeName("Wednesday"); sc.writeName("Thursday"); sc.writeName("Friday"); sc.writeName("Saturday"); sc.writeName("Sunday"); } } |
소스 : Context - Concrete State의 구현 클래스의 현재 상태의 인스턴스를 유지한다.
package kr.pe.acet.state; public class StateContext { private Statelike myState; /** * Standard constructor */ StateContext() { setState(new StateA()); } /** * Setter method for the state. Normally only called by classes implementing * the State interface. * * @param newState * the new state of this context */ void setState(final Statelike newState) { myState = newState; } /** * Writer method * * @param name * the name to be written */ public void writeName(final String name) { myState.writeName(this, name); } } |
소스 : State - Context의 행동과 연관된 독특한 상태를 interface로 정의한다.
package kr.pe.acet.state; public interface Statelike { /** * Writer method for the state name. * @param context the stateful context * @param name the name to be written */ void writeName(StateContext context, String name);
} |
소스 : Concrete State - State의 구현부 이다.
package kr.pe.acet.state; public class StateA implements Statelike { @Override public void writeName(StateContext context, String name) { System.out.println(name.toLowerCase()); context.setState(new StateB()); } } |
package kr.pe.acet.state; public class StateB implements Statelike { /** State counter */ private int count = 0; @Override public void writeName(final StateContext context, final String name) { System.out.println(name.toUpperCase()); /* Change state after StateB's writeName() gets invoked twice */ if (++count > 1) { context.setState(new StateA()); } } } |
결과
monday TUESDAY WEDNESDAY thursday FRIDAY SATURDAY sunday |
음...뭔가 단순하다. 위의 소스에서 그냥 이것저것 해보자.
결과는 이렇게~
[null]에서[kr.pe.acet.state.StateA@1e63e3d]로 변경 되었습니다. monday StateA Excute!! [kr.pe.acet.state.StateA@1e63e3d]에서[kr.pe.acet.state.StateB@1b90b39]로 변경 되었습니다. 오늘은 월요일 입니다. TUESDAY StateB Excute!! 오늘은 화요일 입니다. WEDNESDAY StateB Excute!! [kr.pe.acet.state.StateB@1b90b39]에서[kr.pe.acet.state.StateA@18fe7c3]로 변경 되었습니다. 수요일 [kr.pe.acet.state.StateA@18fe7c3]에서[kr.pe.acet.state.StateB@b8df17]로 변경 되었습니다. THURSDAY StateB Excute!! 오늘은 목요일 입니다. FRIDAY StateB Excute!! [kr.pe.acet.state.StateB@b8df17]에서[kr.pe.acet.state.StateA@13e8d89]로 변경 되었습니다. 금요일 [kr.pe.acet.state.StateA@13e8d89]에서[kr.pe.acet.state.StateB@1be2d65]로 변경 되었습니다. SATURDAY StateB Excute!! 오늘은 토요일 입니다. SUNDAY StateB Excute!! [kr.pe.acet.state.StateB@1be2d65]에서[kr.pe.acet.state.StateA@9664a1]로 변경 되었습니다. 일요일 [kr.pe.acet.state.StateA@9664a1]에서[kr.pe.acet.state.StateB@1a8c4e7]로 변경 되었습니다.
|
TEST Code
package kr.pe.acet.state;
import org.junit.Assert;
import org.junit.Test;
public class StateTest {
@Test
public void statePatternTest() {
final StateContext sc = new StateContext();
Assert.assertNotNull(sc);
sc.writeName("Monday");
sc.getDay("월요일");
sc.writeName("Tuesday");
sc.getDay("화요일");
sc.writeName("Wednesday");
sc.getDay("수요일");
sc.writeName("Thursday");
sc.getDay("목요일");
sc.writeName("Friday");
sc.getDay("금요일");
sc.writeName("Saturday");
sc.getDay("토요일");
sc.writeName("Sunday");
sc.getDay("일요일");
}
}
Context Code
package kr.pe.acet.state;
// 상태를 관리하거나
public class StateContext {
private State myState;
/**
* Standard constructor
*/
StateContext() {
setState(new StateA());
}
/**
* Setter method for the state. Normally only called by classes implementing
* the State interface.
*
* @param newState
* the new state of this context
*/
void setState(final State newState) {
changeState(newState);
myState = newState;
}
/**
* Writer method
*
* @param name
* the name to be written
*/
public void writeName(final String name) {
myState.writeName(this, name);
}
// 상태를 하나 추가
public void getDay(final String name){
myState.changeName(this, name);
}
// 상태 변화 관리
public void changeState(State state){
System.out.println("["+this.myState+"]에서["+state+"]로 변경 되었습니다.");
}
}
State Code
package kr.pe.acet.state;
// 상태를 나타 냄
public interface State {
/**
* Writer method for the state name.
* @param context the stateful context
* @param name the name to be written
*/
void writeName(StateContext context, String name);
void changeName(StateContext context, String name);
}
Concrete State Code - StateA
package kr.pe.acet.state;
public class StateA implements State {
@Override
public void writeName(StateContext context, String name) {
System.out.println(name.toLowerCase());
System.out.println("StateA Excute!!");
context.setState(new StateB());
}
@Override
public void changeName(StateContext context, String name) {
// TODO Auto-generated method stub
System.out.println(name+"\n\n");
context.setState(new StateB());
}
}
Concrete State Code - StateB
package kr.pe.acet.state;
public class StateB implements State {
/** State counter */
private int count = 0;
@Override
public void writeName(final StateContext context, final String name) {
System.out.println(name.toUpperCase());
System.out.println("StateB Excute!!");
/* Change state after StateB's writeName() gets invoked twice */
if (++count > 1) {
context.setState(new StateA());
}
}
@Override
public void changeName(StateContext context, String name) {
System.out.println("오늘은 "+name+" 입니다.\n\n");
}
}
마지막으로 State Pattern의 장단점은??
장점 : 언제 다른 상태로 변하는지 알 수 있는 정보가 하나의 클래스 내에 정리되어 있는 점이다.
즉, 위의 Concrete State Code들을 보면 알 수 있다.
단점 : 하나의 ConcreteState 역할이 다른 ConcreteState 역할을 알아야한다는 점이다. 엥??
아까는 장점이라매? 장난치나?? 라고 하실지도 모르겠군요..ㅋㅋ;;
즉, 상태변화를 ConcreteState역할에 맡겨버리면 클래스간의 의존관계를 강하게 만들기 때문에
위의 Class StateA에서 StateB의 객체를 만드는 부분이 있습니다. 이때 StateB가 삭제 되버리면
StateA에도 수정을 가해야하는 단점이 있습니다. 그래서
Mediator Pattern을 적용 할 수 도 있을 것 같다.
2013/12/09 - [Architecture/DesignPattern] - [DesignPattern] mediator pattern
- 끝 -
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] Iterator pattern (0) | 2014.01.06 |
---|---|
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
[DesignPattern] state pattern (0) | 2013.12.31 |
[DesignPattern] memento pattern (0) | 2013.12.16 |
[DesignPattern] mediator pattern (0) | 2013.12.09 |
[DesignPattern] command pattern (0) | 2013.12.03 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback).
The memento pattern is implemented with three objects: the originator, a caretaker and a memento.
The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.
출처) 위키피디아
memento pattern에는 3가지 객체가 필요하다.
1) originator
미국·영국 [ərídƷənèitər] 영국식
다른 뜻(1건) 예문보기
창작자, 창설자, 창시자, 발기인, 시조
가. Sets and Gets values from the currently targeted memento object.
나. Creates new Mementos and assigns current values to them.
2) caretaker
미국식 [|kerteɪkə(r)] / 영국식 [|keəteɪkə(r)]
1. (건물의) 경비원 2. (주택・토지의) 관리인 3. 다른 사람을 돌보는 사람
Holds an ArrayList that contains all previous versions of the Memento.
It can store and retrieve stored Mementos.
3) menento


memento pattern은 이전 상태의 객체를 쉽게 저장하는 방법 중에 하나이다.
즉, undo~!! 이전 상태로 돌리는 것이다. 이전 상태로 돌릴려면..어떻게?????
☞ 이전 상태의 오브젝트의 정보를 저장 해야한다.
오브젝트의 정보를 복원하기 위해서는 자유자재로 해당 오브젝트를 액세스 할 수 있어야 할 것이다.
하지만 이런식으로 오브젝트를 리플렉션을 하다가는 캡슐화가 보장받지 못하게 된다.
그래서!! 캡슐화도 보장받고, 저장 및 이전상태로 돌리는(복원) undo를 가능케하는 것이 바로 memento pattern 인 것이다!(멋진데..)
Originator
package kr.pe.acet.memento; import java.util.ArrayList; |
Memento의 역할 이 인터페이스로 할 수 있는 일에는 한계가 있고 내부 상태가 외부에 공개되는 것을 방지한다.
package kr.pe.acet.memento; import java.util.ArrayList; |
Caretaker의 역할
package kr.pe.acet.memento; import static org.junit.Assert.*; import org.junit.Test; public class Caretaker { @Test } |
결과 ==== 0 ==== 1 ==== 2 ==== 3 ==== 4 ==== 5 ==== 6 ==== 7 ==== 8 ==== 9 |
Tip. 스택, 큐 등을 이용하여 히스토리로써 관리할 수도 있다. 또한 serialization을 통해서 파일로 관리하도록 기능을 확장할 수 있다.
마지막으로 요 동영상은 꼭보자!
https://www.youtube.com/watch?v=jOnxYT8Iaoo
참고 사이트 : http://scotty83.tistory.com/entry/Memento-Pattern
참고 사항
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] observer pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] Interpreter pattern
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
2013/12/03 - [Architecture/DesignPattern] - [DesignPattern] command pattern
2013/12/09 - [Architecture/DesignPattern] - [DesignPattern] mediator pattern
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] abstractFactory 패턴
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] flyweight pattern (0) | 2014.01.06 |
---|---|
[DesignPattern] state pattern (0) | 2013.12.31 |
[DesignPattern] memento pattern (0) | 2013.12.16 |
[DesignPattern] mediator pattern (0) | 2013.12.09 |
[DesignPattern] command pattern (0) | 2013.12.03 |
[DesignPattern] observer pattern (0) | 2013.11.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
2013/12/03 - [Architecture/DesignPattern] - [DesignPattern] command pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] observer pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] Interpreter pattern
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] abstractFactory 패턴
<< Mediator Pattern >>
패턴의 의도 : 각 객체가 관련성을 갖는 다른 객체에 대한 참조관계를 직접 정의하기 보다는 이를 독립된 다른 객체가 관리..(-_-;;뭥미?)
즉, 중재한다고 보면 된다^-^
아래의 소스는 비행기를 예를 들었는데 너무 좋은 예인것 같다.
비행기들이 서로 충돌하지 않고 착륙 한다. 어떻게?? 관제탑이 비행기들을 중재하기 때문이다.
즉, 비행기끼리 서로 통신한다면 매우 혼란을 겪게 된다.
ex) 그림을 하나 보자
아래처럼 비행기들 끼리 서로 통신을 한다면 복잡스러울 것이다. 지금은 4대라서 6번이지만..ㅋㅋ
그래서 관제탑을 두어서 관리하면 아래와 같이 깔끔하다. 굳~!
Colleague : Mediator와 통신하는 객체들이라고 생각하시면 됩니다
핵심 문장!! : "Mediator 는 모든 것을 알고 있다+ㅁ+"
즉, tower.land(this); <---Colleague에서 Mediator Pattern의 객체를 받아서 해당 method를 호출 한다.
이미 Mediator는 task가 정해져있고 그 task를 실제로 하는 아이들이 Colleague 들이다.
그런 의미에서 Mediator가 Colleague들을 중재한다고 볼 수 있다.
위를 이해했다면 Facade 패턴과 Mediator 패턴의 차이를 알 수가 있다.
Facade패턴은 창구라고 생각하면 되니 창구안의 객체들을 중재하는 기능은 없다.
하지만 Mediator는 이미 모든것을 정해놓고 Colleague, Mediator와 통신하는 객체들이기때문에 중재를 한다.
헷깔리지 말자~!^-^good~
아래의 소스에서 조금 아쉬운 것은 Colleague가 Interface 구조가 아니라는 것이다. Mediator가 하나 일 수 있지만 Colleague가 여러가지 일 경우가 많을 것이다. 물론 Mediator 또한 Interface로 갈 수 있다.(아래의 소스에 그렇게 해놨다..ㅋㅋㅋ 하지만 의미는 없다는거;;)
암튼 이해하기에는 좋은 소스임에는 틀림이 없다.
UML을 보자! - Class Diagram을 보자. 손수 그렸다..ㅋㅋ;;
또는 아래에는 표현이 되어있지는 않지만 Mediator를 Colleague에서 연관시켜서
setMediator 로 받아서 또 다른 Mediator 사용도 가능하다.
main source
package kr.pe.acet.mediator; public class MediatorMain { /** } } |
colleague source : Airplane
package kr.pe.acet.mediator; public class Airplane extends Thread { public Airplane(ControlTower tower, int seq) { public int getSeq() { @Override |
mediator interface
package kr.pe.acet.mediator; public interface MediatorControlTower { |
concreate Mediator
package kr.pe.acet.mediator; public class ControlTower implements MediatorControlTower{ |
결과 - 쫌 길다..ㅋㅋㅋ
1번 비행기 착륙 시작 |
참고 사이트 : http://iilii.egloos.com/4850510
https://www.youtube.com/watch?v=jWF6dvSr_Pk
- 끝 -
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] state pattern (0) | 2013.12.31 |
---|---|
[DesignPattern] memento pattern (0) | 2013.12.16 |
[DesignPattern] mediator pattern (0) | 2013.12.09 |
[DesignPattern] command pattern (0) | 2013.12.03 |
[DesignPattern] observer pattern (0) | 2013.11.24 |
[DesignPattern] Interpreter pattern (0) | 2013.11.24 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] observer pattern
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] Interpreter pattern
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] abstractFactory 패턴
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
금일은 Command Pattern 에 대해서 스터디를 했네요^^
reo형님이 빠져서 아쉽네요..ㅜㅜ..지못미..
출처 : http://ko.wikipedia.org/wiki/%EC%BB%A4%EB%A7%A8%EB%93%9C_%ED%8C%A8%ED%84%B4
커맨드 패턴(Command pattern)이란 요청을 객체의 형태로 캡슐화하여 서로 요청이 다른 사용자의 매개변수와, 요청 저장 또는 로깅, 그리고 연산의 취소를 지원하게 만드는 패턴이다.
라고~위키피디아에 명시 되어져있습니다.
소스 : command.zip
테스트 코드 : CommandTest.java
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] memento pattern (0) | 2013.12.16 |
---|---|
[DesignPattern] mediator pattern (0) | 2013.12.09 |
[DesignPattern] command pattern (0) | 2013.12.03 |
[DesignPattern] observer pattern (0) | 2013.11.24 |
[DesignPattern] Interpreter pattern (0) | 2013.11.24 |
[첫번째 스터디] abstractFactory 패턴 (0) | 2013.07.21 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] singleton 패턴
2013/07/21 - [Architecture/DesignPattern] - [첫번째 스터디] abstractFactory 패턴
2013/11/24 - [Architecture/DesignPattern] - [DesignPattern] Interpreter pattern
참조 사이트 :
http://ko.wikipedia.org/wiki/%EC%98%B5%EC%84%9C%EB%B2%84_%ED%8C%A8%ED%84%B4
11월 25일 내부 스터디(일명: 용수철 스터디 그룹!)
observer pattern에 대해서 알아보자^^
객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다. 발행/구독 모델로 알려져 있기도 하다.
이 패턴의 핵심은 옵서버 또는 리스너(listener)라 불리는 하나 이상의 객체를 등록하거나 자신을 등록시킨다. 그리고 관찰되는 객체(또는 주제)에서 발생하는 이벤트를 전달한다.
구조는 아래와 같디.
소스 - 패키지는 package kr.pe.acet.observer; 이다~~
소스가 쓰레드 형태라서..JUnit으로는 동작하지 않아서 아쉽다..ㅋㅋ; 사실 동작하지 않는 것인지..동작 못시키는건지...@-@;;
Test 소스
'Architecture > DesignPattern' 카테고리의 다른 글
[DesignPattern] mediator pattern (0) | 2013.12.09 |
---|---|
[DesignPattern] command pattern (0) | 2013.12.03 |
[DesignPattern] observer pattern (0) | 2013.11.24 |
[DesignPattern] Interpreter pattern (0) | 2013.11.24 |
[첫번째 스터디] abstractFactory 패턴 (0) | 2013.07.21 |
[첫번째 스터디] singleton 패턴 (0) | 2013.07.21 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
소프트웨어 아키텍처 이론과 실체
라는 책을 산지..올해 2월에 산것 같은데..제대로 보지를 못했다..ㅠ_ㅠ 채수원님 책은 술술 읽혀서 보았다 다행히..
2013/03/05 - [Life of AceT/Good book] - 소프트웨어 아키텍처 이론과 실제, TDD(채수원)
아직 기초 지식이 부족하여 할 것이 너무나도 많다..(아~내 잃어버린 시간들이여~~진작에 공부를 했어야..쿨럭~)
조금 정리를 하여 조금씩 이라도 볼 생각이다.
사실 잊고 있었는데..홍K(前팀장)님이..자극을 주셨다+ㅁ+~고오오오오오~
좋은 자료도 주시고..흐흐+ㅁ+흐흐흐~나만 봐야디~
자!~ 책의 구성은 총 4부로 되어있다. 혼자보기에는 엄청 힘들 것 같기도 하다..ㄷㄷㄷ
1부. 아키텍처의 개요
1장) 아키텍처 비즈니스 사이클
2장) 소프트웨어 아키텍처 정의
3장) A-7E 항공 전자 시스템
2부. 아키텍처 수립
4장) 품질속성 이해
5장) 품질 목표 달성
6장)항공관제 시스템
7장) 아키텍처 설계
8장) 비행 모의실험
9장) 아키텍처 문서화
10장) 아키텍처 재건
3부. 아키턱처 분석
11장) ATAM
12장) CBAM
13장) 월드와이드웹
4부. 아키텍처 확산
14장) 소프트웨어 프로덕트 라인
15장) 셀시우스테크
16장) J2EE/EJB
17장) 루더 아키텍처
18장) 기성 컴포넌트를 활용한 시스템 구축
19장) 소프트웨어 아키텍처의 미래
'Architecture > AA' 카테고리의 다른 글
메시지큐에 대해 알아보자. (0) | 2017.06.27 |
---|---|
SOLID (object-oriented design) (0) | 2014.02.26 |
[소프트웨어 아키텍처 이론과 실체] 아키텍트로 가기 위한 필독서!! (0) | 2013.11.24 |
DTP(Distribution Transaction Processing) 관련 자료 (0) | 2013.06.08 |
ACE-T의 아키텍트 이야기 (0) | 2013.01.28 |
AA란? (0) | 2012.11.12 |