Job Flow의 소개

Job Flow와 관련 된 다른 포스트

• http://ryulib.tistory.com/342

• http://ryulib.tistory.com/163

• http://ryulib.tistory.com/164

• http://ryulib.tistory.com/166

• https://www.delmadang.com/community/bbs_view.asp?bbsNo=3&bbsCat=0&st=S&keyword=job%20flow&indx=430697&keyword1=job&keyword2=flow&page=1

 

 

▶ 만든계기

Job Flow는 1995년 여름 어느 날 델파이 프로젝트를 진행하던 중, 객체간의 메시지 흐름만을 명확하게 도식해 보려는 시도를 통해서 만들어진 문서형식입니다.

 

 

▶ 모듈별 분업화에 이르는 길

절자적 프로그래밍으로도 모듈화는 가능합니다.  예를 들어 델파이의 유닛참조나, C 언어의 include를 통해서 프로그램의 일부분을 라이브러리라는 모듈로 나눠서 작성하면 됩니다.  하지만, 모듈별 분업화에 있어서, OOP와 절차적 프로그래밍 사이에는 커다란 차이가 있습니다.  아래의 차이점을 이해하지 못한다면,  단순히, Class를 사용한다고 객체지향적 프로그래밍을 한다고 할 수는 없습니다.

• 인터페이스 분리 vs 코드 분리
• 코드 분리를 통한 모듈화에서는 의존성에 대한 코드를 격리시켜서 변화에 대비할 수가 없습니다.
• 의존성과 전혀 관련이 없는 함수와 루틴을 은닉할 수 없습니다.  (Class의 private method와 비교됨)
• 코드 분리를 통한 모듈화에서는 데이터를 은닉할 수 있는 방법이 없습니다.
• Event 중심 개발 vs Flow 중심 개발
• Flow 중심으로 개발하게 되면, 다른 객체의 변화를 필요 이상으로 감시해야되는 문제가 발생합니다.
• 나의 변화는 Event를 통해서 누군가에게 알려줬다는 사실만 기억할 수 있으면 됩니다.
• 다른 객체의 변화는 해당 객체의 Event를 구독하겠다는 신청을 한 것으로 감지할 수 있어야 합니다.

 

 

▶ 인터페이스 분리란?

다음 코드에서 우리가 알 수 있는 것은 무엇일까요?

[code delphi]
type
  TClock = class(TObject)
  private
  public
    procedure Start; virtual; abstract;
    procedure Stop; virtual; abstract;
  end;
 
var
  Clock : TClock;
 
begin
  Clock := TClock.Create;
  Clock.Start;
[/code]

위의 코드만으로는 당연히 에러가 납니다.  Start라는 메소드가 구현되지 않았기 때문입니다.

 

아래의 코드는 어떻습니까?

[code delphi]
type
  TClock = class(TObject)
  private
  public
    procedure Start; virtual; abstract;
    procedure Stop; virtual; abstract;
  end;
 
  TDigitalClock = class(TObject)
  private
  public
    procedure Start; override;
    procedure Stop; override;
  end;
 
var
  Clock : TClock;
 
begin
  Clock := TDigitalClock.Create;
  Clock.Start;
[/code]

코드가 완전하지는 않지만, override를 통해서 해당 메소드가 구현된 부분이 동작하게 될 것이라 추측할 수가 있습니다.  이를 통해서 우리가 얻을 수 있는 것은, 이후 어떠한 동작을 하는 시계 클래스를 만들더라도 사용법은 Start, Stop으로 동일합니다. 라는 보장을 받을 수 있다는 것 입니다.  즉, 이제 구현과정이 아무리 복잡하고, 변화가 심해도 그것은 이것을 사용하는 다른 코드(객체)에는 전혀 영향을 줄 수 없다는 확신이 생긴 것 입니다.

 

 

▶ 절차 중심적 사고와 Event 중심적 사고의 차이

[그림 1] 절차 중심적 사고와 Event 중심적 사고의 차이

 

[그림 1]은 같은 상황을 절자 중심적으로 설계된 과정과 Event 중심적으로 설계된 과정을 Job Flow로 도식화 한 것 입니다.

 

그림의 윗쪽의 상황은

• 클라이언트가 서버에 접속하면 암호화에 필요한 키를 받게되고
• 게임 모듈에서는 사용자가 프로그램을 조작했을 때 발생하는 이벤트를 명령어로 변환하여 소켓을 통해서 서버로 전송하게 됩니다.
• 만약 소켓이 아직 서버에 접속 중이면서 아직 키를 받지 못한 때에 명령어를 전송할 수가 없습니다.
• 전송하기 전에 Key값을 받았는 지 점검하고, 받지 않았으면 키값을 받을 때까지 반복하면서 기다립니다.
• 전송되는 명령어는 암호화되어서 서버로 전송됩니다.

그림 아랫쪽의 상황은

• 클라이언트가 서버에 접속하면 암호화에 필요한 키를 받게되고
• 이때, 이벤트를 통해서 상황을 알아야할 객체에게 알려주게 됩니다.
• 게임모듈은 클라이언트 소켓이 키를 받아서 사용할 수 있게되었다는 이벤트를 받습니다.
• 게임모듈은 해당 이벤트가 발생하면 자신을 Enabled 될 수 있도록 합니다.
• 명령어 전송이 키를 받기 전에 이루어지지 않도록 방어하는데 루프를 반복할 필요가 없습니다.

 

 

▶ Job Flow의 작성 목적

 

▶ 기능

 

▶ 작성법

 

 

Codeway.vss