본문 바로가기
[Effective Java] 예외 상황에서만 예외를 사용하자. [Effective Java] 예외 상황에서만 예외를 사용하자. - 예외는 예외 상황을 대비해 설계된 것이므로, JVM 을 만드는 회사가 예외 처리 속도를 빠르게 하려고(우리가 명시적으로 검사하는 것만큼) 매달릴만한 일이 아니다. try-catch 블록 내부에 코드를 넣으면, 여러 종류의 JVM 이 해 줄 수 있는 나름의 최적화를 못하게 하는 부작용이 생길 수 있다. 배열을 반복 루프 처리하면서 정상적인 루프 종료 검사를 하는 표준 이디엄 코드가 반드시 중복 검사를 하는 것은 아니다. 근래의 JVM들에서는 그런 코드를 최적화한다. - 예외는 예외적인 상황에서만 사용해야 한다. 절대로 정상적인 흐름 제어에 사용하면 안된다. - 잘 설계된 API에서는 클라이언트가 예외를 사용해서 정상적인 흐름 제어를 하게끔.. 2017. 2. 20.
[Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16.
[Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. [Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. - 사용 가능한 API 라면 반드시 문서화해야 한다. 만일 문서화 주석 규칙에 친숙하지 않다면 배워야 한다. - API 를 문서화하려면, 외부에 제공하는 모든 클래스, 인터페이스, 생성자, 메소드, 필드의 선언부 앞에 문서화 주석을 넣어야 한다. 만일 어떤 클래스가 직렬화될 수 있다면 직렬화 형태도 문서화해야 한다. - 문서화 주석이 빠진 API 를 사용하는 것은 실망스럽고 에러가 생길 가능성이 많다. 유지보수 하기 쉬운 코드를 작성하려면 외부에 공개되지 않는 대부분의 클래스, 인터페이스, 생성자, 메소드, 필드에 대해서도 문서화 주석을 작성해야 한다. - 메소드의 문서화 주석에서는 메소드와 클라이언트 사이의 계.. 2017. 1. 23.
[Effective Java] 오버로딩(overloading)을 분별력 있게 사용하자. [Effective Java] 오버로딩(overloading)을 분별력 있게 사용하자. public class CollectionClassifier{public static String classify(Set s){return "Set";} public static String classify(List lst){return "List";} public static String classify(Collection c){return "Unknown Collection";} public static void main(String[] args){Collection[] collections = { new HashSet(), new ArrayList(), new HashMap().values() };for( Col.. 2017. 1. 16.
[Effective Java] 메소드 시그니처를 신중하게 설계하자. [Effective Java] 메소드 시그니처를 신중하게 설계하자. - 메소드 이름을 신중하게 짓자. 이름은 항상 표준 작명 규칙을 따라야 한다. 이름에는 일관성이 있어야 한다. 폭넓게 공감 가는 이름을 선택해야 한다. - 편리한 메소드를 만드는데 너무 열중하지 말자. 모든 메소드는 자신의 역할을 해야 한다. 메소드가 너무 많으면, 클래스를 배우고 사용하고 문서화하고 테스트하고 유지하기가 어렵다. 클래스나 인터페이스가 지원하는 각 동작에 대해서 충분한 기능을 수행하는 메소드를 제공하자. - 너무 많은 매개 변수를 피하자. 매개 변수는 네 개 이하를 목표로 하자. 매개 변수가 네 개를 넘으면 시종일관 문서를 참조하지 않고는 그 메소드 API 를 사용할 수 없다. 같은 타입의 매개 변수가 길게 나오면 특히 .. 2017. 1. 12.
[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.
[Django] 파이썬 웹 프로그래밍 - Django 웹 프레임워크 #1 [Django] 파이썬 웹 프로그래밍 - Django 웹 프레임워크 #1 -책을 읽으며 Remind 하는 내용, 핵심 내용, 모르던 내용을 정리한 것입니다. 예문 및 자세한 설명은 책을 구매하여 보세요~ -2003년 로렌스 저널-월드 신문을 만들던 웹 개발팀의 내부 프로젝트로 시작.2005년 오픈 소스 프로젝트로 공개.구글의 앱 엔진에서 장고를 사용하면서 많은 사람들이 사용.파이썬의 대표적인 웹 프레임워크로 자리매김. * MVC 패턴 기반 MTV -장고는 MVC 를 기반으로 한 프레임워크이다.장고에는 View 를 Template, Controller 를 View 라고 부른다.그래서 장고를 흔히 MTV(Model-Template,View) 프레임워크라 부른다. * 객체 관계 .. 2016. 12. 9.
[Effective Java] 바운드 와일드 카드를 사용해서 API 의 유연성을 높이자. [Effective Java] 바운드 와일드 카드를 사용해서 API 의 유연성을 높이자. - 매개변수화 타입은 불변(invariant) 이다. 서로 다른 두 개의 타입 Type1, Type2 에 대해 List, List 는 서브 타입도 수퍼 타입도 아니다. - 매개변수화 타입은 불변이기 때문에, 바운드 와일드 카드 타입(bounded wildcard type)을 사용해야 유연성이 좋다. 예) -> 를 사용하였기에 null 이외에는 put 을 할 수 없다. 이 경우 1번의 방법을 helper 로 갖는 function 을 하나 더 가져야 한다. 하지만, public 하게는 raw type 도 받을 수 있어 유연성은 더 좋다. Summary 메소드 API에 와일드 카드 타입을 사용하면 코드 작성이 조금 어려워.. 2016. 12. 5.
[Effective Java] 추상 클래스보다는 인터페이스를 사용하자. [Effective Java] 추상 클래스보다는 인터페이스를 사용하자. - 인터페이스(interface)와 추상클래스(abstract class)는 비슷하지만 다르다. 추상 클래스는 구현된 메소드를 포함할 수 있는 반면 인터페이스는 그렇지 못하다. 추상 클래스로 정의된 타입을 구현하는 클래스는 반드시 추상 클래스의 서브 클래스가 되어야 한다. 인터페이스를 구현하는 클래스의 경우 인터페이스에 정의된 모든 메소드를 구현하기만 하면 된다. 자바는 단일 상속만을 허용하므로 추상 클래스로 타입을 정의할 때 심한 제약이 따른다. - 인터페이스는 추상 클래스에 비해 변경과 적용이 쉽다. - 인터페이스는 믹스인(mixin)을 정의하는 데 이상적이다. 믹스인은 클래스가 자신의 본래 타입에 추가하여 구현할 수 있는 타입으.. 2016. 11. 7.
반응형

티스토리툴바