Flow] Condition 만들기 - 비지터 패턴응용...
플젝하면서 이번에 처음보는 개발 프레임웍이 멋져...
코딩양은 많아보이지 않는데 하나 하나 연결? 이 필요하여 이걸 프로그램으로 맞춰버리려고 사용할 툴을 만들고 있다.
프로그램 흐름을 미리 만들어놓고 각각 흐름내에서 배치되는 화면들을 템플릿으로 구성한 후에
실제 디자인이 나오면 하나씩 바꿔가는 건데 기본 흐름은 xml로 이뤄지니까
흐름만 만들어 두면 개발이 엄청 편할 것?같은??? ...
일부 xml코드가 시각화 도우미에 있는 구조처럼 나오는 파일이 있는데, 이 파일을 UI 프로그램을 이용해서
직관적으로 디자인하고 코드로 변환하는 프로그램을 만들고 있다.
비지터 패턴을 이용하여 세가지 객체를 저런 형태로 변환한다.
cvp.Visit( 대상 );
원래하려던 xml제작 코딩은 이제 UI로 편하게... 기본틀을 만들고 나머진 손코딩해야지.
더 깊이 들어가면... 배보다 배꼽이 된다. 딱. 이 기능까지만 넣으면 된다...
UI를 통해 조금더 쉽게.. 입력할수 있는 방법을 고려중인데... ( 이미 결정은 했음. )
주말 코딩해서 월요일 또 핸드폰 보며 옮겨야겠군...
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
Commad? 응용... (0) | 2012.01.19 |
---|---|
비지터 패턴... (0) | 2010.05.06 |
콤포지트 패턴... (0) | 2010.05.06 |
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
체인 패턴... (0) | 2010.05.04 |
옵져버패턴
옵져버에 대해 글을 남기게 되었다. 최근 다시 디자인 패턴을 보게 되었는데, 다른 패턴들은 그저 확인정도지만,
옵져버는 그동안 긴가민가! 했던 패턴이라 다시 자세히 보게 되었다.
모니터링을 만들때 각 서버에 데이타 수집받으며, 데이타를 챠트로 표시하는곳, 표시박스에 표기하거나
라인색을 표시하거나 하는 곳으로 모두 전달했는데, 여기 사용하던 패턴이 잘 못 적용되었다. 옵져버 패턴을 제대로
이해 못하고 만든거라서 설계에서 꼬여버린 케이스같다.
음... 처음 컨셉은 저랬는데... 옵져버 패턴을 잘 못 적용했넹...
동작은 되지만... 옵져버가 서로 뒤바꼈던것 같다.
데이타객체가 바뀌면 관련 객체를 업데이트 한다였는데... 소스는 좀 꼬였던것 같고..
간략하게 옵져버 패턴용 소스를 만들어봤다. 이젠 혼란스럽지 않겠지..
public interface IData
{
void Add(IHandler handler);
void Remove(IHandler handler);
void Notify();
}
public interface IHandler
{
void Update();
}
public class DataObject : IData
{
List<IHandler> handlers = new List<IHandler>();
public void Add(IHandler handler)
{
handlers.Add(handler);
}
public void Remove(IHandler handler)
{
handlers.Add(handler);
}
public void Notify()
{
foreach (IHandler h in handlers)
{
h.Update();
}
}
string text { get; set; }
public string Text { get { return text; } set { text = value; Notify(); } }
}
public class View : IHandler
{
static int Number = 0;
int No = 0;
public View()
{
No = Number++;
}
public DataObject Sv { get; set; }
public Control HostControl { get; set; }
public void Update()
{
if (HostControl != null && Sv != null) HostControl.Text = No+"]"+ Sv.Text;
}
}
// 사용
DataObject sv = new DataObject();
// 등록
sv.Add(new View() { Sv = sv, HostControl = label1 });
sv.Add(new View() { Sv = sv, HostControl = label2 });
sv.Add(new View() { Sv = sv, HostControl = label3 });
// 상태 업데이트 발생 이벤트 시점!
sv.Text = "가나다";
Commad? 응용...
오늘 작업중에 ERP에서 그룹웨어 전자결재관련 링크 콜! 하는 부분에 대한 작업을 하였음.
프레임웍 쪽은 내가 관여할 부분이 안되므로... 단순한 코딩보다
그룹웨어 관련 명령을 관리할수 있는 걸 만들어두면 추후 좋지 않을까 해서 ...
작업을 시작하였음. 코드는 기록 못하니... 패턴 형태만 기록함.
우선 Event에 대한 동작은 기능에서 제외했다.( 객체사용에 있어서 이벤트까지 필요없는 것임. )
구현에 있어 떠오른 패턴은 커맨드패턴이다. 약간의 변형을 시켜 만들어 보았다.
#그룹웨어 관련 데이타 인터페이스
_. 멤버1
_. 멤버2
_. 멤버...
_. 멤버 유효성체크();
#그룹웨어 명령 열거형
_. 쓰기
_. 읽기
#그룹웨어 헬퍼 : 데이타 인터페이스
_. static 쓰기명령.Execute( 데이타인터페이스 )
{ 데이타인터페이스.Validate( 쓰기 );
데이타처리( 쓰기, 데이타인터페이스 ); }
_. static 읽기명령.Execute( 데이타인터페이스 )
{ 데이타인터페이스.Validate( 읽기 );
데이타처리( 쓰기, 데이타인터페이스 ); }
_. static 데이타처리( 명령열거형, 데이타인터페이스 )
{ ToDo: 작업... }
_. static 버튼제어( 대상버튼..., 상태값1, 상태값2.... ) //오버로딩.
{ 상태값들 별로 대상버튼 제어... }
이렇게 해두면 읽기, 쓰기 에 각각 데이타를 활용할 수 있게 만들고, 또다른 명령이 필요하면
명령열거형에 새명령 추가.
데이타에 유효성체크에 새명령에 대한 코드 추가.
헬퍼에 새명령 메서드 추가.
헬퍼에 버튼제어에 로직 추가.
이렇게 처리가 가능하다.
실제 사용할때는 !!!
# 데이타 조회
1. 그룹웨어헬퍼 인스턴스에 데이타 셋팅!
2. 그룹웨어헬퍼 인스턴스.버튼제어( 대상버튼..., 상태값1, 상태값2.... )
# 쓰기명령
1. 그룹웨어헬퍼.쓰기명령.Execute( 그룹웨어헬퍼 인스턴스 );
# 읽기명령
1. 그룹웨어헬퍼.읽기명령.Execute( 그룹웨어헬퍼 인스턴스 );
단 몇줄로 쉽게 구현이 가능하고 프레임웍 내에 귀속된다고 했을 시 어떨까?
_ 내 생각엔....
장점.
1. 역할이 분명하고, 헬퍼 자신이 가져야 할 데이타가 무척 제한적일 수 있다.
_. 그룹웨어와 관련된 데이타에 대해 제한을 둘수 있다.
erp와 그룹웨어와의 경계를 만든다.
2. 따라 처리 로직을 쉽게 찾을수 있고 새명령코드를 만들때 쉽다.
_. 실제 많은 명령을 만들어봐야 어떤지가 나올 것 같다.
유효성체크는 항상 고민이다... 추후 이녀석에 대해 써볼 예정임.
3. 담당 개발자가 작성할 소스를 줄일 수 있다.
_. 굉장히 중요하다고 생각함. 솔루션에서 유지보수를 힘들게 하는 것으로는
일정에 대한 압박으로 코드 자체를 휘저어 놓는 것인데...
( 나랑은 좀 먼 얘기? 난 일정마감이 와도 내맘대로.. 시간이 많아도 내맘대로... 고쳐야 할 습관이기도 함... )
_. 유지보수를 하는 입장에서의 소스 버젼이 다른 것들에 대해서는 참 접근이 쉽지 않다는 것이다.
특정 기능이 필요한 시점에서 정말 단발성이냐 아니냐에 따라 클래스 생성여부를 결정하는 나로써는...
이번 그룹웨어헬퍼는 사용하는 페이지가 7이었고. 동일한 데이타구조와 함께 그 기능이 동일하기에
클래스로 특화 시켜놓았다. 그리고 주석을 붙여놓았는데...
단점.
1. 동작에 대한 문서가 상세하게 작성되어야 한다.
음 난 정말 상세하게 적어두려고 읽기 좋도록 만들어보려고 노력은 하는데... 어렵다...
정리된 문서 읽는 것도 긴글들은 벅차다.
2. 이러한 패턴에 대해 유지보수 개발자는 이해하고 있어야 한다.
UI담당 개발자가 추가적인 확장이 어렵다. 곧, 헬퍼 외부에 코드를 남발해야 한다.
( 이는 프레임웍 담당 개발자가 확장시켜주면 되는데... )
3. 아무래도... 이게 실제 프레임웍을 소유하고 있는 개발자에게 부담이 되지 않을까?
남의 소스를 반가워 할 개발자는 그리 많치 않을테니..
이렇게 정리 해보았다.
퇴근중에 간단히 몇가지 생각해보니... 위 패턴은 내가 2.0프레임웍 만들때
비지니스 로직을 구현하던 중 유사하게 나타난 것이였다.
다음엔 디자인 패턴 몇개를 골라서 닷넷이 가진 매력을 뽐내볼까나...
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
Flow] Condition 만들기 - 비지터 패턴응용... (0) | 2018.04.27 |
---|---|
비지터 패턴... (0) | 2010.05.06 |
콤포지트 패턴... (0) | 2010.05.06 |
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
체인 패턴... (0) | 2010.05.04 |
비지터 패턴...
쉽다면 쉽고.. 어렵다면 어려운 패턴이었음. 아직도 가끔은 헷갈리는데...
예제로 본것들중 기억에 남는것은 기자가 각 방송국을 들락 날락 거린다는 예제였던것 같다.
콤보짓 없이 비지터를 살짝쿵.. 비스므리 해보려 했더니... 좀..골때린게 나왔다. 의미상 별거 없어보이긴 하는데..
어쨌거나 저쨌거나..
방문자(Visitor)는 자기가 방문하게될 요소(Ac)에 자기를 등록하도록 Acceptor(방문자 v); 가 요구되고 이를 인터페이스로 구현된다.
이 인터페이스를 통해 방문자의 .Visit( 요소 )를 호출하면서 구조(자료리스트)를 순회 하게 된다.
단순하게 생각하자!!
방문자는 방문하게될 대상에 자기가 들어갈 곳을(Acceptor) 요구하고 이를 통해 자기가 들어가서
방문(Visit())을 하게 되며 대상요소에 대한 처리는 Visit() 내에서 처리한다!!..
소스를 보자.. 말로는 역시 풀어내는것은 아직 표현부족으로 한계....
추가: 방문자의 문제 처리를 바꾸고자 한다면
간단히 짝수 출력라인 주석을 하면 홀수만 보이게된다... 일이 구분된다는 것이지.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Ac a1 = new Ac("a1"); // <== 각 요소들...
Ac a2 = new Ac("a2");
Ac a3 = new Ac("a3");
Ac a4 = new Ac("a4");
Ac a5 = new Ac("a5");
Ac a6 = new Ac("a6");
Ac a7 = new Ac("a7");
Ac a8 = new Ac("a8");
Ac a9 = new Ac("a9");
Ac a10 = new Ac("a10");
a1._ac = a10; <-- 하위 요소들 추가!!
a10._ac = a4;
a5._ac = a7;
List<Ac> ls = new List<Ac>(); // <-- 비지터가 방문하게될 리스트...
ls.Add(a1);
ls.Add(a2);
ls.Add(a3);
ls.Add(a5);
ls.Add(a6);
ls.Add(a8);
ls.Add(a9);
Visitor v = new Visitor();
foreach( Ac item in ls )
v.Visit(item); // <--- 각각 방문하게 된다.
this.textBox1.Text = v.ToString(); // <-- 방문결과...
}
}
public interface IVisitor
{
void Visit(Ac ac);
}
public interface IAcc
{
void Acceptor( IVisitor v);
}
public class Ac : IAcc // <-- 방문하게 될 대상 객체이다.
{
static int InstanceCount = 0;
static void Count() { InstanceCount++; }
int _i = 0;
public Ac _ac = null;
// <-- 하위 요소가 존재시... 방문자가 순회 하게 될.. 요소로 판정하기 위해... ( 콤포짓 패턴... )
public int I
{
get { return _i; }
}
string _name = "";
public Ac(string __name)
{
Count();
_i = InstanceCount;
_name = __name;
}
#region IAcc 멤버
public void Acceptor(IVisitor v)
{
v.Visit(this); // 비지터에 AC자신에 대한 처리를 맡긴다.
}
#endregion
public override string ToString()
{
return _name;
}
}
public class Visitor : IVisitor //<-- 방문자...
{
StringBuilder sb = new StringBuilder();
public void Clear()
{
sb.Remove(0, sb.Length);
}
#region IVisitor 멤버
public void Visit(Ac ac) //<-- 방문될 요소를 받는다.
{
if( ac.I % 2 == 0 )
{
sb.AppendLine(" "+ac.ToString()+"(짝수)");
if (ac._ac == null) sb.AppendLine();
}
else
{
sb.AppendLine(" " + ac.ToString() + "(홀수)");
if (ac._ac == null) sb.AppendLine();
}
if (ac._ac != null)
{
ac._ac.Acceptor(this);
//<-- 하위 요소가 존재시 방문등록을 한다.
이로써 방문자는 다시 하위 요소에 자기가 등록되면서 visit가 재귀형태로 호출된다.
}
}
#endregion
public override string ToString()
{
return sb.ToString();
}
}
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
Flow] Condition 만들기 - 비지터 패턴응용... (0) | 2018.04.27 |
---|---|
Commad? 응용... (0) | 2012.01.19 |
콤포지트 패턴... (0) | 2010.05.06 |
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
체인 패턴... (0) | 2010.05.04 |
콤포지트 패턴...
움... 이 패턴을 첨 접할때 Tree라는 개념을 알고 본터라.. 가장 처음 접했던 어려운 패턴이었다.
단순해보이면서도 왠지... 거북했던 패턴으로 기억나는데...
가장 최근에 적용하고 사용한 방법중에 XmlHelper를 만들때
각 Element를 메모리에 올리기 위한 자료구조를 만들때 사용했었다.
Element를 받고 하위 Element를 동일한 타입으로 설정하고 추가 추가...
재귀를 통해 읽어들이고 각각 요구사항에 맞춰 파싱도 하고 출력도 하고...
단위객체
{
단위객체[] 하위List;
Print()
{
"<자기자신>"
foreach( 단위객체 obj in 하위List )
obj.Print()
"</자기자신>"
}
}
대략...이랬다...
사용방법은 꾀 많다.
트리구조를 가지고 있는 자료구조에 적용하기 쉽기때문에...랄까?
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
Commad? 응용... (0) | 2012.01.19 |
---|---|
비지터 패턴... (0) | 2010.05.06 |
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
체인 패턴... (0) | 2010.05.04 |
커맨드패턴 (0) | 2010.05.03 |
객체를 공부하면서... 커플링? 느슨한결합도?
요즘 공부를 하면서 객체간에 커플링과 느슨한결합도에 대한 다시한번더 생각하게 된다.
내가 주도하는 프로젝트에서야 내가 만든 프레임웍등을 이용할때나 위... 커플링과 느슨한결합도에 신경을 쓸까..?
프리형태의 입장인 지금은 저딴건 개나 줘버렷!!
지금껏 하루 하루 시간 쪼개서 공부해온 것들은 모두.. 내가 주도하거나 내가 주축이 되면.. 가능한것들 뿐이다.
SW공학.. 자체가 비전공자인 내가 공부해봤자라는 의미가 될수 있는듯 하다.
물론 알아두면 좋고 알아야 하는것이기도 하고... 물론 몰라도 돈버는데는 영향이 없어보인다.
객체와 객체를 연결지으면서 서로간에 간섭이 얼마나 일어나느냐를 커플링 척도로 보는데 이는 프리로 일하면서
관심밖에 사항이 된다. 결합도 역시.. 그렇다.
느슨하게 해주는 주체가 무엇이 될까? 인터페이스? 추상화된 기반객체?
음... 그렇다면... 내가 주가 되었을때의 이 개념들을 어떻게 써먹을지도 고민해봐야 하는데...
얼마전 완성된 프레임웍은 내부적으론 유지보수에 대한 대비를 많이 했지만.. 실제 사용에 있어서의 결합도는 거의 무시한채 작업이 되었는데... 이건 어떻게 한다?
객체가 객체를 사용하는데 있어서 직접적이 호출이 아닌 중간에 하나를 거쳐서 호출하게끔하여 실제 호출되는 객체의 변화에 조금 덜 반응할수 있도록 맞춰주는것이 결합도를 낮춰주는 방법이라고 난 생각한다.
개발자와 개발자간에 직접적인 업무교류가 아닌 중간에 PL을 거쳐 협업을 하는것 처럼... 이랄까? 비유가 좀 아닌가?
아무튼.. 사용자는 실제 호출되는 객체에 대해 모르는 편이 좋다고 본다. 곧 블랙박스가 된다.
알아야 하는것은 인터페이스.. 정도? 기반클래스에서 제공되는 메서드와 프로퍼티?랄까?
현재의 프로젝트는 인터페이스 기반에 호출이 아닌 해당 객체를 직접 호출하는 형태이다.
또한 객체를 생성하는데 있어서.. 해당 객체를 직접 생성하고 있는데 이를 분리하는것이 곧 생성패턴들을 이용 하는것인데
그런것도 없어보이고...
느슨함과 커플링에 대한 생각은 좀더 찾아보고 고려해보아야 할 것이다.
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
비지터 패턴... (0) | 2010.05.06 |
---|---|
콤포지트 패턴... (0) | 2010.05.06 |
체인 패턴... (0) | 2010.05.04 |
커맨드패턴 (0) | 2010.05.03 |
디자인 패턴 설명이 정말 쉬운곳... (0) | 2010.03.16 |
체인 패턴...
뭐 볼꺼 있나... 요약하자...
문제 -- 해결책 따로 따로 매칭시켜서 처리 해보자..
어떤 문제들을 해결할수 있는 방법 1,2,3,... N 개가 존재할시 이 해결법들을 하나로 묶어 관리 하며
제시되는 문제들을 받았을때 이 문제를 해결할수 있는놈이 처리하자!! 라는 취지임.
없으면 말고.. 라는? ㅋㅋ
문제1 : 문제, 문제 2 : 문제, 문제3 : 문제, 문제4 : 문제, 문제n : 문제...
해결법1 : 해결 . 해결법2 : 해결 , 해결법3 : 해결 , 해결법4 : 해결 ... 해결법n : 해결 .
해결 { 해결 Next; setNext( 해결 ); 풀이( 문제 ); 내꺼( 문제 ); }
이렇게 따로 따로 분리하여 각 해결법과 문제를 볼수 있게 된다.
해결법1.setNext(해결법2).setNext( 해결법3 )... <-- 체인 처럼. 각각 연결을 시켜둔다.
해결법1.풀이( 문제1 );
해결법1.풀이( 문제2 ); ...
풀이 내부에서는 자기가 풀수 있는 문제인지 체크하고 풀거나 또는 다음으로 넘겨준다.
이런 순서라는거쥐... 문제는 이것도 지식이되고 만다는거...
어따 써머거? 음... 어따 써먹을지 찾아보자. 전에 뭔가 하다가 써먹으려다 실패했었다.
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
콤포지트 패턴... (0) | 2010.05.06 |
---|---|
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
커맨드패턴 (0) | 2010.05.03 |
디자인 패턴 설명이 정말 쉬운곳... (0) | 2010.03.16 |
패턴을 써서 좋은점... (0) | 2010.02.17 |
커맨드패턴
명령 자체를 객체로 만든다 라는 개념인데 잘 보면 어렵진 않고...
다만 이걸 어따 써먹느냐..가 관건인듯 하다.
늘 그렇듯이 쌓아올린 지식은 지혜로 바꾸어내야만 한다. 써먹을수 있는 지식을 많이 가지는 것이 곧 내가 지향하는 목표가 아닌가..
프로그래밍에 대한 전반적인 지식들은 인터넷, 서적등으로 얼마든지 취할수 있으나 이것을 써먹지 못하면... 알아서 뭐하겠는가?
간단히 커맨드패턴을 요약하자면..
1. 명령{ 수행() }
2. 수행객체{ 수행할일(); }
1 + 2 . 명령처리객체 : 명령
{
수행객체 ;
수행() { 수행객체.수행()}
}
3. 요청처리객체
{
명령;
수행(){ 명령.수행() }
}
보통의 객체와 객체사이의 메세지 전달구조에서는 객체와 객체간에 메세지를 공통으로 사용하기 위해서 Interface를 사용하는데 단일 메서드 일때는 그냥 호출해도 되지만 한번에 호출될 메세지가 많을때 이를 캡슐화 할때 이용할수 있다.
예제로 본 문서에는 전사, 법사, 힐러 같은경우를 예로 들고 있다
Attack() 공격시 전사가 취하는 행동, 법사가 취하는 행동, 힐러가 취하는 행동이 각각 다르지만. Attack()이란 명령으로 통합관리 할수 있고 이를 커맨드패턴을 이용하는 기법에 대해 설명하고 있다.
1.
명령 { Attack() }
2.
전사{ 준비자세(); 칼을 든다(); 후려친다(); 준비자세(); }
법사{ 준비자세(); 책을 편다(); 스킬시전한다(); 준비자세();}
...
1 + 2.
전사명령처리 : 명령 {
전사;
Attack()
{
전사.칼을든다();
전사.후려친다();
전사.준비자세();
}
3. 캐릭터명령
{
명령 :
SetCmd( 명령 );
Attack(){ 명령.Attack(); }
}
전사 워리어 = new 전사();
명령 cmd = new 전사명령처리( 워리어 );
캐릭터명령 cCmd = new 캐릭터명령( );
cCmd.SetCmd( cmd );
cCmd.Attack();
뭐 이런식이라는데...
명령을 객체화 하여 실제행동에 사용되는 객체와 명령을 요청한 객체간 관계를 느슨하게 만들어주는... 역할을 한다.
느슨하게!! 라는것에 대한 생각을 해볼필요가 있어보인다.
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
---|---|
체인 패턴... (0) | 2010.05.04 |
디자인 패턴 설명이 정말 쉬운곳... (0) | 2010.03.16 |
패턴을 써서 좋은점... (0) | 2010.02.17 |
디자인 패턴에 관하여... (0) | 2010.02.17 |
디자인 패턴 설명이 정말 쉬운곳...
디자인 패턴 Java로 설명된 곳
말이 필요없음.. 우선 가서 보는게...
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
---|---|
체인 패턴... (0) | 2010.05.04 |
커맨드패턴 (0) | 2010.05.03 |
패턴을 써서 좋은점... (0) | 2010.02.17 |
디자인 패턴에 관하여... (0) | 2010.02.17 |
패턴을 써서 좋은점...
패턴을 쓰면 좋은점에 대해 안쓴듯 하여 조금더 써보도록 한다.
결론부터 말하자면 유지보수 관점으로 객체를 설계해야 할경우 패턴을 이용하면 유지보수 관련 포인트를 다수 축소시킬수 있게 된다.
아래 간단한 예를 들어본다.
프로그래밍 작업은 곧 데이타 객체들을 조립하여 하나의 프로그램을 만들어내는 것이다. 조립된 형태에 따라 유지보수를 어떻게 할수 있는지가 판가름 나는 것 같다.
보통 객체를 생성할때는 특정 객체(Form or UserControl or Class)에서 new 예약어를 통해서 객체를 생성하는데
class {
ClassType cObject = new ClassType();
}
형태로 객체를 생성하게 되었을시 해당 객체를 특정사유에 의해 변경하고자 하는 경우 위 소스에서는 선언한 타입과 생성타입 모두 찾아 바꾸어야 한다.
물론 Visual Studio를 이용하면 바꾸는 것도 나름 쉽게 바꿀수 있겠으나 이를 바꾸면서 발생할수 있는 오류에 대한 접근 포인트가 많아 질것이다. 또한 해당 객체를 사용하는데 있어서 메서드등이 특정객체에 종속되는 경향이 있으므로 이 또한 객체와 객체간에 결속력이 강해져서 떼어낼 수 없게 된다. 지금까지 작업들을 보면 떼어낼 일이 거의 없었다. 앞으로도???
위와 같은 문제애 대한 해결책으로 Interface나 추상객체를 만들어 상속을 통해 객체를 정의 하고 생성하는 경우 선언한 타입이 공통분모가 되면서 바뀌므로 생성타입에 대한 유지보수 관련 포인트가 남게 된다.
생성타입 객체가 자주 쓰여지는 객체일시 여전히 많은 부분이 손길을 기다리게 되므로 이를 더욱더 축소하기 위한 방법으로
생성패턴을 고려해볼수 있다.
Factory 패턴으로 하자면
공통타입 = Factory.Create("타입1"); 으로 생성된 객체를 받게 될시엔 사용하는곳 에서의 손볼곳은 거의 없다.
생성하는 위치 곧 Create( string TypeName) 이란 메서드 내부 구현에서 생성되는 객체에 대한 부분만이 유지보수꺼리로 남아 있게 된다.
단, 주의 할점은 공통타입이 제공하는 메서드 또는 프로퍼티가 생성되는 객체에 모두 적용되어 있어야 하고 또 사용하는 부분이 객체마다 다를수 있기때문에 이에 대한 정의가 충분히 고려되어야 한다. 이는 추상화 또는 가상메서드를 이용하고 이를 오버라이드 하는 방법으로 해결할수 있다. 여기서 객체의 크기에 대해서는 고려하지 않겠다.
또는 Singleton 패턴으로
특정객체 = Singleton.GetInstance(); 해서 사용하는 경우도 있는데 싱글톤인 경우는 객체 자체를 유일한놈으로 보고 만들기때문에 이 객체에 대한 접근할수 있는 부분을 최소화 하는 방법이 주요하다.
DB와 직접 연결되는 통로를 담당하는 객체에 사용해보거나 DebugView용 Form에 적용도 해보았다.
또 Builder 라는 패턴으로
객체를 생성하는데 있어서 객체들을 조립하는 형태로 만들어내는 패턴이다.
또 자기 상태를 View객체에 직접 알림으로써 변경사항등에 대한 다른 처리등을 유도할수 있는 옵져버,
계층구조를 가지는 데이타를 처리할수 있는 콤보짓트, 비지터, 체인등등...
어차피 유지보수를 할꺼면 초기 개발에서 좀더 고민하고 고려해서 유지보수 포인트를 줄이는데 힘쓰는게 비용측면에서나 정신적으로나 좋다고 볼수 있다.
디자인 패턴이란 프로세스를 만들어내기 위해 필요한 객체들을 어떻게 배치하고 조립하느냐에 따른 기술에 대한 명칭일뿐이다. 패턴을 몰라도 이미 사용중에 있을것이며 주로 사용하는 패턴에 대해서 옛날 개발자들이 이름을 붙여놓은 것이다.
남용하지 말고 적제적소에 쓰면 좋을것이고 또한 사용된 패턴들에 대해 알아야 다른 개발자가 구현한 소스들을 볼수 있게되니 꼭 공부해두는게 좋을듯 하다.
'# 5) 디자인패턴(for .NET )' 카테고리의 다른 글
객체를 공부하면서... 커플링? 느슨한결합도? (0) | 2010.05.04 |
---|---|
체인 패턴... (0) | 2010.05.04 |
커맨드패턴 (0) | 2010.05.03 |
디자인 패턴 설명이 정말 쉬운곳... (0) | 2010.03.16 |
디자인 패턴에 관하여... (0) | 2010.02.17 |