본문 바로가기
[Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16.
[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. [Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. - 리플렉션은 여러모로 강력한 기능을 제공한다. 하지만 이런 강력함은 다음의 대가들을 수반한다. 컴파일 시점에 가능한 타입 확인의 장점이 없어진다. 재귀적인 접근을 필요로 하는 코드는 알아 보기 어렵고 길다. 처리 성능이 늦다. - 사실 리플렉션은 컴포넌트 기반의 어플리케이션 개발 도구용으로 설계되었다. 따라서 일반적으로 런타임에서는 리플렉션을 이용해서 재귀적으로 사용하면 안된다. - 리플렉션이 필요한 복잡한 애플리케이션은 다음과 같다. 클래스 브라우저 객체 조사기 코드 분석 도구 RPC - 리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다. 예를 들어 컴파일 시점에는 쓸.. 2017. 2. 13.
[Effective Java] 객체 참조는 그 객체의 인터페이스 타입으로 하자 [Effective Java] 객체 참조는 그 객체의 인터페이스 타입으로 하자 - 객체를 참조할 때는 클래스보다는 인터페이스를 사용해야 한다. 만일 적합한 인터페이스 타입이 있다면, 매개 변수, 반환 값, 변수, 필드 모두 다 인터페이스 타입을 사용해서 선언해야 한다. 유일하게 객체의 클래스를 참조할 필요가 있는 경우는 생성자에서 객체를 생성할 때이다. - 인터페이스를 객체의 타입으로 사용하는 습관을 들이면, 프로그램이 훨씬 더 유연해진다. - 인터페이스의 구현체(클래스)를 변경하고자 하는 이유는, 새로 변경한 구현체가 더 좋은 성능을 내는 경우가 많다. - 만일 적합한 인터페이스가 없다면, 객체를 참조하는 타입을 인터페이스 대신 클래스로 하는 수밖에 없다. 적합한 인터페이스가 없는 경우는 보통 fina.. 2017. 2. 9.
[Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. [Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. - 사용 가능한 API 라면 반드시 문서화해야 한다. 만일 문서화 주석 규칙에 친숙하지 않다면 배워야 한다. - API 를 문서화하려면, 외부에 제공하는 모든 클래스, 인터페이스, 생성자, 메소드, 필드의 선언부 앞에 문서화 주석을 넣어야 한다. 만일 어떤 클래스가 직렬화될 수 있다면 직렬화 형태도 문서화해야 한다. - 문서화 주석이 빠진 API 를 사용하는 것은 실망스럽고 에러가 생길 가능성이 많다. 유지보수 하기 쉬운 코드를 작성하려면 외부에 공개되지 않는 대부분의 클래스, 인터페이스, 생성자, 메소드, 필드에 대해서도 문서화 주석을 작성해야 한다. - 메소드의 문서화 주석에서는 메소드와 클라이언트 사이의 계.. 2017. 1. 23.
[Effective Java] 메소드 시그니처를 신중하게 설계하자. [Effective Java] 메소드 시그니처를 신중하게 설계하자. - 메소드 이름을 신중하게 짓자. 이름은 항상 표준 작명 규칙을 따라야 한다. 이름에는 일관성이 있어야 한다. 폭넓게 공감 가는 이름을 선택해야 한다. - 편리한 메소드를 만드는데 너무 열중하지 말자. 모든 메소드는 자신의 역할을 해야 한다. 메소드가 너무 많으면, 클래스를 배우고 사용하고 문서화하고 테스트하고 유지하기가 어렵다. 클래스나 인터페이스가 지원하는 각 동작에 대해서 충분한 기능을 수행하는 메소드를 제공하자. - 너무 많은 매개 변수를 피하자. 매개 변수는 네 개 이하를 목표로 하자. 매개 변수가 네 개를 넘으면 시종일관 문서를 참조하지 않고는 그 메소드 API 를 사용할 수 없다. 같은 타입의 매개 변수가 길게 나오면 특히 .. 2017. 1. 12.
[Effective Java] 타입 정의는 표시 인터페이스를 사용하자. [Effective Java] 타입 정의는 표시 인터페이스를 사용하자. - 표시 인터페이스(marker interface)는 메소드 선언은 전혀 없으면서 클래스가 그 인터페이스를 구현하는지만 나타내는(표시하는) 인터페이스이다. - annotation 이 이를 대체할 수도 있겠지만, marker interface 는 annotation 에 비해 두 가지 장점이 있다. 1. marker interface 는 표시된 클래스의 인스턴스에 의해 구현되는 타입을 정의한다. 2. 더 정확한 목표를 가질 수 있다. ( annotation 은 class 한정이 아니다. ) - annotation 도 장점이 있다. 1. 주요 장점은 이미 발표되어 사용 중이라도 기본적으로 하나 이상의 주석 타입 요소들을 추가함으로써 더 많.. 2017. 1. 5.
[Effective Java] 인터페이스를 사용해서 확장 가능한 enum 을 만들자. [Effective Java] 인터페이스를 사용해서 확장 가능한 enum 을 만들자. - 대개의 경우 enum 의 확장은 좋지 않은 생각으로 밝혀졌다. - 확장 가능한 enum 타입을 사용해야 할 경우가 최소한 한 가지가 있는데, 작동 코드(operation code) 또는 opcode 라고 하는 것으로 특정 머신의 작동을 나타내는 요소들을 갖는 enum 타입이다. - 인터페이스를 구현한 enum 에 generic 을 설정할 경우는 아래와 같이 할 수 있다. bounded wild card Class opSet // class 객체가 enum 과 Operation 서브 타입 모두임을 나타냄. unbounded wild card Collection 2016. 12. 29.
[Effective Java] int 상수 대신 enum 을 사용하자. [Effective Java] int 상수 대신 enum 을 사용하자. - int enum pattern 이라고 불리는 int 를 이용한 분기는 단점이 많다. - 타입 안전을 보장하지도 않고, 편리하게 사용할 수 있는 방법도 제공하지 않는다. 즉 취약하다. - int enum 상수를 출력 가능한 문자열로 쉽게 바꾸는 방법도 없다. - 하나의 int enum 그룹에 있는 모든 상수를 loop 처리하거나, 그룹 사이즈를 알 수 있는 좋은 방법도 없다. - int enum 패턴의 변이로 String enum 패턴이 있는데 더더욱 바람직하지 않다. print 하는 부분에서는 좋지만, 문자열 비교에 의존하여 성능 문제가 생길 수도 있다. 더욱 문제가 되는 것은 필드명 대신 string 상수 값을 클라이언트 코드에.. 2016. 12. 19.
[Effective Java] 전략을 표현할 때 함수 객체를 사용하자. [Effective Java] 전략을 표현할 때 함수 객체를 사용하자. - 자바는 함수 포인터를 제공하지 않는다. 대신 객체 참조를 사용해서 유사한 효과를얻을 수 있다. 호출된 객체의 메소드에서 다른 객체(메소드로 전달되는)의 메소드를 수행하도록 객체를 정의하는 것이 가능하다. 그런 메소드 하나만 달랑 외부에 제공하는 클래스의 인스턴스는 사실상 메소드 포인터의 역할을 한다. 그런 인스턴스를 함수 객체(function object)라고 한다. ex) Comparator Interface 를 상속한 Class instance. - 좋은 함수 객체는 상태가 없어 static final, singleton 으로 사용 가능한 녀석이다. Summary 함수 포인터의 주 용도는 전략(strategy) 패턴을 구현하는.. 2016. 11. 15.
반응형

티스토리툴바