우리들이 애플리케이션을 개발할 때 상당히 많이 사용하는 패턴중의 하나가 Singleton Design 패턴일 것이다. 그러나 Singleton 패턴은 다음과 같은 문제를 일으킨다.

• Singleton 클래스에 대한 의존관계는 다른 많은 클래스들 속에 하드코딩 되어야 한다.
• Singleton은 그 자신의 설정을 처리해야 한다. ( 잘 이해가 되지 않는 부분이다. )
• 복잡한 애플리케이션은 많은 Singleton을 갖는다. 각각은 그것의 설정 로딩을 서로 다르게 할 것이다. 이는 설정을 위한 중앙 Registry가 없음을 의미한다.
• Singleton은 인터페이스와 친밀하지 않다. 이것은 매우 좋지 않은 일이다. Singleton이 인터페이스를 구현하게 만드는 것은 권장되지 않는다. 왜냐하면, 그 후에 해당 인터페이스에 대한 다른 구현들을 막을 방법이 없기 때문이다. Singleton의 일반적인 구현은 인터페이스가 아닌 클래스에 타입을 정의하는 것이다.
• Singleton들은 상속에 잘 따르지 않는다. 왜냐하면, 특별한 클래스에 코딩을 할 필요도 없을 뿐 아니라, 자바는 Static method들의 overriding을 허용하지 않기 때문이다.
• Singleton의 상태를 Runtime시에 일관성 있게 갱신하는 것은 불가능하다. 각 Singleton이나 Factory 클래스들에 있어서의 Concurrent 갱신 시도는 무작위의 순서로 적용될 것이다. 애플리케이션 내의 모든 Singleton들의 상태를 재생할 방법은 전혀 없다.

Singleton Design 패턴의 단점을 극복하기 위하여 Rod Johnson은 다른 객체의 인스턴스를 관리하는 하나의 Registry를 가질 것을 추천하고 있다. 이 인스턴스 관리는 전담하는 객체를 Application Context라고 부른다. 이 방법의 장점은 다음과 같다.

• 인터페이스와 잘 동작한다. Singleton이 필요한 객체들이 구현 클래스에 대한 알 필요가 없다.
• 모든 객체들은 일반 자바 클래스들이고, 상속을 일반적으로 사용할 수 있다. 여기에는 어떤 static 변수도 없다.
• 설정은 클래스 외부에서, 그리고 전체적으로 프레임워크 코드에 의해서 다루어진다. Context 객체는 각 Singleton들을 인스턴스화하고 설정하는데 책임을 진다. 이것은 자바 코드 외부에서의 설정(XML문서나 RDBMS 테이블등을 이용한)이 사용될 수 있다는 것을 의미한다. 그런 설정은 객체들이 빈즈 속성을 공개하는 것만으로도 애플리케이션 Context에 의해 다루어지는 객체들 간의 객체 그래프 생성을 가능하게 하는 기능을 포함하게 된다.
• Context 객체는 인터페이스를 구현할 것이다. 이것은 코드 변경 없이도 서로 다른 구현들이 서로 다른 소스들로부터 설정을 가져올 수 있게 한다.
• Singleton들의 동적인 상태 변경이 가능하다. Context는 재생될 수 있고, 그것이 관리하는 객체들의 상태를 변경시킬 수도 있다.(물론 여기에는 Thread Safe 이슈에 대한 고려가 있어야 한다.)
• Context 객체를 사용하는 것은 다른 가능성들을 열어준다. 예를 들면, Context는 독립적인 객체 인스턴스들을 위한 Factory로서 동작하는 Prototype Design 패턴의 구현같은 다른 서비스들을 제공할 수도 있다. 많은 애플리케이션 객체들이 그것에 접근할 수 있기 때문에, Context 객체는 Observer 설계 패턴의 이벤트 제공자로서 동작할 수도 있다.
• Singleton Design 패턴은 유연하지는 않지만, 만일 이것이 유용하다면 여러분은 여러 애플리케이션 Context 객체를 가지기 위해 선택할 수 있다.

안녕하세요 strider 입니다 이제 한 2 달쩨 되가나여??? 요즘 만은 일들이 있어 진도가 많이 나가지는 못했읍니다만!!! ....   어쩼든 continue 입니다

일단 요즘저의 목표는 내년 중반기까지가 일단 전부입니다
그뒤는  새로운 곳에서 시작을 하게 될거 같아서 계획을 잡는건 무리군요

단기계획을 말씀드리만

1 자바전문가이면서 실무적인 architecture 로서 기본개념 잡기.....

2 IELTS 패스해서 호주 가기 등입니다 ...가는계 목적이아니고...물론


일단 전공자가 아닌저같은 경운 상당이 실무에 접해 있는 논리만으로 지내왔읍니다
사실 그이유뻬고서도 성격자체도  그런성향이 강하긴 합니다만

가장중요한건 제.데.로   이해하고 아는거라 생각합니다
플젝이 진행되면 대부분의  클라이언트경우  다~~그게 그거인 거죠 가 항상 나옵니다
개인적으로 아~~~주 싫어하는 표현인데....
개인적으론 저런 표현 경멸하기 까지 하죠..ㅡ,.ㅡ

대부분의 플젝 실패는 제대로 알지 못함 즉 무지에서  비롯된다는데는 지금까지 경험을 비추어서도 틀림없는 말입니다
사실이 좀 길었고...

일단 전  아직 기본이 부족하다는 판단에 프레임웍에 치중을 하긴 합니다만
이 스터디 팀의 퀘스천맨으로 자리메김 할까 합니다


다만 질문도 모르고선 할수 없기에  지식습득에 최선을 다하긴 합니다만
원천부터 차근히 올라가는 부분은 다른분들의 수고를 좀 부탁드릴수 밖에 없을거 같고
아마 proving 에 즉 구현해보는데 주력을할까 합니다

기존의 계념을 접근하는데만 시간을  배당할수없기에 최대한의 지름길..즉 short cut 을
따라 지식이 축척되지 않을까 하는데요   따라서 그 깊이가 그다지 ㅡ,.ㅡ....


단기간내에 성립된 짧은 지식이지만  멤버 여러분의 디테일로  적어도 잘못아는 우는 범하지 않으리라 봅니다



SOA 는 아키텍저 특성상 실제 전체를 구현한다는것은 어불성설이지 싶고
ESB나SCA 구현체를 Spring 을 이용해 빠른시간내에 구축해 보고 싶읍니다


개인적으로 요즘또 IELTS 셤준비로 미국드라마에 시간을 많이 할에 하다 보니...
(핑개인가...ㅡ,.ㅡ)  정말 일주일이 번개 같이지나 갑니다....정말.....

암튼  cheer up !! 하죠...