Skip to main content

Posts

Showing posts from September, 2009

Java generic in return context

아래 코드를 보시고 1, 2번 라인중에 어디서 에러가 날 지를 찾아보세요. interface B { void doB(); } class D implements B { public void doB() {} } interface H { B getB(); } class HImpl implements H { public B getB() { return new D(); // 1) } } ... H h = new HImpl(); D d = h.getB(); // 2) 네, 2번 라인입니다. 그럼 다음 코드는? interface B1 { void doB1(); } interface B2 { void doB2(); } class D implements B1, B2 { public void doB1() {} public void doB2() {} } interface H { <T extends B1 & B2> T getB(); } class HImpl implements H { public <T extends B1 & B2> T getB() { return new D(); // 1) } } ... H h = new HImpl(); D d = h.getB(); // 2) 네, 1번입니다. 잘 이해가 되질 않아 사내 메일링 리스트에 물어보니 I think you're seeing and interpreting it as "this method can return anything that implements both interfaces". What it's actually saying is "the caller is going to tell you a specific class that implements both interfaces, and you must return one of those" . 이랍니다. 즉 T 타입이 아직 결정되지 않은 상태라 D와 T는 compati

Access level of methods in package-private class

Java에서 (C++도 마찬가지지만) 권장되는 access level 사용법은 다음과 같습니다. Use the most restrictive access level that makes sense for a particular member. 쉽게 얘기해서 private으로 충분하면 private을 쓰고 다음으로 package-private, protected, public 순으로 쓰라는 얘기. 그런데 C++와는 달리 Java는 class에도 public과 package-private 두 종류의 access level이 있습니다. 이 중 public class의 method들은 위의 권장 사항을 따르면 될 듯 한데 package-private class일 경우는 어떨까요? Package-private class에서는 실제 사용될 수 있는 조건으로 봤을 때 method들이 public이건 protected건 모두 package-private과 같은 조건을 가집니다. 즉, 아무리 method의 access level을 public이나 protected로 해봐야 다른 package에선 이 method를 사용할 수가 없습니다. 따라서 the most restrictive한 level을 사용하라는 위 권장 사항을 따르자면 package-private class의 method들은private이 아니라면 모두 package-private access level을 사용해야 합니다. 그런데 코딩을 하다보니 이 방법엔 한가지 문제가 있더군요. 가끔 package-private class를 public class로 만들어야 할 경우들이 생기는데 이때 method들이 모두 package-private이면 다른 package에서 사용할 수가 없습니다. 그래서 다시 method들의 access level을 조정해야 할 필요가 생기는데 이 시점은 이미 코드를 작성했을 때와 멀어서 자칫 잘못된 access level을 지정할 수 있게 됩니다. 그래서 생각한건데... package-priva

A History of CLU

Checked exception 관련 글들을 찾아 보다가 읽게 된 문서입니다. CLU라는 프로그래밍 언어를 개발하게 된 배경과 과정에 대한 내용인데 정말 재밌네요. 참고로 문서가 좀 길어보이지만 한 1/3은 부록입니다. :) A History of CLU 거의 30~40년전 이야기인데 현재 사용하고 있는 언어들이 여기서 앞으로 많이 나간것 같아 보이지 않네요. As mentioned, the concept of data abstraction arose out of work on structured programming and modularity that was aimed at a new way of organizing programs. The resulting programming methodology is object-oriented . A keystone of the methodology is its focus on independence of modules . Achieving independence requires two things: encapsulation and specification . Specifications are needed to describe what the module is supposed to do in an implementation-independent way so that many different implementations are allowed. ( Code is not a satisfactory description since it doesn’t distinguish what is required from ways of achieving it . One of the striking aspects of much of the work on object-oriented programming has been its lack of understanding of the importance of specificatio

Checked exception, 이거 써도 되나?

mkseo님 블로그 에 Best Practices for Exception Handling 에 관한 글이 올라왔는데 댓글을 읽고 쓰고 하다 궁금한게 생겼습니다. Checked exception, 이거 써도 되나? mkseo님이 링크를 걸어준  The Trouble with Checked Exceptions 과 Does Java need Checked Exceptions? , Java's checked exceptions were a mistake (and here's what I would like to do about it) 등의 글을 읽다 보니 현재까지의 결론은 "java의 checked exception실험은 실패다"정도인 것 같더군요. 몇가지 이유로는 원래 language designer의 의도와는 달리 많은 exception이 무시되고 있다. 원래 의도는 compile-time에 에러를 냄으로써 개발자들에게 이 예외를 지금 처리하거나 아니면 위로 전달해야 한다는 메시지를 보내는 것이었다. 하지만 예외를 전달하기 위해서는 method의 signature를 수정해야 한다. 개발자들로서는 이 상황을 벗어날 수 있는 가장 쉬운 방법을 찾게 되고, 이게 바로 catch 후 무시하는 것인데 대부분의 코드가 이런 식으로 작성되고 있다. catch (...) {} 원래 exception의 목적중 하나는 예외가 발생한 지점과 처리할 지점의 분리이다. 즉 low-level에서 발생했지만 거기서 처리가 불가능한 exception들을 위로 전달하여 처리하게 한다... 인데... checked exception은 그 사이에 있는 모든 코드가 이 exception에 대해 알아야만 하게 강제한다. 즉, 전달되는 과정이 투명하지 않다. Versionability - 어느 method가 A, B라는 checked exception만을 던진다고 선언되었다면 client code들은 이 예외만을 처리하거나 위로 전달하도록 작성된다. 나중에 이

Responsive Design seminar - Kent Beck

http://agile.egloos.com/5087979 정말 오랫만에 세미나를 가서인지 첫 시간은... 잘 잤다. ㅜㅜ 다음은 기억에 남는 얘기들. Responsive to Constraints Feedback from system, people or customers. Step back 문제를 만났을 때 한발짝 뒤로 물러서서 바라봐라... 쉬운 예로 어떤 코드의 테스트를 작성하는데 구현하기가 너무 어렵다면 한발짝 뒤로 물러서서 애초에 코드의 설계가 잘못된건 아닌지 확인해봐야 한다. 켄트벡이 든 예는 회전문이었는데... 회전문의  throughput, latency, variance등의 조건을 모두 고려하여 설계하기는 불가능하다. 이때 한발짝 물러서서 왜 회전문이 개선되어야 하는지, 혹시 문밖에 있는 인기있는 커피점때문은 아닌지 보자... 만약 그렇다면 커피점을 문안으로 들여오자. 뭐 이런 얘기... 마침 같이 갔던 H씨가 코드가 바뀔때마다 깨지는 테스트때문에 고민하고 있었는데 한발짝 물러서서 꼭 테스트가 필요한지 확인해보고 지워버리라고 조언... ㅎㅎ Retrospect 자신이 하는 일을 돌아보자. 왜 이렇게 했는지... Goal Steady flow of features. Design - beneficially relating elements 설계란 element들간의 관계인데 서로에게 이롭게 만드는 것. Ambiguity 최선의 설계가 무엇인지 모호할 때는 그대로 놔두는 것도 필요. 그대로 놔두면 코드는 점점 망가지며 스스로 해결책을 드러낼 수 있다. Safe steps 위험하며 효율적인(빠른) 방법보다는 안전하며 덜 효율적인 방법을 선호. 물론 안전하며 덜 효율적인 방법을 빨리 사용할 수 있다. Values 아직 명확하진 않지만... 예를 들면 simplicity, feedback, community Patterns 대부분의 디자인 결정은 problem domain과 관계가 없고