본문 바로가기

분류 전체보기

Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item 19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았다면 상속을 금지하라 1. 재정의 메서드의 문서화 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야한다. 재정의 가능 메서드 : 호출 메서드의 API 설명에 기술, 호출 순서, 각각의 호출 결과 처리 영향 기술 호출할 수 있는 모든 상황을 남긴다. 백그라운드 스레드, 정적 초기화 과정에서 호출이 일어날 수 있는 상황 등 API 문서의 Implementation Requirements : 메서드의 내부 동작 방식 설명 메서드 주석에 @ImplSpec 태그를 붙여주면 자바독 도구가 생성된다. 좋은 API문서란 '어떻게'란 '무엇'을 하는지를 설명해야한다. 대치된다 : 그러나 상속이 캡슐화를 해치기 때문에 어쩔수 없다 - 클래스를 안전하게 상속할 수 있게 해야하기 때문 2. 상속 설..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] Item18. 상속보다는 컴포지션을 사용하라 상속이 안전 할 때 상위 클래스와 하위클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서 사용한다. 확장할 목적으로 설계되었고 문서화도 잘되었다. 상속이 안전하지 않을때 다른 패키지의 구체 클래스를 상속하는 것은 위험하다. 1. 하위 클래스가 깨지기 쉬운 이유 상속은 캡슐화를 깨뜨린다. 상위클래스의 구현에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상위클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 하위 클래스가 오동작할 수 있다. a. 자신이 다른 부분을 사용하는 자가사용 여부 public class InstrumentedHashSet extends HashSet{ private int addCount = 0; @Overrid public boolean add(E e){ add..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item17. 변경가능성을 최소화하라 불변 클래스 : 그 인스턴스의 내부 값을 수정할 수 없는 클래스 예 ) String, Wrapper Class, BigInteger, BigDecimal - 설계 구현 사용이 쉽다. 오류 여지가 적고 안전하다. 1. 불변 클래스 5가지 규칙 ㄱ. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. (setter) ㄴ. 클래스를 확장할 수 없게 한다. (extend X) ㄷ. 모든 필드를 final로 선언한다 ㄹ. 모든 필드를 private으로 선언한다. ​ [아이템 15] : 클래스와 멤버의 접근권한을 최소화하라 ​ [아이템 16] : public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 ㅁ. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 객체 참조 X - ge..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] Item16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 1. public 클래스의 가변 필드 절대 가변 필드를 public으로 노출하면 안된다. 캡슐화의 이점을 제공하지 못한다. API를 수정하지 않고는 내부 표현을 바꿀 수 없다. 불변식을 보장할 수 없다. 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. 패키지 바깥에서 접근할 수 있는 클래스라면 접근자(getter)를 제공하자. 클래스 내부 표현 방식을 언제든 바꿀 수 있다. package-private 클래스, private 중첩 클래스 는 데이터 필드를 노출해도 하등의 문제가 없다. package-private : 패키지 바깥 코드를 손대지 않고 데이터 표현 방식을 바꿀 수 있다. private 중첩 : 이 클래스를 포함하는 외부 클래스까지로 제한한다. 2. public 클래스의 불변 필드 ..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item 15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트 : 클래스 내부 데이터와 내부 구현정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는가 오직 API를 통해서만 다른 컴포넌트와 소통한다. [정보은닉, 캡슐화] 1. 정보 은닉의 장점 시스템 개발 속도를 높인다 - 여러 컴포넌트 병렬 개발 시스템 관리 비용을 낮춘다 - 컴포넌트 교체 비용 하락 성능 최적화에 도움이 된다 - 완성된 시스템을 프로파일리하고 최적화할 컴포넌트만 가능하다. [아이템 67 - 최적화는 신중히 하라] 소프트웨어 재사용성을 높인다 - 의존성이 낮은 컴포넌트라면 다른 환경에서도 유용 큰 시스템을 제작하는 난이도를 낮춘다 - 개별 컴포넌트 동작 검증 2. 정보 은닉 기본원칙 모든 클래스와 멤버의 접근성을 가능한 한 좁힌다 (최대한 public을 지양하는 듯) 접근성 : 요소가..
Dev Book Review/Clean Code 2020. 4. 29. CleanCode 2장 의미 있는 이름 1. 의도를 분명이 밝혀라 변수나 함수 클래스 이름은 의도가 분명한 이름이어야한다. 변수(함수, 클래스)의 존재 이유 변수(함수, 클래스)의 수행 기능 변수(함수, 클래스)의 사용 방법 // 변경 전 int d; //경과 시간 (단위: 날짜); // 변경 후 int daysSinceCreation; 코드의 단순성이 아닌 코드의 함축성을 고려해야한다 -> 코드 맥락을 코드 자체에 명시적으로 드러나야한다. 코드 맥락 정보 제공 방법 : 개념에 이름을 붙인다 // 변경 전 public List getThem(){ List list1 = new ArrayList(); for(int[] x : the List) if(x[0] == 4) list1.add(x); return list1; } /* 변경 후 - 각 칸..
Dev Book Review/Clean Code 2020. 4. 28. CleanCode 1장 깨끗한 코드 1. 코드가 존재하리라 코드는 요구사항을 표현하는 언어이다 언어는 요구사항에 가깝게한다 요구사항에서 정형구조를 뽑아낸다. 코드의 도움 없이 요구사항을 상세히 표현하기는 불가능하다 : 코드는 정밀한 표현이다. 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세도 코드이다. 프로그래밍 언어에서 추상화 수준은 점차 높아질 것이다. 2. 나쁜 코드 우리 모두는 좋은 코드가 중요하다는 사실을 안다. 회사가 망한 원인 -> 나쁜 코드 버그가 남아있고, 프로그램이 죽는 횟수가 늘어짐 출시에 바빠 코드를 마음대로 짜고, 기능을 추가할 수록 엉망이 되었다. 고행(wading) = 나쁜 코드를 헤쳐나간다 르블랑의 법칙(Leblanc's Law) = 나중은 결코 오지 않는다. 나중에 손보겠다고 한 코드 + 돌아간다..
Develop/Springboot 2020. 4. 28. 인터페이스 빈주입을 사용하는 이유 Springboot를 사용할 때 대부분, 인터페이스를 이용한 @Service 빈주입을 한다. 하지만 왜 하는지는 모르는채 사용만 했었는데, 백기선님의 유튜브 영상을 보고 깨닫게 되었다. 영상 : https://www.youtube.com/watch?v=C6nsjqrCJq4&feature=youtu.be 서비스 코드 public interface MyService { void doSomething(); } @Service public class MyServiceImpl implements MyService { @Override public void doSomething() { System.out.println("hello Im Impl Service"); } } 이렇게 서비스가 있는경우를 생각해보자. Co..

티스토리툴바