'facade'에 해당하는 글 1건

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
예전에 중복으로 인해 프로그램이 엉망으로 되가는 것을 경험한 적이 있습니다. 저는 그러한 경험을 통해 자연스레 단일 지점 제어의 필요성을 느꼈고, 중복을 없애기 위한 의식적인 노력을 부단히 했습니다. 이러한 노력을 반복하다보니 어느날 부터인가 특별한 의식 없이도 중복을 제거하고 있음을 발견할 수 있었습니다. 매우 익숙해진 것입니다.

그런데 이 익숙함이 부정적인 결과를 가져올 수 있는 것 같습니다. 예를 들어 저의 경우 '중복은 반드시 없어져야 하는 것이다'라는 생각에 사로잡혀, 지난 글에서 얘기했던 격리와 같은 측면에 대해선 몇년동안 전혀 생각하지 못했었습니다. 중복이라는 문제에 대해 무의식적으로 대응하다보니 더 이상 그것에 대해 생각할 수 없었고 안타깝게도 더 이상의 발전이 없었던 것입니다.

얼마전 EP님이 쓰신 글에 소개 된 인용에서 저자의 비슷한 경험을 발견 할 수 있었습니다.
I had become accustomed to encapsulating the business logic with either a session façade or a POJO façade. Eventually, this approach started to make sense. After all, if the presentation tier and business tiers are running in the same machine, then the cost of calls between the tiers is negligible. We do not need to be constrained by a design approach whose main motivation was to minimize the overhead of remote calls.

저는 Session Facade나 POJO Facade를 이용하여 비즈니스 로직을 캡슐화 하는 데 익숙해져 있었습니다. 사실 이러한 접근은 합리적인 이유로 시작된 것입니다. 하지만 프레젠테이션 계층과 비즈니스 계층이 같은 장비에서 구동되고 있다면 이 두 계층 사이에 호출 비용은 매우 미비할 것입니다. 이런 경우에는 원격 호출의 부담을 최소화 하려 했던 처음 의도를 고집할 필요가 없습니다.

저의 경험과 위 인용에서 발견된 문제를 피하기 위해서는 '익숙함에 대한 경계'가 필요할 것으로 보입니다. 익숙함의 어두운 측면이 있습니다. 그것은 익숙함이 생각을 멈추게 하여 결과적으로 발전을 방해할 수 있는 높은 울타리가 될 수 있다는 것입니다. 따라서 익숙한 것에 대해서도 의식하고 생각하는 자세가 더 좋은 결과를 만들 수 있을 것이라 생각합니다.

2007/11/01 ~ 2008/01/10

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,