본문 바로가기

전체 글

 (60)
11. 시스템 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. Main 분리 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다. 팩토리 객체가 생성되는 시점을 애플리케이션이 결정해야 하는 경우 ABSTRACT FACTORY 패턴을 사용한다. 의존성 주입 Dependency Injection, DI 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 메커니즘이다. .... 중간부분은 스프링 공부 후 다시 읽어보는 게 좋겠다... 테스트 주도 시스템 아키텍처 구축 코드 수준에서 아케텍처 관심사를 분리할 수 있다면 ..
10. 클래스 클래스 체계 변수 목록 정적 공개 상수 static public 정적 비공개 변수 static private 비공개 인스턴스 변수 공개 변수 (거의 없다) 공개 함수 비공개 함수 (자신을 호출하는 공개 함수 직후) => 추상화 단계가 순차적으로 내려감 클래스는 작아야 한다 응집도가 높은 클래스를 선호한다. 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아지면 클래스를 쪼개야 한다는 신호다. 클래스를 쪼갤 수록 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다. 단일 책임 원칙 (SRP) 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙 객체 지향 설계에서 중요한 개념 클래스를 쪼갤 수록 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.는 말이 이해는 되는데 선뜻 적용하기 어렵게 느껴진다...
09. 단위 테스트 실제 코드를 짜기 전에 단위 테스트부터 짜라 TDD의 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 실제 코드가 진화하면 테스트 코드도 변해야 한다. 테스트 코드가 지저분할 수록 부담이 늘어난다. 깨끗한 테스트 코드는 실제 코드의 변경을 쉽게해서 유연성, 유지보수성, 재사용성을 제공한다. 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. Fast 빠르게 테스트가 느리면 자주 돌리지 못하게 되어 결국 코드 품질이 망가진다. Independent 독립적으로 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스..
08. 경계 유사한 경계 인터페이스를 사용할 때에는 여기저기 직접 넘기지 말고 캡슐화하여 사용하라. 클래스나 클래스 계열 밖으로 노출되지 않도록 한다. 학습 테스트 프로그램에서 사용하려는 방식대로 외부 API를 호출한다. 학습테스트의 장점 필요한 지식을 확보하는 손쉬운 방법이다. 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다. 아직 존재하지 않는 코드를 사용하기 우리에게 필요한 경계 인터페이스가 무엇인지 알게되면 모르는 부분을 떼어 분리하여 그 부분의 구현을 나중으로 미룰 수 있다. 깨끗한 경계 경계에 위치하는 코드는 깔끔히 분리해야하며 기대치를 정의하는 테스트 케이스도 작성한다. 새로운 클래스로 경계를 감싸거나 ADAPTER 패턴을 사용한다. 소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작..
07. 오류 처리 오류 코드보다 예외를 사용하라 논리와 오류 처리 코드를 구분하기 위함 테스트 작성법 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법이 권고됨 -> 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워짐 미확인 예외를 사용하라 확인 예외가 필요한 경우도 있지만 남용한 경우 거치는 모든 단계에 확인 예외를 추가해줘야 하는 번거로움이 생길 수 있음 감싸기 기법을 사용하라 호출자를 고려해 예외 클래스를 정의하라. 특히 외부 API를 사용하는 경우 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어듦 테스트하기에도 수월해짐 Null을 반환하지 마라 Null을 반환하는 코드는 호출자에게 문제를 떠..
06. 객체와 자료 구조 구현을 감추려면 추상화가 필요하다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 절차적인 코드와 자료구조 vs 클래스와 객체 지향 기법 객체와 자료 구조는 근본적으로 양분된다. 절차적인 코드와 자료구조 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 새로운 자료 구조를 추가하기 어렵다. (모든 함수를 고쳐야 함) => 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우에 더 적합 클래스와 객체 지향 기법 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. 새로운 함수를 추가하기 어렵다. (모든 클래스를 고쳐야 함) => 새로운 함수가 아니라 새로운 ..
05. 형식 맞추기 코드 형식은 의사소통의 일환이다. 원활한 소통을 장려하는 코드 형식 적절한 행 길이를 유지하라. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 성명하고 아래로 내려갈수록 의도를 세세하게 묘사한다. 생각의 사이에는 빈 행을 넣어 분리한다. 변수는 사용위치에 최대한 가까이 선언한다. *단, 인스턴스 변수는 클래스 맨 처음에 선언하며 C++의 경우 모든 인스턴스 변수를 클래스 마지막에 선언하는 가위 규칙을 적용함 세로 형식: 서로 밀접한 코드들은 가까이에 놓여야 한다. 종속함수. 한 함수에서 호출하는 다른 함수는 바로 그 아래에 정의되어 있어야 한다. 이렇게 표현하면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다.가로 형식: ~120자가 적당하다. 공백의 사용 할당 연산자 앞뒤로 공백을 주어 왼쪽..
04. 주석 한마디 "나쁜 코드에 주석을 달지 마라. 새로 짜라." - 브라이언 W. 커니핸, P.J. 플라우거 우리는 코드로 의도를 충분히 표현하지 못해서 주석을 사용한다. 주석은 거짓말을 한다. 프로그래머들이 주석을 유지보수하기 쉽지 않아 주석은 오래될수록 틀린 정보를 가질 가능성이 높다. 부정확한 주석은 더 이상 지킬 필요가 없는 규칙이나 지켜서는 안 되는 규칙을 명시한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 좋은 주석 저작권 정보와 소유권 정보 등의 법적인 주석 의도를 설명하는 주석 중요성을 강조하는 주석 결과를 경고하는 주석 //TODO 주석 Javadocs 책에는 안써있지만 개인적으로 사용하기 시작한 플랫폼의 버전이나 deprecated 등의 정보가 달려있을 때 유용했다. 나쁜 주석 독자와 제..

티스토리툴바