역겨운 Context클래스. Context객체입장에서는 배은망덕(?)하다고 여길지도 모른다.
Servlet/JSP와 EJB 환경에선 Context 객체 없이는 무엇도 하기 힘든데...
나는 Kathy Sierra의 영향을 받아 즉흥적인 그래프를 만든다.
신뢰성 있는 분석을 기반으로 한 그래프는 아니지만 명예훼손의 염려는 없다.
기반이 되는 코드가 아니라 업무 로직을 담은 클래스에 Context가 보인다면 내가 봐도 눈에 거슬릴 것 같다. 나는 대체로 정적 코드가 필요해질 때까지 정적 코드를 사용하지 않는다.라는 지침에 동의한다.
하지만, 편의성을 모토로 하는 유틸리티 메소드/클래스의 상당수는 static이다.
Java EE 환경에서는 컨테이너의 등장으로 인해서 공유의 수준이 다양해졌고, 다양한 수준의 "static"이 등장했는데 그들의 다른 이름이 Context이다.
이제 오후까지 마쳐야 하는 문서 작업 때문에 업무로 복귀해야 한다. 쩝...
역겨운 Context클래스의 링크를 통해 의미의 면적이 좁은이라는 상큼한 글을 만나게 되었다.
이것은 내가 가장 먼저 배운 프로그래밍의 Principle of least privilege에 대한 또다른 해석이다.
Servlet/JSP와 EJB 환경에선 Context 객체 없이는 무엇도 하기 힘든데...
나는 Kathy Sierra의 영향을 받아 즉흥적인 그래프를 만든다.
기반이 되는 코드가 아니라 업무 로직을 담은 클래스에 Context가 보인다면 내가 봐도 눈에 거슬릴 것 같다. 나는 대체로 정적 코드가 필요해질 때까지 정적 코드를 사용하지 않는다.라는 지침에 동의한다.
하지만, 편의성을 모토로 하는 유틸리티 메소드/클래스의 상당수는 static이다.
Java EE 환경에서는 컨테이너의 등장으로 인해서 공유의 수준이 다양해졌고, 다양한 수준의 "static"이 등장했는데 그들의 다른 이름이 Context이다.
이제 오후까지 마쳐야 하는 문서 작업 때문에 업무로 복귀해야 한다. 쩝...
역겨운 Context클래스의 링크를 통해 의미의 면적이 좁은이라는 상큼한 글을 만나게 되었다.
이것은 내가 가장 먼저 배운 프로그래밍의 Principle of least privilege에 대한 또다른 해석이다.
