Circular Dependency의 해악은 개발을 하다보면 자연스럽게 알게 된다..
회사에서 개발하는 시스템중에 처음에는 그러하지 않았을 것인데, 아키텍처링을 할 수 없는 지금의 조직에서 자연스럽게 Circular Dependency를 걸어버렸다.. 일정이라는 최고의 명제 아래 말이다..
결국, 의존과 버전에 묶여서 뗄레야 뗄루 없는 커플처럼 되어 버린 기존의 시스템은 또다시 거대한 레거시로의 한발한발 다가서고 있다.. 정말로 뗄 수 없을 정도로 말이다..
누군가는 나서서 해결을 해야 겠지만, 누가 하겠는가.. 일정에 맞춰서 들어온 일 처리해야쥐..
결국 시스템의 모습은 직책자들의 마인드와 의지가 만들어 내는 우리의 현실이며, 이 모습은 좋은 개발팀 혹은 좋은 개발실은 아니라는 느낌을 지울 수 없다..
아래 Building속성에서의 Circular dependencies는 Warning이 아니라 Error 상황이 되어야 된다.
그래서, 위의 상황을 미연에 방지를 해야된다.. 단순한, 일정에 맞춰야 되서 Warning이 Default가 되어서는 안될 것이다.. ^^;;
1) In computers, a platform
is an underlying computer system on which application programs can run.
On personal computers, Windows 2000 and the Mac OS X are examples of two
different platforms. On enterprise servers or mainframes, IBM's S/390 is an
example of a platform.
A platform consists of an operating system, the computer
system's coordinating program, which in turn is built on the instruction
set for a processor or microprocessor, the hardware that
performs logic operations and manages data movement in the computer. The
operating system must be designed to work with the particular
processor's set of instructions. As an example, Microsoft's Windows 2000
is built to work with a series of microprocessors from the Intel
Corporation that share the same or similar sets of instructions. There
are usually other implied parts in any computer platform such as a
motherboard and a data bus, but these parts have increasingly become
modularized and standardized.
Historically,
most application programs have had to be written to run on a particular
platform. Each platform provided a different application program
interface for different system services. Thus, a PC program would have
to be written to run on the Windows 2000 platform and then again to run
on the Mac OS X platform. Although these
platform differences continue to exist and there will probably always be
proprietary differences between them, new open or standards-conforming
interfaces now allow many programs to run on different platforms or to
interoperate with different platforms through mediating or "broker"
programs.
2) A platform is
any base of technologies on which other technologies or processes are
built.
framework
In general, a framework is a real or conceptual structure
intended to serve as a support or guide for the building of something
that expands the structure into something useful.
In computer systems, a
framework is often a layered structure indicating what kind of programs
can or should be built and how they would interrelate. Some computer
system frameworks also include actual programs, specify programming
interfaces, or offer programming tools for using the frameworks. A
framework may be for a set of functions within a system and how they
interrelate; the layers of an operating system; the layers of an
application subsystem; how communication should be standardized at some
level of a network; and so forth. A framework is generally more
comprehensive than a protocol and more prescriptive than a
structure.
The ThoughtWorks Anthology 라는 책의 11 챕터의 빌드 아케텍트인 줄리안 심슨님의 내용은, build.xml 즉, ant 파일이 refactoring에 대한 내용입니다. 그 중에서, <macrodef> 태그를 이용한 build.xml 파일의 리펙토링 예제가 나오는데, 유용할것 같아서 개인적으로 사용하고 있는 dist target에 대해서 리펙토링을 적용해 봤습니다.
위 예제처럼, 리펙토링된 내용을 살펴보면, <macrodef>태그를 통해서 기능에 대한 내용을 작게 쪼개서 빼고(<macrodef>) , 사용하는 <target>에서는 필요한 각 기능을 호출하는 템플릿 메쏘드(?)처럼 기술하게 됩니다. 어디서 많이 본 느낌인데.. 위는 기능을 작게 나눠서 메쏘드로 뽑는 extract method 리렉토링 기법과 동일하네요.. 역시 대가들에게서 많은 내용을 배우게 되는것 같습니다. ^^
소켓을 기반으로 풀링을 하는 라이브러리를 개발할 시에 보통 소켓 클래스의 isconnected 라는 상태변수를 통해서 소켓의 연결상태를 확인할 수 있으나, 정확한 정보는 아니죠.. isconnected라는 변수는, 마지막 네트웍 이벤트를 처리한 소켓의 연결 상태이기 때문이죠.. 그래서 확실하게 풀을 관리하기 위해서는 네트웍 이벤트를 발생시켜 보는것이 Java에서는 해결책이라고 봐야 될듯 합니다.
아래코드는 SocketChannel이 non-block인 상태를 기준으로, read 메쏘드를 호출했을 경우, 리턴값을 보고 상태를 확인하는 코드입니다.
int readbytes = socketChannel.read(buf);
// 연결이 되어 있음..
if(readbytes == 0)
// 끊어졌네요.
if (readbytes == -1)
// 리시브된 데이타가 있네요..
if(readbytes >0)
소켓 풀링을 관리하는 매니저 클래스가 풀에 들어있는 소켓의 read 이벤트를 주기적으로 호출해보면, socket의 연결상태를 잘 유지할 수 있을 것입니다. ^^