Project
Engineering Knowledge Base
개발서와 설계 글을 실무 판단 기준으로 다시 묶는 학습 아카이브입니다.
Problem
책과 기술 메모는 읽을 때는 유용하지만, 시간이 지나면 프로젝트 판단과 연결되지 않은 기록으로 흩어지기 쉽습니다.
Approach
설계, 테스트, 도메인 모델링, 언어 사용 원칙을 태그 기반으로 묶고 문제 해결 관점에서 다시 찾을 수 있게 정리합니다.
Impact
학습 기록을 단순 요약이 아니라 시스템 설계와 코드 리뷰에서 재사용할 수 있는 판단 근거로 축적합니다.
학습 기록은 책별 요약으로 남기면 다시 활용하기 어렵습니다. 이 프로젝트는 개발서에서 얻은 개념을 실제 설계 판단, 테스트 전략, 코드 구조 선택에 연결하기 위한 지식 베이스입니다.
중심은 책을 많이 읽었다는 사실이 아니라, 반복해서 마주치는 문제를 설명할 수 있는 언어를 축적하는 것입니다. 도메인 경계, 의존성 방향, 테스트 가능성, 데이터 모델링, 언어의 타입 시스템 같은 주제를 프로젝트와 글 사이의 연결점으로 다룹니다.
이 아카이브의 글은 "개념을 이해했다"에서 끝나지 않고, 어떤 상황에서 그 개념이 판단 기준이 되는지까지 남기는 것을 목표로 합니다.
11장. 단위 테스트 안티 패턴
11장. 단위 테스트 안티 패턴 비공개 메서드 단위 테스트 전혀 하지 말아야 된다 비공개 메서드와 테스트 취약성 단위 테스트를 하려고 비공개 메서드를 노출하는 경우에는 식별할수 있는 동작만 테스트하는 것을 위반한다 비공개 메서드와 불필요한 커버리지 죽은 코드다 추상화가 누락되어 있다 비공개 메서드 테스트가 타당한 경우 비
10장. 데이터베이스 테스트
10장. 데이터베이스 테스트 통합 테스트라는 퍼즐의 마지막 조각은 프로세스 외부 관리 의존성이다. 가장 일반적인 예는 애플리케이션 데이터베이스다 실제 데이터베이스를 테스트하면 회귀 방지가 아주 뛰어나지만 설정하기 쉽지 않다 데이터베이스 테스트를 위한 전제 조건 형상 관리 시스템에 데이터베이스 유지 개발자마다 별도의 데이터
9장. 목 처리에 대한 모범 사례
9장. 목 처리에 대한 모범 사례 목은 테스트 대상 시스템과 의존성 간의 상호 작용을 모방하고 검사하는 데 도움이 되는 테스트 대역이다 목은 비관리 의존성에만 적용해야 된다 목의 가치를 극대화하기 비관리 의존성에만 목을 사용하게끔 제한하는 것이 중요하지만 이는 목의 가치를 극대화 하기 위한 첫 번째 단계일 뿐이다 시스템
8장. 통합 테스트를 하는 이유
8장. 통합 테스트를 하는 이유 단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 작동하는지 확신할 수 없다 단위 테스트가 비즈니스 로직을 확인하는데 좋지만 비즈니스 로직을 외부와 단절된 상태로 확인하는 것만으로는 충분하지 않다 통합 테스트는 무엇인가? 통합 테스트의 역할 단위 테스트는 세가지 요구사항을 충족하는
7장. 가치 있는 단위 테스트를 위한 리팩터링
7장. 가치 있는 단위 테스트를 위한 리팩터링 좋은 단위 테스트 스위트의 속성 개발 주기에 통합돼 있다 코드베이스 중 가장 중요한 부분만을 대상으로 한다 최소한의 유지비로 최대의 가치를 끌어낸다 가치 있는 테스트 가치 있는 테스트 작성하기 리팩터링할 코드 식별하기 코드의 네 가지 유형 복잡도 또는 도메인 유의성 코드 복잡
6장. 단위 테스트 스타일
6장. 단위 테스트 스타일 단위테스트 스타일 출력 기반 테스트 가장 품질이 좋음 상태 기반 테스트 두번째 통신 기반 테스트 가장 품질이 낮음 단위 테스트의 세 가지 스타일 출력 기반 테스트(output based testing) 상태 기반 테스트(state based testing) 통신 기반 테스트(communicati
5장. 목과 테스트 취약성
5장. 목과 테스트 취약성 런던파는 테스트 대상 코드 조각을 서로 분리하고 불변 의존성을 제외한 모든 의존성에 테스트 대역을 써서 격리하고자 한다 고전파는 단위 테스트를 분리해서 병렬로 실행할 수 있게 하자고 한다 테스트 간에 공유하는 의존성에 대해서만 테스트 대역을 사용한다 목과 스텁 구분 테스트 대역의 종류 목(moc
4장. 좋은 단위 테스트의 4대 요소
4장. 좋은 단위 테스트의 4대 요소 좋은 단위 테스트 스위트의 특성 개발 주기에 통합돼 있다 코드베이스의 가장 중요한 부분만을 대상으로 한다 최소한의 유지비로 최대 가치를 끌어낸다 가치 있는 테스트 식별 가치 있는 테스트 작성 좋은 단위 테스트의 4대 요소 자세히 살펴보기 회귀 방지 리팩터링 내성 빠른 피드백 유지 보수
3장. 단위 테스트 구조
3장. 단위 테스트 구조 단위 테스트를 구성하는 방법 AAA(arrange act assert) 패턴 사용 3A 패턴은 테스트를 준비(arrange), 실행(act), 검증(assert) 세 단계로 나누는 것을 의미한다. AAA 패턴은 스위트 내 모든 테스트가 단순하고 균일한 구조를 갖는데 도움이 된다 일관성이 이 패턴의
2장. 단위 테스트란 무엇인가
2장. 단위 테스트란 무엇인가 고전파(classical school)는 단위 테스트와 테스트 주도 개발에 원론적으로 접근하는 방식 런던파(London school)는 단위 테스트와 테스트 주도 개발에 실용적으로 접근하는 방식 ‘단위 테스트’의 정의 단위 테스트의 속성 작은 코드 조각을 검증하고 빠르게 수행하고 격리된 방식
1장. 단위 테스트 목표
1장. 단위 테스트 목표 단위 테스트를 배우는 것은 테스트 프레임워크나 목 라이브러리등과 같은 기술적인 부분을 익히는 것에 그치지 않는다 단위 테스트를 매우 많이 작성하더라도 많은 버그와 유지비로 프로젝트 진행이 느려지게 된다 단위 테스트 현황 대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다 보통 제품코드
12장: 데이터 시스템의 미래
파생 데이터 12장: 데이터 시스템의 미래 데이터 통합 문제가 주어졌을때 모든 문제를 만족하는 하나의 해결책은 없지만 상황에 따라 적절한 서로 다른 접근법이 많이 있다 파생 데이터에 특화된 도구의 결합 포스트그레스큐엘 같은 디비는 간단한 애플리케이션 만들기에 충분한 전문 색인 기능이 포함되어 있지만 더 복잡한 검색 기능을
11장: 스트림 처리
파생 데이터 11장: 스트림 처리 "복잡하지만 잘 작동하는 시스템은 예외 없이 간단하지만 잘 작동하는 시스템으로부터 발전한다. 이 명제는 역도 참이다. 처음부터 복잡하게 설계된 시스템은 절대 작동할 리도 없고 작동하게 만들지도 못한다." 존갈, 체계론 일괄처리는 입력으로 파일 집합을 읽어 출력으로 새로운 파일 집합을 생성
10장: 일괄 처리
파생 데이터 1부와 2부에서는 디스크에 저장된 데이터의 레이아웃부터 결함이 있는 상황에서의 분산된 일관성의 한계까지 분산 데이터베이스로 가기위해 고려해야 할 모든 주요사항을 밑바닥부터 다뤘다 데이터를 저장하고 처리하는 시스템 레코드 시스템 : 데이터를 레코드 단위로 저장하고 읽는다 파생 데이터 시스템 : 데이터를 레코드
09장: 일관성과 합의
분산 데이터 09장: 일관성과 합의 결함의 가장 간단한 해결방법은 서비스가 실패하도록 두고 사용자에게 오류메시지를 보내는것 내결함성을 지닌 시스템을 구축하는 가장 좋은 방법은 유용한 보장을 해주는 범용 추상화를 찾아 이를 구현하고 애플리케이션에서 이 보장에 의존하게 하는것 분산시스템에 가장 중용한 추상화 중 하나는 합의
08장: 분산 시스템의 골칫거리
분산 데이터 08장: 분산 시스템의 골칫거리 엔지니어로서의 우리의 임무는 모든 게 잘못되더라도 제 역할을 해내는 시스템을 구축하는것 결함과 부분 장애 하드웨어가 올바르게 동작하면 같은 연산은 항상 같은 결과를 낸다(결정적이다) 부분 장애(partial failure) : 분산시스템에서는 시스템의 어떤 부분은 잘 동작하지만
07장: 트랜잭션
분산 데이터 07장: 트랜잭션 트렌젝션은 데이터베이스의 여러문제를 단순화하는 메커니즘으로 채택돼 왔다 트랜젝션은 애플리케이션에서 몇개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법이다. 데이터베이스에 접속하는 애플리케이션에서 프로그래밍 모델을 단순화하려는 목적으로 만든것이다 트랜잭션 격리 수준(isolation leve
06장: 파티셔닝
분산 데이터 06장: 파티셔닝 데이터셋이 매우 크거나 질의 처리량이 매우 높다면 복제만으로는 부족하고 데이터를 파티션으로 쪼갤 필요가 있다 이작업을 샤딩이라고도 한다 파티션을 나눌때 보통 각 데이터 단위가 하나의 파티션에 속한다 파티셔닝의 주된 이유 : 확장성 파티셔닝과 복제 보통 복제와 파티셔닝을 함께 적용해 각 파티션
05장: 복제
분산 데이터 기술이 성공하기 위해서 홍보보다 현실이 우선돼야 한다. 자연을 속일 수는 없기 때문이다 Richard Feynman 여러 장비 간 분산된 데이터베이스를 필요로 하는 이유 확장성 내결함성/고가용성 지연시간 고부하로 확장 수직확장, 용량확장, 공유메모리 아키텍처 비공유 아키텍처 수평확장 복제 대 파티셔닝 여러 노
04장: 부호화와 발전
데이터 시스템의 기초 04장: 부호화와 발전 만물은 변한다 그대로 있는 것은 아무것도 없다 헤라클레이토스 시스템이 계속 원활하게 실행되게 하려면 양방향 호환성을 유지해야 된다 하위호환성 (backwards compatibility) 새로운 코드는 예전 코드가 기록한 데이터를 읽을수 있어야 된다 상위호환성 (forward
03장: 저장소와 검색
데이터 시스템의 기초 03장: 저장소와 검색 데이터베이스의 두가지 작업 데이터를 저장하고 데이터를 조회하는 것 로그 구조 계열 저장소 엔진, 페이지 지향 계열 저장소 엔진 데이터베이스를 강력하게 만드는 데이터 구조 데이터베이스에서 특정 키의 값을 효율적으로 찾기 위해서 필요한 데이터 구조는 색인 이다 색인의 일반적인 개념
02장: 데이터 모델과 질의 언어
데이터 시스템의 기초 02장: 데이터 모델과 질의 언어 대부분의 애플리케이션은 하나의 데이터 모델 위에 다른 데이터 모델을 계층을 둬서 만듬 관계형 모델과 문서 모델 가장 잘알려진 데이터 모델은 1970년 에드가 코드가 제안한 관계형 모델을 기반으로 한 SQL 데이터는 관계로(테이블) 구성되고 각 관계는 튜플(로우) 모음
01장: 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션
데이터 시스템의 기초 01장: 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 오늘날 소프트웨어는 계산 중심 과는 다르게 데이터 중심적이다 데이터 베이스 캐시 검색 색인 스트림 처리 일괄 처리 소프트웨어 시스템의 관심사 신뢰성 확장성 유지보수성 신뢰성 애플리케이션은 사용자가 기대한 기능을 수행한다 시스템은 사
아이템 52: mutable 컬렉션 사용을 고려하라
이펙티브 코틀린(효율성) 아이템 52: mutable 컬렉션 사용을 고려하라 immutable 컬렉션 보다 mutable 컬렉션이 좋은 점은 성능적인 측면에서 더 빠르다 컬렉션 복제는 처리 비용이 많이 든다 참조
아이템 51: 성능이 중요한 부분에는 기본 자료형 배열을 사용하라
이펙티브 코틀린(효율성) 아이템 51: 성능이 중요한 부분에는 기본 자료형 배열을 사용하라 기본 자료형의 특징 가볍다 일반적인 객체와 다르게 추가적으로 포함되는것이 없기 때문 빠르다 값에 접근할 때 추가비용이 들지 않는다 일반적으로 array보다 list나 set을 사용하는 것이 좋다 하지만 기본 자료형 컬렉션을 굉장히
아이템 50: 컬렉션 처리 단계 수를 제한하라
이펙티브 코틀린(효율성) 아이템 50: 컬렉션 처리 단계 수를 제한하라 전체 컬렉션에 대한 반복과 중간 컬렉션 생성이라는 비용이 발생함 이 비용은 적절한 컬렉션 처리 함수들을 활용해서 줄일 수 있다. 참조
아이템 49: 하나 이상의 처리 단계를 가진 경우에는 시퀀스를 사용하라
이펙티브 코틀린(효율성) 아이템 49: 하나 이상의 처리 단계를 가진 경우에는 시퀀스를 사용하라 Iterable 과 Sequence 는 완전히 다른 목적으로 설계되어서 완전히 다른 형태로 동작한다 Sequence 는 지연 처리 된다 시퀀스 지연처리의 장점 자연스러운 처리 순서를 유지함 최소한만 연산함 무한 시컨스 형태로
아이템 48: 더 이상 사용하지 않는 객체의 레퍼런스를 제거하라
이펙티브 코틀린(효율성) 아이템 48: 더 이상 사용하지 않는 객체의 레퍼런스를 제거하라 상태를 유지할 때는 메모리 관리를 염두에 두어야 한다는 것 코드를 작성할때는 메모리와 성능 뿐 아니라 가독성과 확장성을 항상 고려해야 한다 일반적으로는 가독성과 확장성이 더욱 중요하지만 라이브러리를 구현할 때는 메모리와 성능이 중요하
아이템 47: 인라인 클래스의 사용을 고려하라
이펙티브 코틀린(효율성) 아이템 47: 인라인 클래스의 사용을 고려하라 inline 으로 만들수 있는것은 함수뿐만 아니다 하나의 값을 보유하는 객체도 inline 으로 만들수 있다 inline 클래스는 아래 상황에 많이 쓰인다 측정 단위를 표현할때 타입 오용으로 발생하는 문제를 막을때 인터페이스를 구현하는 인라인 클래스는
아이템 46: 함수 타입 파라미터를 갖는 함수에 inline 한정자를 붙여라
이펙티브 코틀린(효율성) 아이템 46: 함수 타입 파라미터를 갖는 함수에 inline 한정자를 붙여라 inline 한정자의 역활은 컴파일 시점에 함수를 호출하는 부분을 함수의 본문으로 대체하는것 inline 한정자의 장점 타입 아규먼트에 reified 한정자를 붙여서 사용할수 있다 reified 한정자를 지정하면 타입 파
아이템 45: 불필요한 객체 생성을 피하라
이펙티브 코틀린(효율성) 오늘날에는 코드 효율성을 관대 하게 바라본다 개발자가 비싸지고 메모리는 싸졌기 때문이다 장기적으로 효율성은 중요하다 아이템 45: 불필요한 객체 생성을 피하라 객체 생성에는 언제나 비용이 든다 객체를 wrap 하면 크게 3가지 비용이든다 객체는 더 많은 용량을 차지한다 요소가 캡슐화 되어 있다면
아이템 44: 멤버 확장 함수의 사용을 피하라
이펙티브 코틀린(클래스설계) 아이템 44: 멤버 확장 함수의 사용을 피하라 확장함수는 첫 번째 아규먼트로 리시버를 받는 단순한 일반 함수로 컴파일된다 맴버 확장을 피해야 하는 이유 레퍼런스를 지원하지 않는다 암묵적으로 접근할때 두 리시버중에 어떤 리시버를 선택할지 혼동된다 확장 함수가 외부에 있는 다른 클래스를 리시버로
아이템 43: API의 필수적이지 않는 부분을 확장 함수로 추출하라
이펙티브 코틀린(클래스설계) 아이템 43: API의 필수적이지 않는 부분을 확장 함수로 추출하라 클래스 메서드를 정의할때 멤버로 정의할 것인지 확장 함수로 정의할 것인지 결정해야 된다 맴버와 확장 방식의 차이점 따로 가져와서 사용해야 된다 일반적으로 확장은 다른 패키지에 위치한다 확장은 우리가 직접 멤버를 추가할 수 없는
이펙티브 코틀린 아이템 42: compareTo의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 42: compareTo의 규약을 지켜라 compareTo는 Any에 있는 메소드가 아니라 부등식으로 변환되는 연산자이다. 비대칭적 동작: a≥b 이고 b≥a 라면 a==b이다. 연속적 동작: a≥b 이고 b≥c라면 a≥c이다. 코넥스적 동작(connex relation): a≥b 또는
이펙티브 코틀린 아이템 41: hashCode의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 41: hashCode의 규약을 지켜라 해시 테이블 Map, Set : 컬렉션에 요소를 빠르게 추가하고 컬렉션에서 요소를 빠르게 추출해야한다고 할때 사용할 수 있는 자료구조 Map, Set은 중복 비허용 성능을 좋게 만드는 해결 방법 해시 테이블 해시 테이블은 각 요소에 숫자를 할당하는
이펙티브 코틀린 아이템 40: equals 의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 40: equals 의 규약을 지켜라 동등성 코틀린에는 두 가지 종류의 동등성(equality)이 있다. 구조적 동등성(structural equality) : equals 메서드와 이를 기반으로 만들어진 == 연산자(!= 포함)로 확인하는 동등성이다. 레퍼런스적 동등성(referent
이펙티브 코틀린 아이템 39: 태그 클래스보다는 클래스 계층을 사용하라
이펙티브 코틀린(클래스설계) 아이템 39: 태그 클래스보다는 클래스 계층을 사용하라 상수(constant) 모드를 가진 클래스를 많이 볼수 있다. 이러한 상수 모드를 태그(tag)라고 부르며 태크를 포함한 클래스를 태그 클래스라고 부른다. 태그 클래스는 서로다른 책임을 한 클래스에 태그로 넣는 문제를 가진다. 태그 클래스
이펙티브 코틀린 아이템 38: 연산 또는 액션을 전달할 때는 인터페이스 대신 함수 타입을 사용하라
이펙티브 코틀린(클래스설계) 아이템 38: 연산 또는 액션을 전달할 때는 인터페이스 대신 함수 타입을 사용하라 대부분의 프로그래밍 언어에서는 함수 타입이 없다. 그래서 액션을 전달할때 메서드가 하나만 있는 인터페이스를 전달한다 이러한 인터페이스를 SAM(Single Abstract Method)이라 부른다. 파라미터 전달
이펙티브 코틀린 아이템 37: 데이터 집합표현에 data 한정자를 사용하라
이펙티브 코틀린(클래스설계) 아이템 37: 데이터 집합표현에 data 한정자를 사용하라 떄로는 데이터를 한번에 전달해야 되는데 이럴때는 data 한정자를 사용해서 class를 만들면 좋다 toString equals와 hashcode copy : immutable 클래스를 만들때 유용하다. compoentN : 위치 기반
이펙티브 코틀린 아이템 36: 상속보다는 컴포지션을 사용하라
이펙티브 코틀린(클래스설계) 아이템 36: 상속보다는 컴포지션을 사용하라 단순하게 코드 추출 또는 재사용을 위해 상속을 하려고 한다면, 조금 더 신중하게 생각해야 한다. 간단한 행위 재사용 상속의 단점 상속은 하나의 클래스만을 대상으로 할 수 있다. 상속을 사용해서 행위를 추출하다 보면 거대한 Base 클래스를 만들게 되
이펙티브 코틀린 아이템 33: 생성자 대신 팩토리 함수를 사용하라
이펙티브 코틀린(객체생성) 아이템 33: 생성자 대신 팩토리 함수를 사용하라 생성자 역활을 대신해주는 함수를 팩토리 함수 팩토리 함수의 장점 함수의 이름을 붙일수 있다 함수가 원하는 타입을 리턴할 수 있다 호출될때 마다 새객체를 만들 필요가 없다 아직 존재하지 않는 객체를 리턴할 수 있다 객체 외부에 팩토리 함수를 만들면
이펙티브 코틀린 아이템 34: 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라
이펙티브 코틀린(객체생성) 아이템 34: 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라 기본 생성자 : 객체를 정의하고 생성하는 방법을 지정할때 사용하는 가장 기본적인 방법 점층적 생성자 패턴(telescoping constructor pattern) 코틀린은 디폴트 아규먼트(default argument)를 사용할
이펙티브 코틀린 아이템 35: 복잡한 객체를 생성하기 위한 DSL을 정의하라
이펙티브 코틀린(객체생성) 아이템 35: 복잡한 객체를 생성하기 위한 DSL을 정의하라 함수 타입의 몇가지 예 () Unit : 아규먼트를 갖지 않고, Unit을 리턴하는 함수 (Int) Unit : Int를 아규먼트로 받고, Unit을 리턴하는 함수 (Int) Int : Int를 아규먼트로 받고, Int를 리턴하는 함수
이펙티브 코틀린 아이템 32: 추상화 규약을 지켜라
이펙티브 코틀린(추상화 설계) 아이템 32: 추상화 규약을 지켜라 규약은 개발자들의 단순한 합의 무언가를 할 수 있다는 것이 그것을 해도 괜찮다는 의미는 아니다. 상속된 규약 클래스를 상속하거나 다른 라이브러리의 인터페이스를 구현할 때는 규약을 반드시 지켜야 된다. 프로그램을 안정적으로 유지하고 싶으면 규약을 지켜야 된다
이펙티브 코틀린 아이템 31: 문서로 규약을 정의하라
이펙티브 코틀린(추상화 설계) 아이템 31: 문서로 규약을 정의하라 함수가 무슨일을 하는지 명확하게 설명하고 싶다면 KDoc 주석을 붙혀주는것이 좋다. 일반적인 문제는 행위가 문서화 되지 않고 요소의 이름이 명확하지 않다면 이를 사용하는 사용자는 현재 구현에만 의존하게 된다. 이러한 문제는 예상되는 행위를 문서화만 잘해도
이펙티브 코틀린 아이템 30: 요소의 가시성을 최소화하라
이펙티브 코틀린(추상화 설계) 아이템 30: 요소의 가시성을 최소화하라 API를 설계할때 간결한 API를 선호하는 이유 작은 인터페이스는 배우기 쉽고 유지하기 쉽다. 기능이 많은 클래스보다 작은 클래스이 이해하기 쉽다. 유지보수가 편하다. 변경을 가할떄는 기존것을 숨기는것 보다 새로운것을 만드는것이 편하다 그래서 가시성을
이펙티브 코틀린 아이템 29: 외부 API를 랩(wrap)해서 사용하라
이펙티브 코틀린(추상화 설계) 아이템 29: 외부 API를 랩(wrap)해서 사용하라 랩(wrap) 해서 API를 사용할떄 장점 문제가 있다면 래버(wrapper)만 변경하면 되서 변화에 쉽게 대응 할수 있다. 프로젝트 스타일에 맞춰서 API의 형태를 조절할수 있다. 특정 라이브러리에서 문제가 발생하면 래퍼를 수정해서 다
이펙티브 코틀린 아이템 28: API 안정성을 확인하라
이펙티브 코틀린(추상화 설계) 아이템 28: API 안정성을 확인하라 시멘틱 버저닝 MAJOR 버전: 호환되지 않는 수준의 API 변경 MINOR 버전: 이전 변경과 호환되는 기능을 추가 PATCH 버전: 간단한 버그 수정 어노테이션 @Experimental: 안정적이지 않음 @Deprecated: 더 이상 사용되지 않음
이펙티브 코틀린 아이템 27: 변화로부터 코드를 보호하려면 추상화를 사용하라
이펙티브 코틀린(추상화 설계) 아이템 27: 변화로부터 코드를 보호하려면 추상화를 사용하라 상수 이름을 붙일 수 있다. 나중에 값을 쉽게 변경 가능하다. 함수 일반적인 알고리즘을 함수로 추출 하면 코드를 항상 기억해 두지 않아도 된다 함수의 단점 함수는 상태를 유지 하지 않는다. 함수 시그니처를 변경하면 프로그램 전체에
이펙티브 코틀린 아이템 26: 함수 내부의 추상화 레벨을 통일하라
이펙티브 코틀린(추상화 설계) 추상화란 : 복잡한 자료, 모듈, 시스템 등으로 부터 핵심적인 개념 또는 기능을 간추려 내는것을 말한다. 추상화를 설계한다는 것은 단순하게 모듈 또는 라이브러리로 분리한다는 의미가 아니라 함수를 정의할 때는 그 구현을 함수 시그니처 뒤에 숨기게 되는데 이것이 바로 추상화다. 추상화의 목적 복
이펙티브 코틀린 아이템 25: 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라
이펙티브 코틀린(재사용성) 아이템 25: 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라 코틀린은 멀티플랫폼을 지원해서 코드를 서로 다른 플랫폼에서 공유가 가능하다 공통 모듈을 추출해서 재사용하면 좋다. 참조
이펙티브 코틀린 아이템 24: 제네렉 타입과 variance 한정자를 활용하라
이펙티브 코틀린(재사용성) 아이템 24: 제네렉 타입과 variance 한정자를 활용하라 위에 코드에서 파라미터 T는 variance 한정자(out 또는 in)이 없으므로 기본적으로 invariant(불공변성) 입니다. 제네릭 타입으로 들어가는 타입들이 서로 관련성이 없다는 의미 만약 어떠한 관련성을 원한다면 out 또는
이펙티브 코틀린 아이템 23: 타입 파라미터의 섀도잉을 피하라
이펙티브 코틀린(재사용성) 아이템 23: 타입 파라미터의 섀도잉을 피하라 지역 파라미터가 외부 스코프에 있는 프로퍼티를 가린다. 이를 새도잉이라고 한다. 위와 같이 선언하면 타입 파라미터가 새도잉된다. 하지만 위처럼 독립적으로 동작합니다. 위처럼 선언해야 의도한 방식대로 동작할것입니다. 독립적으로 선언하고 싶으면 이름을
이펙티브 코틀린 아이템 22: 일반적인 알고리즘을 구현할 때 제네릭을 사용하라
이펙티브 코틀린(재사용성) 아이템 22: 일반적인 알고리즘을 구현할 때 제네릭을 사용하라 타입 아규먼트를 사용하는 함수를 제네릭 함수라고 부른다.(예 stdlib에 있는 filter 함수) 타입 파라미터는 컴파일러에 타입과 관련된 정보를 제공하여 컴파일러가 타입을 정확하게 추측할수 있다. 제네릭 제한 타입 파라미터의 중요
이펙티브 코틀린 아이템 21: 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라
이펙티브 코틀린(재사용성) 아이템 21: 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라 property delegate 를 사용하는것이 property delegation 이라고 부른다. 코틀린에서 lazy 함수 제공 프로퍼티 위임을 사용하면 변화가 있을때 이를 감지하는 observable 패턴을 쉽게 만들수 있다.
이펙티브 코틀린 아이템 20: 일반적인 알고리즘을 반복해서 구현하지 말라
이펙티브 코틀린(재사용성) 아이템 20: 일반적인 알고리즘을 반복해서 구현하지 말라 기존에 구현된 내용을 활용하면 장점 코드가 짧아진다. 코드 작성 속도가 빨라진다. 직접구현할때의 실수를 줄일수 있다. 제작자가 한번만 최적화하면 사용하는 모든곳에서 혜택을 받을수 있다. 표준라이브러리 살펴보기 stdlib는 확장함수를 활용
이펙티브 코틀린 아이템 19: knowledge를 반복하지 말라
이펙티브 코틀린(재사용성) 재사용성 : 프로그램 언어의 핵심 특성 아이템 19: knowledge를 반복하지 말라 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. knowledge 를 반복하여 사용하지 말라 DRY 규칙, WET 안티패턴, SSOT(Singe Source of Truth)
이펙티브 코틀린 아이템 18: 코딩 컨벤션 지켜라
이펙티브 코틀린(가독성) 아이템 18: 코딩 컨벤션 지켜라 문서를 보면 알수 있듯이 잘 정리된 코딩 컨벤션을 가지고 있다. 코틀린 커뮤니티에 속한 사람이면 이러한 코딩 컨벤션에 익숙해지는것이 좋다. 장점 어떠한 프로젝트도 쉽게 이해 할수 이다. 다른 외부 개발자도 프로젝트 코드를 쉽게 이해할수 있다. 다른 개발자도 코드
이펙티브 코틀린 아이템 17: 이름 있는 아규먼트를 사용하라
이펙티브 코틀린(가독성) 아이템 17: 이름 있는 아규먼트를 사용하라 메소드의 Argument 용도가 분명하게 보이지 않을경우가 있다. 위처럼 joinToString에 | 값이 무엇을 뜻하는지 분명하지 않다. 코틀린에서는 이름있는 아규먼트를 지원한다. 물론 위와 같은 코드도 의미를 명확하게 알수 있다. 이름있는 아규먼트는
이펙티브 코틀린 아이템 16: 프로퍼티는 동작이 아니라 상태를 나타내야 한다
이펙티브 코틀린(가독성) 아이템 16: 프로퍼티는 동작이 아니라 상태를 나타내야 한다 프로퍼티는 사용자 정의 게터와 세터를 가질수 있다. 파생 프로퍼티 (derrived property) : var을 사용해서 만든 읽고 쓸 수 있는 프로퍼티는 게터와 세터 정의가 가능, val 로 읽기 전용 프로퍼티를 만들때는 field가
이펙티브 코틀린 아이템 15: 리시버를 명시적으로 참조하라
이펙티브 코틀린(가독성) 아이템 15: 리시버를 명시적으로 참조하라 무언가를 더 자세하기 설명하기 위해 명시적으로 긴코드를 사용할때가 있다. 대표적으로 함수와 프로퍼티 지역 또는 톱레벨 변수가 아닌 다른 리시버로부터 가지고 온다는것을 나타낼때가 있다. 예를 들면 클래스의 메서드라는것을 나타내기 위한 this가 있다. 리시
이펙티브 코틀린 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라
이펙티브 코틀린(가독성) 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라 코틀린은 개발자가 타입을 지정하지 않아도 타입을 지정해서 넣어주는 굉장히 수준 높은 타입 추론 시스템을 가지고 있다. 이는 개발시간을 줄여주거나 코드를 줄여줘서 가독성이 크게 향상 된다. 하지만 유형이 명확하지 않을때 남용하지 말자.
이펙티브 코틀린 아이템 13: Unit? 을 리턴하지 말라
이펙티브 코틀린(가독성) 아이템 13: Unit? 을 리턴하지 말라 Unit? 은 Unit 과 null을 반환할수 있다. 하지만 읽을때 오해의 소지가 있으며 예측하기 어려운 오류를 만들수 있다. Unit? 이 붙은 함수가 만들어지면 아래와 같은 코드가 나올수 있다. 이부분은 가독성 측면에서 이해하기 어렵다. 참조
이펙티브 코틀린 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라
이펙티브 코틀린(가독성) 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라 연산자 오버로딩 할때는 항상 신중 해야 된다. 코틀린에서는 각 연산자의 의미는 항상 같게 유지된다. 그래서 오버로딩해서 연산자의 의미를 바꾸면 혼란스럽게 된다. 분명하지 않는 경우 Infix functions(두개의 변수 가운데 오는
이펙티브 코틀린 아이템 11: 가독성을 목표로 설계하라
이펙티브 코틀린(가독성) 아이템 11: 가독성을 목표로 설계하라 코틀린은 간결성을 목표로 설계된 언어가 아니다 가독성을 항상 신경쓰자. 개발자가 코드를 작성하는데 1분 읽는데 10분 걸린다. 인식 부하 감소 가독성은 사람마다 다르게 느낄수 있다. 이해하기 쉬운지는 읽는 사람이 얼마나 많은 관용구(구조, 함수, 패턴)에 익
이펙티브 코틀린 아이템 10: 단위 테스트를 만들어라
이펙티브 코틀린(안정성) 아이템 10: 단위 테스트를 만들어라 지금 까지 코드를 안전하게 만드는 방법에 대해 이야기 했다 코드를 안전하게 만드는 가장 좋은 방법은 다양한 테스트를 해보는것이다. 단위 테스트의 일반적인 내용 일반적인 유즈케이스(happy path) 일반적인 오류케이스 와 잠재적 문제 에지 케이스와 잘못된 아
이펙티브 코틀린 아이템 9: use를 사용해 리소스를 닫아라
이펙티브 코틀린(안정성) 아이템 9: use를 사용해 리소스를 닫아라 Closeable를 구현하고 있는 클래스들을 처리 할때 try finally 를 사용해서 close 메소드를 호출 java의 try with resource 대신 use 와 Reader.useLines 확장 메소드를 제공한다. 참조
이펙티브 코틀린 아이템 8: 적절하게 null을 처리하라
이펙티브 코틀린(안정성) 아이템 8: 적절하게 null을 처리하라 null 은 값이 부족하다(lack of value)는 것을 나타낸다. String.toIntOrNull() String을 Int로 적절하게 변환할수 없을때 null을 반환 Iterable<T .firstOrNull(() Boolean) 주어진 조건에 맞는
이펙티브 코틀린 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라
이펙티브 코틀린(안정성) 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라 함수가 원하는 결과를 만들어 낼 수 없을때 이러한 상황을 처리하는 방법은 크게 두가지가 있다. null 또는 실패를 나타내는 sealed 클래스를 리턴한다. 예외를 throw 한다 예외는 예외 적인 상황이 발생했을때 사용하는
이펙티브 코틀린 아이템 6: 사용자 정의 오류보다는 표준 오류를 사용하라
이펙티브 코틀린(안정성) 아이템 6: 사용자 정의 오류보다는 표준 오류를 사용하라 IllegalArgumentException 과 IllegalStateException 는 require 와 check 를 사용해 throw 할수 있는 예외 IndexOutOfBoundsException : 인덱스 파라미터 값이 범위를 벗어
이펙티브 코틀린 아이템 5: 예외를 활용해 코드에 제한을 걸어라.
이펙티브 코틀린(안정성) 아이템 5: 예외를 활용해 코드에 제한을 걸어라 확실하게 어떤 형태로 동작해야 하는 코드가 있다면 예외를 활용해 제한을 거는것이 좋다. require 블록 : 아규먼트를 제한할 수 있다. check 블록 : 상태와 관련된 동작을 제한할 수 있다. assert 블록 : 어떤것이 true인지 확인할수
이펙티브 코틀린 아이템 4: inferred 타입으로 리턴하지 말라
이펙티브 코틀린(안정성) 아이템 4: inferred 타입으로 리턴하지 말라 코틀린의 타입 추론은 가장 널리 알려진 코틀린의 특징이다. 타입추론을 사용할 때는 몇 가지 위험한 부분이 있다. 우선 할당 떄 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다 절대로 슈퍼 클래스 또는 인터페이스로 설정되지
이펙티브 코틀린 아이템 3: 최대한 플랫폼 타입을 사용하지 말라
이펙티브 코틀린(안정성) 아이템 3: 최대한 플랫폼 타입을 사용하지 말라 코틀린에서는 null safety 메커니즘을 사용해 NPE는 거의 찾아 보기 힘들다. 코틀린에서 자바 코드를 사용할때 @Nullable 어노테이션이 붙어 있으면 String?으로 변경하고 @NotNull 이면 String으로 선언하면 되는데 아무 어
이펙티브 코틀린 아이템 2: 변수의 스코프를 최소화하라
이펙티브 코틀린(안정성) 아이템 2: 변수의 스코프를 최소화하라 상태를 정의할 때는 변수와 프로퍼티는 스코프를 최소화 하는것이 좋다. 프로퍼티보다 지역 변수를 사용하는것이 좋다. 최대한 좁은 스코프를 갖게 변수를 사용하자. 여러 프로퍼티를 한꺼번에 설정해야 하는 경우에는 구조분해 선언을 사용하는 것이 좋다. 스코프를 좁게
이펙티브 코틀린 아이템 1: 가변성을 제한하라
이펙티브 코틀린(안정성) 아이템 1: 가변성을 제한하라 var 나 mutable 객체를 사용하면 상태를 가질수 있다. 상태를 가지는것은 양날의 검이다. 그래서 가변성을 제한하는것을 추천한다. 코틀린은 가변성을 제한하는것이 쉽게 만들어져 있다. 읽기 전용 프로퍼티(val) 가변 컬렉션과 읽기 전용 컬렉션 구분 데이터 클래스
도메인 주도 설계 구현-애플리케이션
도메인 주도 설계 구현 애플리케이션(Application) 핵심 도메인 모델과 상호 교류하며 이를 지원하기 위해 잘 조합된 컴포넌트의 집합 사용자 인터페이스 도메인 객체 랜더링 애그리게잇 인스턴스로 부터 데이터 전송 객체(DTO) 랜더링하기 애그리게잇 내부 상태를 발행하기 위해 중재자를 사용하자 도메인 페이로드 객체로부터
도메인 주도 설계 구현-바운디드 컨텍스트 통합
도메인 주도 설계 구현 바운디드 컨텍스트 통합(Integrating Bounded Contexts) 통합의 기본 1. 하나의 바운디드 컨텍스트가 애플리케이션 프로그래밍 인터페이스(API)를 노출하고 다른 바운디드 컨텍스트가 원격 프로시저 호출(RPC)을 통해 해당 API를 사용하는 방법 2. 메시징 메커니즘을 사용하는 것
도메인 주도 설계 구현-리파지토리
도메인 주도 설계 구현 리파지토리(repository) 리파지토리는 보통 저장소의 위치를 말하는데 주로 그안에 저장된 항목의 안전이나 보존을 위한 장소로 여긴다. 이런 기본적인 원리들은 DDD 리파지토리에도 적용된다. 일반적으로 애그리게잇 타입과 리파지토리 사이에는 일대일의 관계가 성립한다. 정확히 말하자면 애그리게잇만이
도메인 주도 설계 구현-팩토리
도메인 주도 설계 구현 팩토리(factory) 도메인 모델 내의 팩토리 팩토리는 도메인 모델 내에서 객체 생성외의 추가적인 책임을 가질수도 있고 그럴지 않을 수도 있다. 애그리게잇 루트상의 팩토리 메소드 신중한 생성 과정을 통해 클라이언트가 짊어져야 하는 부담을 줄이고 모델의 표현력을 얻을수 있다. 서비스의 팩토리 서비스
도메인 주도 설계 구현-애그리게잇(2)
도메인 주도 설계 구현 애그리게잇(aggregate) 규칙 : 경계의 밖에선 결과적 일관성을 사용하라 하나의 애그리게잇 인스턴스에서 커맨드를 수행할 때 하나 이상의 애그리게잇에서 추가적인 비즈니스 규칙이 수행돼야 한다면 결과적 일관성을 사용하자 큰 규모의 트래픽이 많은 엔터프라이즈에선 애그리게잇 인스턴스가 절대적이고 완전
도메인 주도 설계 구현-애그리게잇(1)
도메인 주도 설계 구현 애그리게잇(aggregate) 스크럼 핵심 도메인에서 애그리게잇 사용하기 큰 클러스터의 애그리게잇 크기가 큰 애그리게잇은 처음엔 그럴싸해 보이지만 실제론 실용적이지 않다. 의도치 않게 트랜젝션이 주기적으로 실패하는데 실패의 원인은 실제 비즈니스 규칙이 아닌 잘못된 고정자를 기준으로 설계 하여 실패
도메인 주도 설계 구현-모듈
도메인 주도 설계 구현 모듈(module) 모듈 설계하기 DDD 컨텍스트에서 모델 안의 모듈은 서로 간에 높은 응집도를 갖고 있는 도메인 객체를 담는 이름이 붙여진 컨테이너 역활을 수행하며 각이 다른 모듈에 있는 클래스 사이에 낮은 결합도를 유지하는 것이 목표가 돼야 한다. 모듈 설계의 간단한 규칙 1. 모델링 개념에 맞
도메인 주도 설계 구현-도메인 이벤트(4)
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 이벤트 저장소 한 바운디드 컨텍스트에 모든 도메인 이벤트를 하나의 저장소에 유지 관리할때 장점 1. 이벤트 저장소를 큐를 사용해 메시징 인프라를 통해 모든 도메인 이벤트를 발행한다. 2. 폴링 중인 클라이언트에게 REST 기반 이벤트 알림을 전달하기 위해 같
도메인 주도 설계 구현-도메인 이벤트(3)
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 도메인 모델에서 이벤트 발행하기 구독자 어떤 컴포넌트가 도메인 이벤트에 구독자를 등록하는가? 일반적으로 애플리케이션 서비스에서 등록이 이뤄지며 때론 도메인 서비스에서도 등록할 수 있다. 헥사고날 아키텍처를 사용할 땐 애플리케이션 서비스가 도메인 모델의 직접적
도메인 주도 설계 구현-도메인 이벤트(2)
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 이벤트의 모델링 이벤트를 모델링할 땐 해당 이벤트가 속한 바운디드 컨텍스트의 유비쿼터스 언어에 따라 이벤트와 속성을 명명하 애그리게잇의 커맨드 오퍼레이션 실행에 따른 결과로 그 이름은 보통 커맨드로 부터 파생된다 이벤트가 제공하는 행동적 오퍼레이션은 어떻게
도메인 주도 설계 구현-도메인 이벤트(1)
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 도메인이 발생한 사건을 위해 도메인 이벤트를 사용하자. 이벤트는 아주 강력한 모델링 도구이다. 일단 도메인 이벤트를 사용하는 법을 알고 나면 여러분은 이에 중독돼서 어떻게 여지껏 도메인 이벤트 없이 살아 왔는지 의아 해질 것이다. 언제 그리고 왜 도메인 이벤
도메인 주도 설계 구현-서비스
도메인 주도 설계 구현 서비스(Service) 도메인 내에서 서비스란 도메인 고유의 작업을 수행하는 무상태의 오퍼레이션이다. 도메인 모델에서 서비스를 생성할 필요가 있음을 알리는 가장 정확한 지표는 에그리게잇이나 값 객체 상에 수행해야 하는 오퍼레이션이 메소드로는 부적절하게 느껴질때이다. DDD를 사용하면 이런 전술의 코
도메인 주도 설계 구현-값 객체(3)
도메인 주도 설계 구현 값 객체(Value Objects) 값 객체의 저장 데이터 모델 누수의 부정적 영향을 거부하라. 값 객체를 데이터 저장소로 저장하는 대부분의 경우는 비정규화된 방식으로 저장된다. 즉 해당 특성은 부모 엔터티 객체와 같은 데이터 베이스 테이블 행에 저장된다. 이는 데이터베이스에서 값을 가지고 오는 과
도메인 주도 설계 구현-값 객체(2)
도메인 주도 설계 구현 값 객체(Value Objects) 미니멀리즘으로 통합하기 값 객체를 사용해 유입되는 업스트림 컨텍스트로부터 다운스트림 컨텍스트의 개념을 모델링하자 불변값을 결과로 사용한다면 책임을 덜 수 있다. 값으로 표현되는 표준 타입 여러 시스템과 애플리케이션에선 표준타입이 필요하다. 표준 타입은 대상의 타입
도메인 주도 설계 구현-값 객체(1)
도메인 주도 설계 구현 값 객체(Value Objects) 종종 엔터티에 관한 고민의 그늘에 가려지긴 하지만 값 객체란 DDD의 필수적인 구성 요소이다. 가능한 위치 에서 엔터티 대신 값 객체를 사용해 모델링하도록 노력해야 한다 심지어 도메인 개념이 엔터티로 모델링돼야 할때도 엔터티의 설계는 자식 엔터티의 컨테이너보다는
도메인 주도 설계 구현-엔터티(4)
도메인 주도 설계 구현 엔터티(entity) 엔터티의 발견과 그들의 내부적인 특징 유효성 검사 모델 내의 유효성 검사를 사용하는 주 이유는 하나의 특성/속성, 전체 객체, 객체의 컴포지션 등의 정확성을 확인하기 위해서다 우리는 하나 이상의 단계로 이뤄진 유효성 검사를 통해 가능한 모든 문제를 다뤄야 한다. 특성/속성의 유
도메인 주도 설계 구현-엔터티(3)
도메인 주도 설계 구현 엔터티(entity) 엔터티의 발견과 그들의 내부적인 특징 분명하게 구분된 바운디드 컨텍스트의 유비쿼터스 언어는 도메인 모델의 설계에 필요한 개념과 용어를 제공한다. 엔터티와 속성을 알아내기 팀은 기술적이고 전술적인 모델링의 늪에 빠지길 원치 않는다 토론을 계속한 후에 팀은 단어를 만들어내여 요구사
도메인 주도 설계 구현-엔터티(2)
도메인 주도 설계 구현 엔터티(entity) 고유 식별자 사용자가 식별자를 제공한다. 사용자가 직접 고유 식별자의 세부사항을 입력할때 몇가지 문제점이 있다. 양질의 식별자를 생성하는 일을 사용자에게 의지한다는 점 애플리케이션이 식별자를 생성한다. 고유식별자를 생성하는 식별자 생성패턴 고유 식별자 (UUID) 전역 고유 식
도메인 주도 설계 구현-엔터티(1)
도메인 주도 설계 구현 엔터티(entity) 개발자는 도메인 보다 데이터에 초점을 맞추는 경향이 있다. 소프트웨어 개발에 관한 대부분의 접근법이 데이터베이스에 중점을 두기 때문에 DDD를 처음 접하는 사람에게 일어날 수 있는 현상이다. 풍부한 행동을 바탕으로 도메인 개념을 설계 하지 않고 주로 데이터의 속성과 연결을 먼저
도메인 주도 설계 구현-아키텍쳐(5)
도메인 주도 설계 구현 아키텍처 이벤트 주도 아키텍처 장기 실행 프로세스 실행자와 추적자? 일부 사람들은 실행자(executive)와 추적자(tracker)를 하나의 객체(애그리게잇)의 개념으로 합치는 편이 가장 간단한 접근법이라는 점을 발견했다. 장기 실행 프로세스는 종종 분산 병렬 처리와 관련이 있을 수 있지만, 분산
도메인 주도 설계 구현-아키텍쳐(4)
도메인 주도 설계 구현 아키텍처 커맨드 퀴리 책임 분리(CQRS) 버트랜드 마이어에 의해 고안된 이원리는 다음과 같은 내용을 따르고 있다. 객체 수준에서 이는 다음을 의미 한다. 1. 메소드가 객체의 상태를 수정한다면, 이 메소드는 커맨드이며 값을 반환하면 안된다. 2. 메소드가 값을 반환한다면 이 메소드는 쿼리이며 직접
도메인 주도 설계 구현-아키텍쳐(3)
도메인 주도 설계 구현 아키텍처 REST : 표현 상태 전송 REST는 웹의 아키텍처가 형성된 이후 웹 아키텍처 자체를 기반으로둔 추론을 바탕으로 얻어진 이론적 결과이다. RESTful HTTP 서버의 주요 특징 리소스가 핵심개념이다. 자술적 메시지를 사용해 무상태로 의사소통한다 일부 HTTP 메소드는 멱등한데 이는 오류
도메인 주도 설계 구현-아키텍쳐(2)
도메인 주도 설계 구현 아키텍처 의존성 역행 원리 의존성이 영향을 주는 방식을 조정함으로써 전통적인 계층 아키텍처를 개선하는 방법이 하나 있다. 로버트 C 마틴에 의해 제안되었다. 상위 수준의 모듈은 하위 수준 모듈에 의존해선 안된다. 둘 모두 반드시 추상화에 의존해야 한다. 헥사고날 또는 포트와 어댑터 앨리스테이 콕빈은
도메인 주도 설계 구현-아키텍쳐(1)
도메인 주도 설계 구현 아키텍처 DDD의 가장 큰 장점 중 하나는 특정 아키텍처의 사용을 요구하지 않는다는 점이다. 핵심 도메인이 바운디드 컨텍스트의 중심에 머무르기 때문에 하나 이상의 아키텍처적 영향력이 전체 애플리케이션이나 전체 시스템에 영향을 미칠 수 있도록 해준다. 사용중인 모든 아키텍처의 영향을 정당화하고 정당화
도메인 주도 설계 구현-컨텍스트 맵(2)
도메인 주도 설계 구현 컨텍스트 맵 컨텍스트 맵이 필수적인 이유 세가지 컨텍스트를 매핑하기 모델의 경우엔 반갑지 않은 방문자 때문에 일반적으로 혼란과 버그를 발생시킨다. 모델러라면 따뜻하게 환영하지만, 질서와 조화를 존중한다는 조건을 지킬 때만 그렇다. 경계에 진입하는 모든 개념은 자신이 갖고 있는 권리를 설명 해야 하며
도메인 주도 설계 구현-컨텍스트 맵(1)
도메인 주도 설계 구현 컨텍스트 맵 둘 이상의 기존 바운디드 컨텍스트들 사이의 매핑을 보여주는 단순한 다이어그램을 그리는 방법이다. 컨텍스트 맵이 필수적인 이유 DDD를 위한 노력을 처음 시작할때 현재 프로젝트 상황의 시각적 컨텍스트 맵을 먼저 그리자 컨텍스트 맵은 상호 교류해야 할 시스템의 목록 뿐 아니라 팀 내부의 의
도메인 주도 설계 구현-도메인, 서브도메인, 바운디드 컨텍스트(4)
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 샘플 컨텍스트 모델을 안정적으로 만들수 있는 임시 개선 방안 모델을 책임 계층으로 리팩토링해 보안과 권한 기능을 현존하는 모델 아래의 논리적 계층으로 내려서 구분할 수 있다. 또 다른 대안으로, 분리된 핵심에 맞춰 작업할 수도 있다. 참조
도메인 주도 설계 구현-도메인, 서브도메인, 바운디드 컨텍스트(3)
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 바운디드 컨텍스트 이해하기 바운디드 컨텍스트는 그 안에 도메인 모델이 존재하는 명시적인 경계 명시적으로 다른 두 모델 내부에선 같거나 비슷한 이름의 객체임에도 서로 다른의미를 갖는 경우가 종종 있다. 두 모델을 명시적인 경계로 둘러싸면 각 컨텍스트 안의 각 개
도메인 주도 설계 구현-도메인, 서브도메인, 바운디드 컨텍스트(2)
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 왜 전략적 설계가 엄청나게 필수적인가 팀은 반듯이 비즈니스 도메인과 그에 따른 서브도메인은 물론 이고 그들이 개발하고 있는 바운디드 컨텍스을 이해하고 있어야 된다. 현실의 도메인과 서브도메인 도메인은 문제점 공간과 해결책 공간을 모두 갖고 있다. 문제점 공간은
도메인 주도 설계 구현-도메인, 서브도메인, 바운디드 컨텍스트(1)
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 큰그림 넓은 의미에서 도메인이란 한 조직이 행하는 일과 그 조직 안의 세계를 일컫는다. 조직이 무엇을 어떻게 하는지에 관한 모든 것을 하나의 도메인 모델에 포함해선 안된다 거의 모든 소프트웨어 도메인에는 다수의 서브 도메인이 있다. 서브도메인과 바운디드 컨텍스
도메인 주도 설계 구현-DDD를 시작하며(4)
도메인 주도 설계 구현 DDD를 시작하며 DDD 적용 난관 일반적인 문제점 유비쿼터스 언어를 만드는 데 드는 시간과 노력을 계산하는 것 도메인 전문가를 시작부터 참여시키고 프로젝트 내내 함께하는것 도메인 내의 해결책에 관한 개발자의 사고방식을 바꾸는것 DDD를 할때는 도메인 전문가의 참여가 필수이다. 많은 개발자가 DDD
도메인 주도 설계 구현-DDD를 시작하며(3)
도메인 주도 설계 구현 DDD를 시작하며 DDD는 어떻게 하는가 유비쿼터스 언어 : 팀내에 공유된 언어 도메인 전문가와 개발자간에 같이 공유된다. 메소드 명에도 고민을 해서 이름을 정함 해당 부분을 유비쿼터스 언어로 사용하여 코딩 문서도 시간이지나면 수정되지 않는다 코드상의 모델이 가장 지속적이고 유일하게 보장 되는 유비
도메인 주도 설계 구현-DDD를 시작하며(2)
도메인 주도 설계 구현 DDD를 시작하며 DDD가 해줄수 있는 일 DDD는 도메인 전문가와 소프트웨어 개발자가 비즈니스 전문가의 심적 모델을 반영한 소프트웨어를 함께 개발할 수 있게 해준다. 이팀은 도메인 전문가와 소프트웨어 개발자를 모두 포함하고 절대로 우리와 그들을 나누지 않는다. DDD는 비즈니스의 전략적 이니셔티브
도메인 주도 설계 구현-DDD를 시작하며(1)
도메인 주도 설계 구현 DDD를 시작하며 도메인 주도 설계라고 불리는 소프트웨어 개발 접근법은 우리가 높은 품질의 소프트웨어 모델을 설계 할수 있도록 해준다. DDD는 전략적인 동시에 전술적인 모델링 도구로서 중요한 비즈니스 목적을 달성시킬 수 있는 양질의 소프트웨어를 설계 할수 있게 해준다. 도메인 전문가는 단순한 직책
클린아키텍쳐-프레임워크는 세부사항이다.
프레임워크는 세부사항이다. 아무리 해도 프레임워크는 아키텍처가 될수 없다. 프레임워크 제작자는 당신이 풀어야 할 특별한 관심사를 염두에 두지 않는다. 프레임워크와의 결합은 우리가 만들어 놓은 프로그램을 프레임워크에 틀에 맞춰 버린다. 이 상황에서 모든 위험과 부담은 우리가 감수한다. 프레임워크와 결혼하지 말라. 프레임워크
클린아키텍쳐-웹은 세부사항이다.
웹은 세부사항이다. 중앙집중식과 분산방식으로 끊임 없이 움직여 왔다. GUI는 세부사항이다. 웹은 GUI이다. UI와 애플리케이션은 서로 독립적이여야 한다. 참조
클린아키텍쳐-데이터베이스는 세부사항이다
데이터베이스는 세부사항이다. 아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다. 즉 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어 올릴수 없다. 데이터 베이스는 데이터 모델이 아니다. 데이터 베이스는 일개 소프트웨어 일 뿐이다. 관계형 데이터베이스 애드거 커드는 1970년에 관계형 데이터 베이스의 원
클린아키텍쳐-클린 임베디드 아키텍처
클린 임베디드 아키텍처 먼저 동작하게 만들어라 소프트웨어가 동작하지 않는다면 사업은 망한다. 그리고 올바르게 만들어라 코드를 리팩터링해서 당신을 포함한 나머지 사람들이 이해할 수 있게 만들고 요구가 변경되거나 요구를 더 잘 이해하게 되었을 때 코드를 개선할 수 있게 만들어라. 그리고 빠르게 만들어라 코드를 리팩터링해서 요
클린아키텍쳐-테스트 경계
테스트 경계 테스트는 시스템의 일부이며 아키텍처에도 관여한다. 시스템 컴포넌트인 테스트 테스트는 태생적으로 의존성 규칙을 따른다. 테스트는 세부적이며 구체적인것 의존성은 항상 테스트 대상이 되는 코드를 향한다. 테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다. 테스트를 고려한 설계 테스트가 지닌 극단적인 고립성이 테스
클린아키텍쳐-크고 작은 모든 서비스들
크고 작은 모든 서비스들 SOA 와 MSA가 최근 큰인기를 끌고 있다. 그 이유는? 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다.(이는 일부만 맞는 말이다.) 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다.(이는 일부만 맞는 말이다.) SOA 아키텍처 관점에서 꼭 중요하다보 볼수는 없다.
클린아키텍쳐-메인 컨포넌트
메인 컨포넌트 모든 시스템에는 최소한 하나의 컴포넌트가 존재하고 나머지 컴포넌트를 생성하고 조정하며 관리한다. 메인 컴포넌트는 궁극적인 세부사항으로 가장 낮은 수준의 정책이다. 메인은 시스템 초기 진입점이다. 운영체제를 제외하면 어떤 것도 메인에 의존하지 않는다. 의존성 주입 프레임워크를 이용해 의존성을 주입은 바로 이
클린아키텍쳐-계층과 경계
계층과 경계 시스템이 세가지 컴포넌트로(UI, 업무규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 몇몇 단순한 시스템에서는 이 정도로 충분하다. 대다수의 시스템에서 컴포넌트의 개수는 이보다 훨씬 많다. 시스템에서 아키텍처의 경계를 발견하는 법을 차근차근 설명하고 있다. 변경의 축에서 정의되는 아키텍처 경계를 가로지르고
클린아키텍쳐-부분적 경계
부분적 경계 아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다. 마지막 단계를 건너뛰기 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것이다. 일차원 경계 완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태
클린아키텍쳐-프레젠터와 험블객체
프레젠터와 험블객체 프레젠터는 험블 객체 패턴을 따른 형태로 아키텍처 경계를 식별하고 보호하는데 도움이 됨 험블 객체 패턴 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안 되었다. 프레젠터와 뷰 뷰는 험블 객체이고 테스트 하기 어렵다. 이 객체에 포
클린아키텍쳐-클린 아키텍처
클린 아키텍처 육각형 아키텍처 data context and interaction(DCI) boundary control entity(BCE) 이들 아키텍처는 세부적인 면에서는 다소 차이가 있더라도 그내용은 상당히 비슷하다. 이들의 목표는 같은데 바로 관심사의 분리이다. 이들 아키텍처는 모두 시스템이 다음과 같은 특징을
클린아키텍쳐-소리치는 아키텍처
소리치는 아키텍처 아키텍처의 테마 이바 야콥슨이 Object Oriented Software Engineering이란 책에서 소프트웨어 아키텍처도 애플리케이션 유스케이스에 대해 소리처야 한다라고 말한다. 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올수 없다. 아키텍처의 목적 좋은
클린아키텍쳐-업무규칙
업무규칙 업무규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 컴퓨터상으로 구현했는지와 상관없이, 업무규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다. 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다. 우리는 이러한 유형의 객체를 엔티티라고 한다
클린아키텍쳐-정책과수준
정책과수준 소프트웨어 시스템이란 정책을 기술한것 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야 한다. 수준 수준을 엄밀하게 정의하자면 입력과 출력까지의 거리이다. 시스템의 임력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다. 입력과 출력을 다루는 정책이라면 시스템
클린아키텍쳐-경계 해부학
경계 해부학 경계 횡단하기 런타임에 경계를 횡단한다. 적절한 위치에서 경계를 횡단하게 하는 비결은 소스코드 의존성 관리에 있다. 두려운 단일체 아키텍처 경계 중에서 가장 단순하며 가장 흔한 형태는 물리적으로 엄격하게 구분되지 않는 형태다. 이 형태에선 함수와 데이터가 단일 프로세서에서 같은 주소 공간을 공유하며 그저 나름
클린아키텍쳐-선긋기
선긋기(Boundaries) 소프트웨어 아키텍처는 선을 긋는 기술이며 이 선을 경계라 부른다. 관련이 있는 것과 없는 것 사이에 선을 긋는다. 경계는 변경의 축이 있는 지점에 그어진다. GUI와 업무 규칙과는 다른 시점에 다른 속도로 변경되므로 둘사이엔 반드시 경계가 필요하다. 단일 책임 원칙은 어디에 경계를 그어야 할지
클린아키텍쳐-독립성
독립성 좋은 아키텍처는 다음을 지원해야 된다. 시스템의 유즈케이스 시스템의 운영 시스템의 개발 시스템의 배포 유즈케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다. 운영 운영 관점에서는 덜 실질적이며 덜 피상적인 업무를 맡는다. 개발 시스템을 설계하는 조직이라면 어ㅣ뜬지 그 조직의 의사소통 구조와 동일한
클린아키텍쳐-아키텍처란?
아키텍처란? 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다. 아키텍처의 주된 목적은 시스템 생명주기를 지원하는 것이다. 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다. 개발 팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다. 일례로 팀이 개발자 다섯 명
클린아키텍쳐-컴포넌트 결합도
컴포넌트 결합도 ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환이 있어서는 안된다. 숙취 증후군은 많은 개발자가 동일한 소스파일을 수정하는 환경에서 발생한다. 해결책으로 두가지 방법이 있다 주단위 빌드 의존성 비순환 원칙 주 단위 빌드 일주일에 4일동안은 서로를 신경쓰지 않다가 금요일날 변경된 코드를 통합하여
클린아키텍쳐-컴포넌트 응집도
컴포넌트 응집도 어떤 클래스는 어떤 컴포넌트에 포함시켜야 할까? REP : 재사용/릴리스 등가 원칙 CCP : 공통 폐쇄 원칙 CRP : 공통 재사용 원칙 REP : 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 메이븐, 라이닝언, RVM 같은 모듈 관리 도구가 등장한 시기 이 기간에 재사용 가능한 컴포넌트
클린아키텍쳐-컴포넌트
컴포넌트(Components) 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 잘설계된 컴포넌트라면 반드시 독립적으로 배포 가능한 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 링킹 로더의 등장으로 프로그래머는 프로그램을 개별적으로 컴파일하고 로드 할수있는 단위로 분할할수
클린아키텍쳐-인터페이스 분리 원칙
의존성 역전 원칙(DIP The Dependency Inversion Principle) 의존성이 추상에만 의존하며 구체에는 의존하지 않는 시스템 비현실적인 아이디어긴 하다. 자바 String은 구체 클래스이다. 이것을 추상클래스로 만들려는 시도는 없다 String은 매우 안정적이기 때문에 String 클래스가 변경되는일
클린아키텍쳐-인터페이스 분리 원칙
인터페이스 분리 원칙(ISP The Interface Segregation Principle) 언어와 ISP 정적 타입 언어 사용자가 import, use, include을 사용하도록 강제한다. 이렇게 소스 코드에 선언된 선언문으로 인해 소스코드 의존성이 발생한다.(자바는 약깐 틀리다.) 루비나 파이썬 같은 동적 타입언어
클린아키텍쳐-리스코프 치환 원칙
리스코프 치환 원칙(LSP Liskov Substitution Principle) 1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다. 상속을 사용하도록 가이드하기 정사각형/ 직사각형 문제 아키텍처 관점에서 LSP를 이해하는 최선의 방법은 이원칙을 어겼을때 시스템 아키텍처에ㅓㅅ 무슨일이 일어나는지 관찰하는 것이
클린아키텍쳐-개방 폐쇄 원칙
개방 폐쇄 원칙(OCP, Open Closed Principle) 버트란트 마이어가 1988년에 만들었는데 컴포넌트의 의존성 방향은 단방향으로 할려고 해야 되고 화살표 방향은 변경으로부터 보호하려는 컴포넌트를 향하도록 그려야 한다. 컴포넌트의 방향성을 제어하기 위해 컴포넌트를 추가 하기도 한다. 시스템을 컴포넌트 단위로
클린아키텍쳐-단일책임원칙
단일책임원칙(SRP: The Single Responsibility Principle) 이름만으로 헷갈릴수가 있다 모듈이 하나의 일만 해야 된다는 것으로 하나의 일만 해야 되는것은 함수이다. 단일 모듈의 변경이유는 하나여야만 한다. 모듈이란 무엇인가? 응집된 집합 단일 책임을 묶어주는 힘은 응집성이다. 징후1: 우발적 중
클린아키텍쳐-설계원칙
클린아키텍쳐 설계원칙 좋은 소프트 웨어 시스템은 클린코드로 부터 시작한다. 좋은 벽돌로 좋은 아키텍쳐를 정의하는 원칙이 SOLID 이다. SOLID는 함수와 데이터구조를 클래스로 배치하는 방법 그리고 이들 클래스를 서로결합하는 방법을 설명해준다. SRP : 단일책임원칙 모듈의 변경이유는 단하나여야 한다. OCP : 개방폐
클린아키텍쳐-함수형 프로그래밍
클린아키텍쳐 함수형 프로그래밍 함수형 프로그래밍 개념은 프로그래밍 그 자체보다 앞서 등장했다. 이 패러다임에서 핵심이 되는 기반은 람다 계산법으로 알론조 처치가 1930년대 발명했다 클로저와 자바의 극단적인 차이를 집어보면 자바는 가변변수를 사용하는데 클로저는 불변변수를 사용한다. 함수형 언어에서 변수는 변경되지 않는다.
클린아키텍쳐-구조적 프로그래밍
클린아키텍쳐 객체지향 프로그래밍 객체 지향이란 무엇인가? 데이터와 함수의 조합? 이것은 만족스러운 대답이 아니다. 캡슐화, 상속, 다형성 캡슐화 OO를 정의하는 요소중 캡슐화를 언급하는 이유는 데이터와 함수를 쉽고 효과적으로 캡슐화 하는 방법을 OO언어가 제공하기 때문이다. 헤더와 구현체를 분리하는 방식을 버리면서 강력한
클린아키텍쳐-구조적 프로그래밍
클린아키텍쳐 구조적 프로그래밍 데이크스트라가 초기에 인식한 문제는 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다는 사실이였다. 데이크스트라는 증명이라는 수학적인 원리를 적용하여 이문제를 해결하고자 했다. 그의 비전은 유클리드 계층구조를 만드는것이였다. 데이크스트라는 이연구를 진행하면서 goto문이 모듈을 더
클린아키텍쳐-패러다임 개요
클린아키텍쳐 패러다임 개요 구조적 프로그래밍 최초로 적용된 패러다임은 구조적 프로그래밍으로 데이크스트라가 발견했다. 데이크스트라는 점프(goto 문장)은 프로그램 구조에 해롭다는 사실을 제시 이러한 구조를 (if/then/else do/while/until)로 대채했다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해
클린아키텍쳐-두가지 가치에 대한 이야기
클린아키텍쳐 두가지 가치에 대한 이야기 행위 (Behavior) 첫번째 가치는 행위 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서이다. 아키텍처 부드러운 제품 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 부드러워야 한다. 다시 말해 변경하기 쉬워야 한다. 소프트웨어의 개발 비용의 증가를 결정짓는 주된
클린아키텍쳐-설계와 아키텍쳐란?
클린아키텍쳐 설계와 아키텍쳐란? 설계와 아키텍쳐와 차이점은 고수준이냐 저수준이냐의 차이일뿐 둘의 차이는 없다. 목표는? 소프트웨어 아키턱처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다. 빨리가는 유일한 방법은 제대로 가는것이다. 참조
클린코드(Smells and Heuristics)-part2
클린코드 냄새와 발견법(Smells and Heuristics) part2 함수 부정 조건은 피하라. 부정 조건은 긍정 조건보다 이해하기 어렵다 가능하면 긍정 조건으로 표현하라. 위에 코드가 아래 코드 보다 낫다. 함수는 한가지 일만 해야 한다. 함수를 짜다 보면 한 함수 안에다 여러 단락을 이어서 일련의 작업을 수행하고
클린코드(Smells and Heuristics)-part1
클린코드 냄새와 발견법(Smells and Heuristics) part1 주석 부적절한 정보 다른 시스템(svn, git, 이슈트렉커 등등)에 저장될 정보는 주석으로 부적절하다. 주석은 코드의 설계에 기술적인 설명을 부연하는 수단이다. 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더이상 쓸모가 없다. 중복
클린코드(Successive Refinement, JUnit Internals, Refactoring SerialDate)
클린코드 Successive Refinement(점진적 개선) 프로그래밍은 과학보다 공예에 가깝다. 클린코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미 점진적 개선을 하기 위해 TDD를 실천 하였고 그래서 하나 씩 개선해 나간 내용이다 이부분은 책으로 꼭 읽어 봐야 할듯 하다 책의 내용이 전체적으로 리펙
클린코드(Concurrency)
클린코드 Concurrency(동시성) 동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출스택을 살펴보면 프로그램 상태가 곧바로 드러난다. 단일 스레드를 디버깅하는 프로그래머는 정지점을 정한후 어느 정지점에 걸렸
클린코드(Emergence)
클린코드 Emergence(드러나다, 창발성) 켄트백의 간단한 설계규칙 4가지 모든 테스트를 실행한다. 중복을 없엔다. 프로그래머의 의도를 표현한다. 클래스와 매소드 수를 최소로 줄인다. 간단한 설계규칙 : 모든 테스트를 실행하라. 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한대로 돌아가는지 검증할 방법이 없다면
클린코드(Systems)
클린코드 Systems 이장에서는 높은추상화 수준에서 즉 시스템 수준에서 클린 코드를 구현하는 방법을 살펴 본다. 시스템 제작과 시스템 사용을 분리하라. 소프트웨어 시스템은 응용프로그램 객체를 제작하고 의존성을 서로 연결하는 시작단계와 시작단계 이후 이어지는 실행 단계를 분리해야 한다. 시작단계는 모든 응용 프로그램이 풀
클린코드(단위테스트)
클린코드 단위테스트 TDD 법칙 3가지 1. 실패하는 단위 테스트를 작성할 때까지 실제코드를 작성하지 않는다. 1. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 1. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로
클린코드(오류처리)
클린코드 오류처리 오류 코드를 처리 하는것은 클린코드와 연관이 있다. 흩어진 오류처리 코드때문에 코드를 이해하기 어려워진다면 클린코드라고 하기 어렵다. 오류처리 보다 예외를 사용하라 얼마전까지만 해도 예외를 지원하지 않는 프로그램 언어들이 많았다. 오류 플래그를 설정하거나 호출자에서 오류코드를 넘기는것이 다였다. 오류코드
클린코드(객체와 자료구조)
클린코드 객체와 자료구조 변수를 private으로 선언하는 이유가 있다 남들이 변수에 의존하지 않았으면 싶어서 이다. 자료 추상화 자료를 세세하게 공개하는것 보다 추상적인 개념으로 표현하는 편이 낫다. 인터페이스나 get/set함수만으로 추상화가 이뤄지지 않는다. 아무 생각 없이 get/set함수를 추가하는것이 가장 나쁘
클린코드(형식 맟추기)
클린코드 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰서 코드를 짜야 된다. 형식을 맞추려는 목적 코드 형식은 중요하다. 코드 형식은 의사소통의 일환이다. 적절한 행 길이를 유지하라. 일반적으로 큰파일 보다 작은 파일이 이해하기 쉽다. 신문기사 처럼 작성하라. 신문은 다양한 기사로 이뤄진다. 대다수 기사가 아주 짧다.
클린코드(의미 있는 이름)
클린코드 의미 있는 이름 검색하기 좋은 이름을 사용하라 위에 asis코드와 tebe코드중 어느것이 검색에 더 편하겠나? 일단 숫자형식은 검색하기 매우 까다롭다 이름을 의미 있게 지으면 검색하기 편해진다. 인코딩은 피하라 헝가리식 표기법 옛날 원도우 C API는 헝가리식 표기법을 매우 중요하게 생각했다. 실제로 컴파일하기
아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라.
이펙티브 자바 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라. 직렬화 프록시 패턴의 한계 1. 클라이언트가 멋대로 확장할 수 있는 클래스에는 적용할 수 없다. 1. 객체 그래프에 순환이 있는 클래스에도 적용할 수 없다. 참조
아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거타입을 사용하라.
이펙티브 자바 아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거타입을 사용하라. 생성자를 막아서 하나의 인스턴스만 생성하게 만든 싱근톤 하지만 Serializable구현하면 readResolve 이용해서 싱글턴을 만들어야 된다. 참조
아이템 88. readObject 메서드는 방어적으로 작성하라.
이펙티브 자바 아이템 88. readObject 메서드는 방어적으로 작성하라. 위에 코드를 역직렬화 하면 시작일이 종료일보다 늦게 생성 될수도 있다 그것을 방지하기 위해 readObject 메소드를 방어적으로 작성한 경우이다. 실행결과 위에서 참조를 훔쳐 와서 mp의 데이터를 변경했지만 p에 데이터가 변경되었다 위에 코드
아이템 87. 커스텀 직렬화 형태를 고혀해보라.
이펙티브 자바 아이템 87. 커스텀 직렬화 형태를 고혀해보라. 먼저 고민해보고 괜찮다고 판단될 때만 기본 직렬화 형태를 사용하라. 객체의 물리적 표현과 논리적 내용이 같다면 기본직렬화 형태라도 무방하다. 기본 직렬화 형태가 적합하다고 결정했더라도 불변식 보장과 보안을 위해 readObject 메서드를 제공해야 할 때가 많
아이템 86. Serializable을 구현할지는 신중히 결정하라.
이펙티브 자바 아이템 86. Serializable을 구현할지는 신중히 결정하라. Serializable 구현의 문제점 Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다. 버그와 보안 구멍이 생길 위험이 높아진다. 해당 클래스의 신버전을 릴리스할 때 테스트할 것이 늘어난다는 점이다. Serializable
아이템 85. 자바 직렬화의 대안을 찾으라.
이펙티브 자바 아이템 85. 자바 직렬화의 대안을 찾으라. 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는 것 이다. 여러분이 작성하는 새로운 시스템에서 자바 직렬화를 써야 할 이유는 전혀 없다. 신뢰할수없는 데이터는 절대 역질렬화하지 않는 것이다. 블랙리스트 방식보단 화이트리스트 방식을 추천 시스템을
아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대하지 말라.
이펙티브 자바 아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대하지 말라. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. 스레드는 당장 처리해야 할 적업이 없다면 실행돼서는 안된다. 실행결과 참조
아이템 83. 지연 초기화는 신중히 사용하라.
이펙티브 자바 아이템 83. 지연 초기화는 신중히 사용하라. 다른 모든 최적화와 마찬가지로 지연 초기화에 대해 해줄 조언은 필요할때까지 하지마라. 대부분의 상황에서 일반적인 초기화가 지연 초기화 보다 낫다. private final FieldType field1 = computeFieldValue(); 인스턴스 필드를 초
아이템 82. 스레드 안정성 수준을 문서화 하라.
이펙티브 자바 아이템 82. 스레드 안정성 수준을 문서화 하라. 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일뿐 API에 속하진 않는다. 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안정성 수준을 정확히 명시해야 한다. 스레드 안정성 수준이 높은순으로 나열한 목록
아이템 81. wait 와 notify 보다는 동시성 유틸리티를 애용하라.
이펙티브 자바 아이템 81. wait 와 notify 보다는 동시성 유틸리티를 애용하라. wait 와 notify는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하자. 동시성 컬렉션에서 동시성을 무력화하는 건 불가능하며, 외부에서 락을 추가로 사용하면 오히려 속도가 느려진다. 위에 코드에서 개선할 포인
아이템 80. 스레드보다는 실행자, 테스크, 스트림을 애용하라.
이펙티브 자바 아이템 80. 스레드보다는 실행자, 테스크, 스트림을 애용하라. java.util.concurrent 패키지가 등장 했고 여기에 executor framework라는 것이 포함이 되어 있다. 실행자 서비스는 쓰레드 보다 고급 api면서 조금더 다루기 쉽다. 실행자 서비스의 주요기능 특정 테스크가 완료되기를
아이템 79. 과도한 동기하는 피하라.
이펙티브 자바 아이템 79. 과도한 동기하는 피하라. 이전 상황을 동기화를 하지 않았을때 문제가 생기는 상황을 다뤘고 이번에는 과도하게 동기화를 했을때 생기는 문제를 다룰것이다. 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안된다. 실행결과 위에 코드는 정상적
아이템 78. 공유중인 가변 데이터는 동기화 해서 사용하라.
이펙티브 자바 아이템 78. 공유중인 가변 데이터는 동기화 해서 사용하라. 동기화(synchronized)는 배타적 실행뿐 아니라 스레드 사이에 안정적인 통신에도 필요하다. 위에 동작은 1초내에 종료할것이라고 생각이 되는가? vm에서 hoisting이 일어나서 종료되지 않는다. 위에 코드가 아래 코드 처럼 최적화 되는것을
아이템 77. 예외를 무시하지 말라.
이펙티브 자바 아이템 77. 예외를 무시하지 말라. catch블럭을 비워두면 예외의 존재 이유가 없어진다. 만약 예외를 무시하기로 결정했으면 이유를 주석으로 남기고 예외 변수 이름도 ignored로 바꿔놓도록 하자. 참조
아이템 76. 가능한 실패를 원자적으로 만들라.
이펙티브 자바 아이템 76. 가능한 실패를 원자적으로 만들라. 일반화 해서 말하자면 호출된 메서드가 실패 하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure atomic)이라고 한다. 메서드를 원자적으로 만드는 방법 가장 간단한 방법은 불변객체로 설계하는 방법이다. 아래는
아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라.
이펙티브 자바 아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라. 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 된다. IndexOutOfBoundsException 에서 실패값을 온전히 포착하도록 수정해 보겠다. 위에 처럼 수정하면 좀 더 좋은 코드가 될수도 있
아이템 74. 매서드가 던지는 모든 예외를 문서화 하라.
이펙티브 자바 아이템 74. 매서드가 던지는 모든 예외를 문서화 하라. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확하게 문서화 하자. 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.(비검사 예외도 문서화는 해야 된다.) 한클래스에 정의된 많은 메
아이템 73. 추상화 수준에 맞는 예외를 던져라.
이펙티브 자바 아이템 73. 추상화 수준에 맞는 예외를 던져라. 상위 계층에서는 저수준의 예외를 잡아 자신에 추상화 수준에 맞는 예외를 던져야 된다.(exception translation) 1. 저수준의 예외가 도움이 되면 예외 연쇄를 이용하라.(exception chaining) 1. 무턱대고 예외를 던지는 것 보다는
아이템 72. 표준 예외를 사용하라.
이펙티브 자바 아이템 72. 표준 예외를 사용하라. 표준 예외는 이미 익숙해서 다른사람이 익히기 쉽다. 그래서 가독성도 좋고 Exception, Throwable, Error, RuntimeException 은 직접 재사용하지 말자 예외 | 주요쓰임 | | IllegalArgumentException| 허용되지 않는 값이
아이템 71. 필요 없는 검사 예외 사용은 피하라.
이펙티브 자바 아이템 71. 필요 없는 검사 예외 사용은 피하라. 검사 예외는 꼭 필요한곳에 사용하면 프로그래밍 안정성을 높혀준다. 검사예외를 피하는 방법 1. 검사 예외를 회피하는 가장 쉬운 방법은 옵셔널이다. 1. 검사 예외를 던지는 메소드를 두개로 쪼개 비검사 예외로 바꿀수 있다.(이방식도 옵셔널과 비슷하다.) 참조
아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라.
이펙티브 자바 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라. 자바는 throwable 타입으로 3가지가 있는데 하나는 검사 예외(checked exception), 런타임 예외(runtime exception), 에러(error) 이렇게 세가지를 제공한다. 호출하는 쪽에
아이템 69. 예외는 진짜 예외 상황에서만 사용하라.
이펙티브 자바 아이템 69. 예외는 진짜 예외 상황에서만 사용하라. 예외는 그 이름이 말해주듯이 진짜 예외 상황에서만 사용하라. 절대로 일상적인 흐름 제어용으로 사용하면 안된다. 잘 설계된 API라면 클라이언트가 정상적인 흐름 제어에서 예외를 사용할 일이 없게 해야 한다. 옵셔널, 상태 검사 메서드, 특정값(null) 중
아이템 68. 일반적으로 통용되는 명명 규칙을 따르라.
이펙티브 자바 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라. 자바는 명명규칙이 잘 정의 되 있으며 자바언어 명세에 나타나 있다 명세에 따르는 명명규칙을 따라라. 패키지와 모듈 이름 1. 조직의 인터넷 도메인 이름을 역순으로 사용한다.(com.google, com.naver) 1. 예외 적으로 표준 라이브러리와 선
아이템 67. 최적화는 신중히 하라.
이펙티브 자바 아이템 67. 최적화는 신중히 하라. 모든 사람들이 새겨야 할 최적화 격언 맹목적인 어리석음을 포함해 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다 (심지어 효율을 높이지도 못하면서) 윌리엄 울프(Wulf72) (전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가
아이템 66. 네이티브 매서드는 신중히 사용하라.
이펙티브 자바 아이템 66. 네이티브 매서드는 신중히 사용하라. 자바 네이티브 인터페이스(JNI)는 자바 프로그램이 C나 C++ 같은 네이티브 언어로 작성한 메소드를 말한다. 자바 네이티브 인터페이스의 주요 쓰임세 레지스터리 같은 플랫폼 특화 기능을 사용한다. 네이티브 코드로 작성된 기존 라이브러리를 사용한다. 성능 개선
아이템 65. 리플렉션 보다 인터페이스를 사용하라.
이펙티브 자바 아이템 65. 리플렉션 보다 인터페이스를 사용하라. 리플렉션의 단점 컴파일 타임 타입 검사가 주는 이점을 하나도 누릴수 없다. 리플렉션을 이용하면 코드가 지저분해지고 장황해진다. 성능이 떨어진다. 리플렉션은 아주 제한적으로만 사용해야 그 단점을 피하고 이점을 취할수 있다. 만약에 써야 되도 리플렉션은 인스턴
아이템 64. 객체는 인터페이스를 사용해 참조하라.
이펙티브 자바 아이템 64. 객체는 인터페이스를 사용해 참조하라. 적합한 인터페이스가 있다면 매개변수 뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라. 아래는 좋은 예로 인터페이스 타입을 사용하였다. 아래는 나쁜예로 클래스 타입을 사용하였다. 인터페이스 타입을 사용하는 습관을 길러두면 프로그래밍이 훨씬
아이템 63. 문자열 연결은 느리니 주의하라.
이펙티브 자바 아이템 63. 문자열 연결은 느리니 주의하라. 자바 6 이후로 성능개선이 많이 되었지만 문자열 연결은 여전히 느리다. += 연결 보다는 StringBuilder를 활용하는것이 좋다. 실행결과 결과는 여전히 StringBuilder를 사용했을때가 더 빠르다 참조
아이템 62. 다른타입이 적절하다면 문자열 사용을 피하라.
이펙티브 자바 아이템 62. 다른타입이 적절하다면 문자열 사용을 피하라. 문자열은 다른 값을 대신하기 적절하지 않다. 숫자를 표현할때는 int, float 등등의 타입이 좋고 예/아니오는 boolean 타입이 좋다 문자열은 열거타입을 대신하기에 적합하지 않다. 상수를 열거할때 열거 타입이 훨씬 좋다. 문자열은 혼합타입을
아이템 61. 박싱된 기본타입 보단 기본타입을 사용하라.
이펙티브 자바 아이템 61. 박싱된 기본타입 보단 기본타입을 사용하라. 자바의 데이터 타입은 크게 두가지로 나눌수 있다. 기본 타입 : boolean, short, int, long, float, double, char 참조 타입 : String, List 기본 타입 |박싱된 기본타입(Wrapper Class) | byt
아이템 60. 정확한 답이 필요하면 float와 double 은 피하라
이펙티브 자바 아이템 60. 정확한 답이 필요하면 float와 double 은 피하라 개발을 할때 floating point 문제에 직면하게 되는데 그 내용에 대해서 푸는 문제이다. 먼저 아래 코드를 보면 실행결과 위에 결과가 전혀 다르게 나오게 된다 float와 double금융타입의 계산과는 맞지 않다. 그럼 대안으로는
아이템 59. 라이브러리를 익히고 사용하라.
이펙티브 자바 아이템 59. 라이브러리를 익히고 사용하라. 실행결과 위 코드는 문제가 있는데 보면 low가 50만개가 출력 되어야 되는데 66만개 이상 출력이 된다. 표준 라이브러리를 사용하면 그 코드를 작성한 전문가의 지식과 여러분보다 앞서 사용한 다른 프로그래머들의 지식을 활용할수도 있다. 위에는 java 9에 추가된
아이템 58. 전통적인 for문 보다는 for-each문을 사용하라.
이펙티브 자바 아이템 58. 전통적인 for문 보다는 for each문을 사용하라. 위에는 전통적인 for문이다. 위에 관용구 들은 while 문보다는 좋지만 가장 좋은 코드는 아니다. 실행결과 위에 코드를 수정해 보면 실행결과 그럼 향상된 for문을 사용하면 실행결과 또다른 케이스로는 실행결과 foreach문을 사용할수
아이템 57. 지역변수 범위를 최소화 하라.
이펙티브 자바 아이템 57. 지역변수 범위를 최소화 하라. 지역 변수의 범위를 최소화 하는 방법 지역 변수의 범위를 줄이는 가장 강력한 방법은 가장 처음 쓰일때 선언하기 이다. 거의 모든 지역변수는 선언과 동시에 초기화 해야 된다. 메서드를 작게 유지하고 한가지 기능에 충실하는것이다. 참조
아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라.
이펙티브 자바 아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라. 여러분의 API를 올바로 문서화하려면 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야 된다. 메서드 주석에서는 HOW가 아닌 WHAT을 기술해야 된다. 한클래스 안에 설명이 똑같은 맴버가 둘이상이면 안된다. 제네
아이템 55. 옵셔널 반환은 신중히 하라.
이펙티브 자바 아이템 55. 옵셔널 반환은 신중히 하라. 실행결과 위에 코드는 IllegalArgumentException을 발생시켜서 체크를 한다 위에서는 Optional을 사용하는것이 더 좋다고 했는데 바꾼 코드를 보면 실행결과 위처럼 옵셔널을 반환하는 메소드에는 절대로 null을 반환하지 말자 실행결과 위 처럼 옵셔
아이템 54. null이 아닌 빈컬렉션이나 배열을 반환하라.
이펙티브 자바 아이템 54. null이 아닌 빈컬렉션이나 배열을 반환하라. 실행결과 위에 코드는 흔하게 볼수 있는 코드이다 여기서 getCheeses()에서 null을 반환하는것보다 빈 컬렉션을 반환하는 것이 좋다. 빈컬렉션을 반환하는 일차 코드는 위처럼 바꿀수 있다. 위 코드는 매번 빈 콜렉션을 할당하니 다시 한번 바꿔
아이템 53. 가변인수(varargs)는 신중히 사용하라.
이펙티브 자바 아이템 53. 가변인수(varargs)는 신중히 사용하라. 가변인수(varargs) 메서드는 몇시한 타입의 인수를 0개 이상 받을수 있다. 실행결과 위에 코드는 간단한 가변인수의 활용예 이다. 또 인수가 하나이상이어야 할수도 있다. 코드를 바꿔보면 실행결과 위에 코드는 문제 점이 있다. 런타임에야 코드가 실
아이템 52. 다중정의(overloading)는 신중히 사용하라.
이펙티브 자바 아이템 52. 다중정의(overloading)는 신중히 사용하라. 실행결과 위에 코드는 집합 리스트 그외를 차례대로 출력할것 같지만, 실제로는 그외만 3번 출력된다. 다중정의(overloading)된 메소드(classify)중 어떤것을 호출할지는 런타임시에 정해진다. 위에 보면 for문에서 Collectio
아이템 51. 메서드 시그니처를 신중하게 설계하라.
이펙티브 자바 아이템 51. 메서드 시그니처를 신중하게 설계하라. 메서드 이름을 신중하게 짓자 편의 메서드를 너무 많이 만들지 말자 확신이 서지 않으면 만들지 말자. 매개변수 목록은 짧게 유지하자. 같은 타입의 매개변수가 연달아 나오는 경우가 특히 해롭다. 매개변수 타입으로는 클래스 보다 인터페이스가 낫다. hashmap
아이템 50. 적시에 방어적 복사본을 만들어라.
이펙티브 자바 아이템 50. 적시에 방어적 복사본을 만들어라. 클라이언트가 여러분의 불변식을 깨뜨릴려고 혈안이 되있다고 가정하고 방어적으로 프로그래밍 해야 한다. 위에 코드는 보면 불변식을 지키는것 같아 그럼 식을 깨뜨리는 방법을 써보면 실행결과 위에 처럼 참조가 열려 있으므로 생성시점과는 상관 없이 불변식을 깨뜨릴수 있
아이템 49. 매개변수가 유효한지 검사하라.
이펙티브 자바 아이템 49. 매개변수가 유효한지 검사하라. 매서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 이러한 제약은 반드시 문서화해야 되며 몸체가 실행되기전 검사해야된다. java 7에 추가된 requireNonNull 매서드는 유연하고 사용하기도 편하니 더이상 null 검사를 수동으로
아이템 48. 스트림 병렬화는 주의해서 적용하라.
이펙티브 자바 아이템 48. 스트림 병렬화는 주의해서 적용하라. 스트림 병렬화를 하면 어떻게 될까? 위에 소스는 응답하지 않는다. 이유는 데이터 소스가 Stream.iterate거가 중간연산으로 limt를 쓰면 파이브라인 병렬화로 성능을 개선할수 없다. 대체로 스트림의 소스가 ArrayList, HashMap, HashS
아이템 47. 반환타입으로 스트림보다 컬렉션이 낫다.
이펙티브 자바 아이템 47. 반환타입으로 스트림보다 컬렉션이 낫다. 반환타입으로 스트림보다 컬렉션이 나은 이유가 둘다 iterable을 구현하고 있지만 스트림은 iterable을 extend 하지 않아서 loop문이 정상적으로 동작 되지 않는다. 그래서 스트림으로 반환하면 무조건 forEach문을 사용해야 된다 그래서 선
아이템 46. 스트림에서는 부작용 없는 함수를 사용하라
이펙티브 자바 아이템 46. 스트림에서는 부작용 없는 함수를 사용하라. 스트림 패러다임의 핵심은 계산을 일련의 변환으로 재구성하는 부분이다. 이때 각 단계는 가능한 한 이전 단계의 결과를 받아 처리 하는 순수 함수여야 한다. 순수 함수란 입력만이 결과에 영향을 주는 함수이다. 그래서 side effect가 없어야 된다.
아이템 45. 스트림은 주의해서 사용해라
이펙티브 자바 아이템 45. 스트림은 주의해서 사용해라 자바8에 추가된 스트림 API 핵심은 두가지 이다. 스트림은 데이터 원소의 유한 혹은 무한 시퀀스를 뜻한다. 스트림 파이프 라인은 이 원소들이 수행하는 원소 단계를 뜻한다. 스트림 파이프라인은 소스 스트림으로 시작되 종단 연산으로 끝나며, 그 사이에 하나 이상의 중간
아이템 44. 표준함수형 인터페이스를 사용하라.
이펙티브 자바 아이템 44. 표준함수형 인터페이스를 사용하라. 자바가 람다를 지원하면서 API를 작성하는 모범사례도 바뀌게 되었다. 상위클래스의 기본 클래스를 재정의 하여 원하는 동작을 하게 만드는 템플릿 메서드 패턴의 매력이 크게 줄었다. 먼저 함수형 인터페이스에 대해서 알아보자 위에 형태가 가장 기본적인 함수형 인터페
아이템 43. 람다보다 매서드 참조를 사용하라.
이펙티브 자바 아이템 43. 람다보다 매서드 참조를 사용하라. 람다가 익명 클래스보다 가장 큰 나은점은 간결함이다. 자바에서 람다 보다 더 간결하게 만들수 있는것이 있는데 그것은 메서드 참조이다. 실행결과 위에선 람다를 사용한 경우 코드 이다. 다시 메서드 참조를 사용하면 실행결과 코드가 간결해진다. 그럼 반대의 경우는
아이템 42. 익명클래스 보다 람다를 사용하라.
이펙티브 자바 아이템 42. 익명클래스 보다 람다를 사용하라. jdk 1.1부터 익명클래스를 사용했는데 jdk1.8에서 람다식을 적용하면서 코드를 더 짧게 가지고 갈수 있게 되었다. 자질구래한 코드들은 사라지고 어떻게 동작하는지에 초점을 맞추게 될수 있는 코드가 되었다. 자바에서 함수타입을 표현할때 추상메서드 하나만 담은
아이템 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라.
이펙티브 자바 아이템 41. 정의하려는 것이 타입(ElementType.TYPE)이라면 마커 인터페이스를 사용하라. 아무 구현이 없고 단지 자기를 구현하는 클래스가 특성 속성을 가짐을 표시해주는것 인터페이스를 마커인터페이스라고 한다. 대표적인 예가 Serializable이다 그럼 코드를 보면 마커인터페이스는 두가지 측면에
아이템 40. @Override 에너테이션을 일관성 있게 사용하라.
이펙티브 자바 아이템 40. @Override 에너테이션을 일관성 있게 사용하라. @Override를 달면 재정의를 잘못하는 경우를 알려준다 아래의 예를 보자. 실행결과 위에 코드에서 버그를 찾아 보자 위에서는 equals를 재정의 하려고 한것 처럼 보인다 그래서 일반규약인 hashCode도 재정의 했다. 그런데 위에는
아이템 39. 명명 패턴보다는 애너테이션을 사용하라
이펙티브 자바 아이템 39. 명명 패턴보다는 애너테이션을 사용하라 junit3 버전과 junit4 버전에 차이점을 보면 테스트 메소드가 무조건 test라는 단어로 시작이 되어야 되었는데 junit4버전은 @Test 어너테이션으로 대체 되었다. 명명 패턴에 문제점 1. 오타가 나면 안된다. 1. 올바른 프로그램 요소만 사용
아이템 38. 확장할수있는 열거 타입이 필요하면 인터페이스를 사용하라.
이펙티브 자바 아이템 38. 확장할수있는 열거 타입이 필요하면 인터페이스를 사용하라. 위에 처럼 인터페이스를 사용하여 Operation을 확장할수 있다. 다시 2개의 오퍼레이션을 확장 시키면 이렇게 확장을 하면 기존 연산에 쓰던 곳에서 계속 확장된것도 사용할수 있다. 테스트 코드를 다시 작성해서 돌려보면 실행결과 위에 코
아이템 37. ordinal indexing 대신 EnumMap을 사용하라.
이펙티브 자바 아이템 37. ordinal indexing 대신 EnumMap을 사용하라. 실행결과 위에 코드에는 문제점이 많다 배열을 사용해서 제네릭을 사용하지도 못했고 그래서 문제가 될 소지들이 있고 앞에서 말했던 잘못된 동작을 할수있는 사항이 많다 이런 상황에서는 EnumMap이 존재한다 EnumMap으로 대체한 코
아이템 36. 비트필드 대신 EnumSet을 사용하라
이펙티브 자바 아이템 36. 비트필드 대신 EnumSet을 사용하라 실행결과 이렇게 사용하는것을 비트필드라고 한다 이렇게 하는것은 집합연산을 통해서 하나의 값을 쓸려고 하는것이다. 이것은 구닥다리 스타일이다. 이것을 enumset을 이용하면 아래의 코드이다. 실행결과 열거할수 있는 타입을 한데 모아 집합 형태로 사용한다고
아이템 35. ordinals 메서드 대신 instance fields를 사용하라
이펙티브 자바 아이템 35. ordinals 메서드 대신 instance fields를 사용하라 실행결과 위에서 ordinal() 메소드를 사용했는데 이것은 문제가 많다 일단 중간에 다른 값이 들어간다고 하면 값이 바뀌게 된다 실행결과 OCTET2를 추가하면 결과값이 바뀌게 된다. java doc를 보면 아래 처럼 Mos
아이템 34. int 상수 대신 열거 타입을 사용하라.
이펙티브 자바 아이템 34. int 상수 대신 열거 타입을 사용하라. 위에 정수 열거 패턴에는 단점들이 많다. 실제로 오렌지와 사과의 이름이 동일한것이 있으면 같은것을 구분하기 위해 앞에 명칭에 오렌지를 붙혀야 했다. 실행결과 그리고 위에 코드 처럼 오렌지를 보내야 하는 클래스에 사과를 보내도 문제가 생기지 않는다. 문자
아이템 33. 타입안전 이종컨테이너를 고려하라.
이펙티브 자바 아이템 33. 타입안전 이종컨테이너를 고려하라. 실행결과 위에 코드 처럼 간단하게 타입안전 이종 컨테이너를 구현할수있는데 여기서 2가지 문제 점이 있다. 악의적인 클라이언트가 Class객체를 제네릭이 아닌 로타입으로 넘기면 타입안정성이 깨진다. 실행결과 위에 코드에서 f.putFavorite((Class)I
아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라.
이펙티브 자바 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라. 가변인수(varargs) 메서드와 제네릭은 자바 5 때 함께 추가되었으므로 서로 시너지 효과가 날꺼라고 예상하는데 그렇지가 않다. 가변인수는 인수의 갯수를 클라이언트에서 조절할수 있게 해주는데 구현방식에서 헛점이 있다. 가변인수를 사용하면 배열이 하
아이템 31. 한정적 와일드카드를 사용해 API의 유연성을 높혀라.
이펙티브 자바 아이템 31. 한정적 와일드카드를 사용해 API의 유연성을 높혀라. 컴파일에러 위와 같은 에러가 난다. 보기에는 당연히 되어야 할것 같은데 에러가 난다. 제네릭은 불공변이기 때문이다. 실행결과 위에 처럼 자바에서는 이런상황을 대처하기 위해 와일드 카트 타입을 지원한다. 유연성을 극대화 하기위해서는 생산자나
아이템 30. 이왕이면 제네릭 메서드로 만들어라
이펙티브 자바 아이템 30. 이왕이면 제네릭 메서드로 만들어라 컴파일 메시지 위처럼 메시지가 나오는데 수정을 하면 메시지는 없고 정상적으로 나온다. 실행결과 실행결과 참조
아이템 29. 이왕이면 제네릭타입으로 만들어라
이펙티브 자바 아이템 29. 이왕이면 제네릭타입으로 만들어라 에서 만들었던 Stack 클래스를 제네릭타입으로 변환하는것이다. 위와 같은 코드가 있는데 배열을 제거 하는 방법이 2가지 있다. 아래는 첫번째 방법으로 elements의 타입을 E로 변환시켜서 하지만 new E[] 배열이 생성되지 않는다 그래서 Object[]을
아이템 28. 배열보단 리스트를 사용하라
이펙티브 자바 아이템 28. 배열보단 리스트를 사용하라 배열은 A가 B의 하위 타입이면 A[]이 B[]의 하위타입이다. 하지만 제네릭은 List< A 가 List< B 의 하위타입은 아니다 그래서 불변이다. 어떻게 보면 제네릭이 문제가 있는것 처럼 보이지만 문제는 배열이다. 실행결과 위에 코드는 컴파일시에는 문제가 없지만
아이템 27. 비검사 경고를 제거하라
이펙티브 자바 아이템 27. 비검사 경고를 제거하라 제네릭을 사용하면 비검사경고가 많이 보일것이다 가능한 비검사 에러를 제거 하자. 컴파일 명령줄 인수에 Xlint:unchecked를 추가하면 자세한 코멘트가 보인다. 만약 타입 안정성이 확보 되었다고 판단되면 @SuppressWarnings("unchecked") 사용하
아이템 26. raw 타입은 사용하지 말자.
이펙티브 자바 아이템 26. raw 타입은 사용하지 말자. 실행결과 위에 처럼 raw 타입을 선언하면 런타임 익셉션에 노출되어 있다. 컴파일시에 에러 위에 코드에서 타입을 선언하면 주석을 선언 할필요없이 코드에 어떤 값이 들어갈지 녹아 들어가있다. 그리고 컴파일시에 타입에러가 나온다 raw타입을 활용하면 제네릭이 주는 안
아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라
이펙티브 자바 아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라 소스파일에 톱레벨 클래스를 여러게 만들어도 자바 컴파일러는 문제가 없다. 아래는 Utensil.java 클래스에 톱레벨 클래스를 두개 지정해도 정상적이다. 위처럼 톱레벨클래스를 2개를 하나에 파일에 작성하게 되면 원치 않는 결과를 나타낼수도 있다. 위
아이템 24. 맴버클래스는 되도록 static으로 만들자
이펙티브 자바 아이템 24. 맴버클래스는 되도록 static으로 만들자 ava 프로그래밍 언어를 사용하면 다른 클래스에서 클래스를 정의 할 수 있습니다. 이러한 클래스는 중첩 클래스(Nested Classes) 라고하며 여기에 설명되어 있습니다. 중첩 클래스는 정적 및 비 정적이라는 두 가지 범주로 나뉩니다. static
아이템 23. 테그달린 클래스보다 클래스 계층구조를 활용하라.
이펙티브 자바 아이템 23. 테그달린 클래스보다 클래스 계층구조를 활용하라. 테그 달린 클래스의 단점은 여러 구현이 하나의 클래스에 담겨서 장황하고 오류를 내기 쉬우며 비효율 적이다. 테그 달린 구조는 클래스 계층구조의 아류일뿐이다. 위에는 테그달린 코드인데 장황하게 쓸때 없는 switch문 그리고 enum등이 들어가게
아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라
이펙티브 자바 아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라 상수인터페이스 안티패턴은 인터페이스를 잘못 사용한 예다. java.io.ObjectStreamConstants 등 자바의 상수형 인터페이스 상수형 인터페이스를 삼으면 구현체에서 PhysicalConstants.AVOGADROS NUMBER 이런식으
아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라.
이펙티브 자바 아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라. java 8 이전에는 인터페이스를 해치지 않고 메서드를 추가할 방법이 없었지만 지금은 default 메소드가 생겼다. 그렇다고 해서 모든 위험이 사라진것은 아니다. 생각할수 있느 모든상황에서 불변식을 해치지 않는 디폴트메소드를 작성하는것은 어려운 법
아이템 20. 추상 클래스 보다는 인터페이스를 우선하라
이펙티브 자바 아이템 20. 추상 클래스 보다는 인터페이스를 우선하라 자바는 단일상속만 되니 추상클래스는 단 하나만 구현할수 있다. 인터페이스는 어떠한 상속을 했던간에 인터페이스가 선언한 메소드를 구현하고 있으면 같은 타입으로 인식한다. 그래서 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을수 있다. 인터페이스의
아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라
이펙티브 자바 아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라 상속용 클래스는 재정의 할수 있는 매서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 된다. 이부분은 바로 직전 아이템인 18번에서 나왔듯이 상속을 했지만 내부사용을 상세하게 몰라서 메소드의 오작동을 이르켰다. 이부분은 문서
아이템 18. 상속보단 컴포지션을 사용하라
이펙티브 자바 아이템 18. 상속보단 컴포지션을 사용하라 상속은 코드를 재사용하는 강력한 수단이지만 항상 최선은 아니다. 상속의 단점 매서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 실행결과 위에서 실행결과를 3으로 예측했지만 6이 나왔다 문제점은 HashSet의 addAll메소드에 있다. 위에 코드에서 보면 내부적으로 a
아이템 17. 변경가능성을 최소화하라.
이펙티브 자바 아이템 17. 변경가능성을 최소화하라. 불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직한 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다. 객체의 상태를 변경하는 매서드를 제공하지 않는다. 클래
아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라.
이펙티브 자바 아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라. 위와 같은 클래스는 public fields를 통해서 접근이 가능하다 하지만 저런식으로 작성하면 캡슐화의 이점을 살리지 못하고 이렇게 되면 클라이언트 코드를 수정하지 않고 해당 정보를 수정할수 없다
아이템 15. 클래스와 맴버의 접근권한을 최소화 하라.
이펙티브 자바 아이템 15. 클래스와 맴버의 접근권한을 최소화 하라. 잘 설계된 컨포넌트와 어설프게 설계된 컨포넌트에 차이점은 내구 구현 정보와 데이터를 얼마나 잘숨겼는지에 따른다. 이런것을 은닉화라고 한다. 정보 은닉의 장점 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 시스템 관리 비용
아이템 14. Comparable을 구현할지 고려하라.
이펙티브 자바 아이템 14. Comparable을 구현할지 고려하라. Comparable 인터페이스의 유일무이한 메서드인 CompareTo메서드는 이번장에서 다룬 다른 메소드들과 달리 Object 메소드가 아니다. 성격은 두가지만 빼면 Object의 equals와 같다. 다른점은 단순 동치성 비교에 더해 순서까지 비교할
아이템 13. clone 재정의는 주의해서 진행하라.
이펙티브 자바 아이템 13. clone 재정의는 주의해서 진행하라. Cloneable을 구현한 클래스는 clone 메소드를 public으로 제공하고 사용자는 복제가 당연히 제대로 이뤄 질꺼라고 생각한다. clone 메소드의 일반규약 위에 일반규약으로 만든 클래스를 보겠다. 실행 결과 위에 코드는 일반적인 객체를 참고 하는
아이템 12. toString은 항상 재정의 하라.
이펙티브 자바 아이템 12. toString은 항상 재정의 하라. Object의 toString은 우리에게 필요한 정보는 보이는것이 아니라 클래스이름@16진수 해시코드를 반환할뿐이다. equals와 hashcode 처럼 대단히 중요하진 않지만 toString은 항상 재정의 하는것이 좋다. 그럼 PhoneNumber클래스를
아이템 11. equals를 재정의 하려면 hashcode도 재정의 하라
이펙티브 자바 아이템 11. equals를 재정의 하려면 hashcode도 재정의 하라 equals를 재정의한 클래스에서 hashcode도 재정의 해야된다 그렇지 않으면 hashcode의 일반규약을 어기게 되어 해당 클래스를 hashmap, hashset 같은 컬렉션의 원소로 사용될때 문제를 일으킬것이다. hashcode
아이템 10. equals는 일반규약을 지켜서 재정의 하라
이펙티브 자바 아이템 10. equals는 일반규약을 지켜서 재정의 하라 equals는 재정의 하기 쉬워 보이지만 어렵다. 아래 사항중 하나라도 판단이 되면 재정의 하지 말자 각 인스턴스가 본질적으로 고유하다. 인스턴스의 논리적 동치성을 검사할일이 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에서 들어 맞는다
hashcode () 및 equals ()를 사용한 작업
hashcode () 및 equals ()를 사용한 작업 java.lang.Object 에서는 equals () 와 hashcode ()의 2 개의 중요한 오브젝트 비교 메소드를 제공합니다. 기본구현 equals (Object obj) : ava.lang.Object 가 제공하는 메소드 로, 인수로서 건네진 다른 객체가
아이템 9. try-finally 보다 try-with-resources 블럭을 사용하세요
이펙티브 자바 아이템 9. try finally 보다 try with resources 블럭을 사용하세요 일단 단점은 코드가 너무 지저분해진다. 두번째는 위에 코드에서 기기에서 문제가 생기면 in.read에서도 문제가 생길수 있고 close 할때도 문제가 생길수 있다. 위에 코드를 변경시키면 Try with Resourc
아이템 8. Finalizer와 Cleaner의 사용은 피하라
이펙티브 자바 아이템 8. Finalizer와 Cleaner의 사용은 피하라 finalize() 메소드에 대한 설명 jdk 9 C++에서의 destructor랑 다른것이다 자바에서 자원 반납은 try with resources또는 try finally 블럭을 통해서 한다. 단점 1. 언제 실행 할지 알수가 없다. gc의
아이템 7. 다쓴 객체의 참조를 해제하라
이펙티브 자바 아이템 7. 다쓴 객체의 참조를 해제하라 위에 처럼 스텍을 만들어서 객체를 저장하는데 다쓴객체의 참조해제를 하지 않아서 메모리 누수 현상이 있다. 위에 내용을 이해하기 위해서 일반적인 GC의 과정을 알아야 될것 같다. 문제가 될수 있는 부분은 stack.push 하는데 이부분은 Strong reference
아이템 6. 불필요한 객체생성을 피하라
이펙티브 자바 아이템 6. 불필요한 객체생성을 피하라 똑같은 기능의 객체를 매번 생성하기 보다는 객체하나를 재사용하는 편이 좋을수도 있다. 결과 위에서 보면 string을 선언 할때 생성자를 통해서 만든 1223과 기능적으로 완전히 똑같은 생성자를 통하지 않은 객체가 있다. 이것은 생성자를 통해서 만드는것은 불필요 한 일
아이템 5. 자원을 직접 명시 하지 말고 의존성 객체 주입(dependency injection)을 사용하라
이펙티브 자바 아이템 5. 자원을 직접 명시 하지 말고 의존성 객체 주입(dependency injection)을 사용하라 지금 대부분 자바 개발자들은 spring 프레임워크를 쓰면서 의존성 주입에 대한 이견은 없을 것입니다. 위에 방식으로 구현한 케이스와 비슷하게 아래 처럼 싱글턴방식으로 구현한 케이스 두가지는 흔한 방
아이템 4. 인스턴스화를 막으려면 private 생성자를 사용하라
이펙티브 자바 아이템 4. 인스턴스화를 막으려면 private 생성자를 사용하라 정적 팩토리 메소드만 모아 놓은 유틸클래스들은 의도치 않게 인스턴스화가 될수 있다. 그런 것을 막으려면 private 생성자를 사용해서 인스턴스 화를 막으면 좋다. 위에서는 정적팩토리 패턴을 제공하는 dateutil 클래스이다. 인스턴스화를
아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라
이펙티브 자바 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라 final 키워드로 싱글톤임을 보장함 위에 코드는 기본적으로 final 키워드로 싱글톤임을 보장한다. 정적 팩토리 패턴으로 싱글턴임을 보장 위에 코드는 싱글톤 구현에 두번째 방법인 정적 팩토리 패턴으로 싱글턴을 구현한 예제이다. 위에 코드
아이템 2. 생성자에 매개 변수가 많다면 빌더를 고려하자
이펙티브 자바 아이템 2. 생성자에 매개 변수가 많다면 빌더를 고려하자 정적 팩토리 메소드 패턴과 생성자와는 공통점이 있는데 선택적인 매개변수가 많을때 처리하기 곤란하다는것 이다. 점층적 생성자 패턴(telescoping constuctor pattern) 위와 같은 클래스가 있다. 이것은 광고 노출과 클릭에 대한 통계를
아이템 1. 생성자 대신 정적 팩토리 매소드 패턴(static factory method) 사용을 고려 해라
이펙티브 자바 아이템 1. 생성자 대신 정적 팩토리 매소드 패턴(static factory method) 사용을 고려 해라 클라이언트가 클래스의 인스턴스를 얻는 수단은 public 생성자 이다. 하지만 프로그래머가 알아 둬야 할 기법이 하나 있는데 그것이 정적 팩토리 매소드 패턴이다. 장점.1 이름을 가질수 있다. 위 클