진성 소프트

(Effective Java) 규칙43. 람다보다는 메서드 참조를 사용하라 람다 람다가 익명 클래스보다 나은 점 중에서 가장 큰 특징은 간결함인데 람다보다도 더 간결하게 만들 수 있는 방법이 있다. 바로 메서드 참조(method reference) 임 예) 임의의 키와 Integer 값의 매핑을 관리하는 프로그램 값이 키의 인스턴스 개수로 해석된다면, 이 프로그램은 멀티셋(multiset)을 구현한게 됨 키가 맵 안에 없다면 키와 숫자1을 매핑하고, 이미 있다면 기존 매핑 값을 증가시킴 map.merge(key, 1, (count, incr) -> count + incr); 자바 8때 Map에 추가된 merge 메서드, 키, 값, 함수를 인수로 받아 수행하는 함수임 메서드 참조 위 코드는 깔끔한 코드지만..

(Effective Java) 규칙45. 스트림은 주의해서 사용하라 스트림 API 스트림 API는 다량의 데이터 처리 작업(순차적이든 병렬적이든)을 돕고자 자바 8에 추가되었다. 스트림 API가 제공하는 추상 개념 핵심 스트림(stream)은 데이터 원소의 유한 혹은 무한 시퀀스(sequence)의 개념 스트림 파이프라인(stream pipeline)은 이 원소들로 수행하는 연산단계를 표현하는 개념 스트림의 원소들은 어디로부터든 올 수 있다. 대표적으로는 컬렉션, 배열, 파일, 정규표현식 패턴 매처(matcher), 난수 생성기, 혹은 다른 스트림 스트림 안의 데이터 원소들은 객체 참조나 기본 타입 값임 기본 타입으로는 int, long, double을 지원 스프림 파이프라인 소스 스트림에서 시작하여 종..

(Effective Java) 규칙15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트란 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. 정보은닉의 장점 대부분의 장점은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해준다. 1. 시스템의 개발 속도를 높임 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 2. 시스템 관리 비용을 낮춤..

(Effective Java) 규칙58. 전통적인 for 문보다는 for-each 문을 사용하라 전통적인 for문의 컬렉션, 배열 순회의 단점 아래 관용구들은 while문보다는 낫지만(규칙57) 가장 좋은 방법은 아니다. for(Iterator i = c.iterator(); i.hasNext()) { Element e = i.next(); ... // e로 무언가를 함 } for (int i = 0; i < a.length; i++) { ... // a[i]로 무언가를 한다. } 반복자와 인덱스 변수는 모두 코드를 지저분하게 할 뿐 진정 필요한 건 원소들뿐임 쓰이는 요소가 늘어나면 오류가 생길 가능성이 높아짐 컬렉션이냐 배열니야에 코드 형태가 상당히 달라짐 for-each 문 for-each 문의 정식..

(Effective Java) 규칙57. 지역변수의 범위를 최소화하라 지역변수의 범위를 최소화 지역변수의 유효범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성은 낮아진다. 지역변수의 범위를 줄이는 방법 1. 가장 처음 쓰일 때 선언하기 미리 선언부터 해두면 코드가 어수선해져 가독성이 떨어짐 변수를 실제로 사용하는 시점엔 타입과 초기값이 기억나지 않을 수도 있음 그렇지 않으면 지역변수가 쓰이는 범위 보다 너무 앞서 선언하거나, 다 쓴 뒤에도 여전히 살아 있게 되기 쉬움 2. 거의 모든 지역변수는 선언과 동시에 초기화하기 만약 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 함 단, try-catch문은 예외임 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 ..

(Effective Java) 규칙16. public 클래스에서는 public필드가 아닌 접근자 메서드를 사용하라 public 필드의 문제 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다. class Point { public double x; public double y; } 이런 클래스는 데이터필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못함 API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없음 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없음 접근자 메서드 public 클래스에서라면 아래의 방식이 확실히 맞다. class Point { private double x; private double y; public..

(Effective Java) 규칙22. 인터페이스는 타입을 정의하는 용도로만 사용하라 인터페이스의 목적 인터페이스를 구현하는 클래스를 만들게 되면, 그 인터페이스는 해당 클래스의 객체를 참조할 수 있는 자료형(type) 역할을 하게 된다. 해당 클래스의 객체로 어떤 일을 할 수 있는지 클라이언트에게 알리는 행위임 인터페이스의 목적은 여기까지이며 다른 목적으로 인터페이스를 정의 하고 사용하는 것은 적절치 못함 인터페이스를 잘못 사용하는 예 상수 인터페이스(constant interface) 형태 메서드가 없고, static final 필드만 있는 형태로 모든 필드는 상수 정의임 대체로 상수 이름 앞에 클래스 이름을 붙이는 번거로움을 피하기 위해서임 //상수 인터페이스 안티패턴 - 사용하지 말 것! pub..

(Effective Java) 규칙20. 추상 클래스 보다는 인터페이스를 우선하라 추상 클래스, 인터페이스 자바 언어에는 여러 가지 구현을 허용하는 자료형을 만드는 방법이 두가지 포함되어 있음. 인터페이스, 추상클래스(abstract class) 이 두 방법의 분명한 차이는 추상 클래스는 구현된 클래스를 포함할 수 있지만 인터페이스는 아니라는 것임. 자바 1.8 부터는 'default' 메서드를 통해 인터페이스에도 구현을 포함시킬 수 있음 좀 더 중요한 차이는 추상 클래스를 자료형으로 사용하기 위해서는 반드시 계승이 필요하다는 것이다. 인터페이스는 포함된 모든 메서드를 정의하고 인터페이스가 규정하는 일반 규약을 지키기만 하면됨 자바는 다중 상속(multiple inheritance)를 허용하지 않기 때문..