개요 2장은 객체의 생성과 파괴에 대해 다룸 객체를 만들어야 할 때와 만들지 말아야 할 때를 구분 올바른 객체 생성 방법 불필요한 생성을 피하는 방법 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 요령 1. 생성자 대신 정적 팩터리 메서드를 고려하라 일반적으로 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자이다. 클래스는 생성자와 별개로 정적 팩터리 메서드를 제공할 수 있다. JDBC같은 경우가 대표적인 예시이다. 장점 이름을 가질 수 있다. 생성자에 넘기는 매개 변수와 생성자 자체 만으로는 반환될 객체의 특성을 설명하지 못한다. 하지만, 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.반복..
객체지향의 사실과 오해를 읽고 쓰는 글입니다. 0. 개요 객체지향 프로그래밍이란 현실 속에 존재하는 사물을 최대한 유사하게 모방해 소프트웨어 내부로 옮겨오는 작업이라고 표현한다. 하지만, 이 책의 필자는 객체지향의 목표는 실세계를 모방하는 것이 아닌 새로운 세계를 창조하는 것이라 표현한다. 다시 말해, 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다. 1장에서는 객체지향에 관한 기본적인 내용을 설명하기 위해 잠시 동안 실세계의 모방을 진행한다. 1. 협력하는 사람들 커피를 구매하기 위해서는 주문하는 손님, 주분을 받고 바리스타에게 메뉴를 전달하는 캐시어, 커피를 제조하는 바리스타라는 역할이 존재한다. 각각은 이 세가지 역할이 협력하는 과정에서 자신이 맡은 바 책임을 다한다. “커피 주문”이라는..
클린코드 68 ~ 75 도입 잘 달린 주석은 어떤 정보보다 유용함. 반대로 경솔하고 근거없는 주석은 코드를 이해하기 어렵게 만든다. 또한, 주석은 “순수하게 선하지” 못하며, 기껏해야 필요악 정도이다. 코드에 비해 주석은 오래될수록 유지보수하기 어려움 ⇒ 오류 발생 ⇒ 최대한 사용 자제 주석보다는 코드를 깔끔하고 이해하기 좋게 만드는 것이 최우선 과제 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이뉴는 코드 품질이 나쁘기 때문 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드
이전자료 [Clean Code] - 3장 함수(1) 도입 프로그래밍 초창기 시스템은 루틴, 하위 루틴으로 나누어짐. 포트란, PL/1 시절에는 시스템을 프로그램, 하위 프로그램, 함수로 나눔. 지금은 함수만 남아있으며 어떤 프로그램이든 가장 기 leapday.tistory.com 방법 7) 부수 효과를 일으키지 마라! 때때로 함수를 통해 클래스 변수를 수정한다. 떄로는 함수로 넘어온 인수나 시스템 전역 변수를 수정한다. 이러한 경우들은 시간적인 결합(Temporal Coupling)이나 순서 종속성(Order Dependency)을 초래한다. boolean checkPassword(String userName, String password){ ... //if userName and password are..
도입 프로그래밍 초창기 시스템은 루틴, 하위 루틴으로 나누어짐. 포트란, PL/1 시절에는 시스템을 프로그램, 하위 프로그램, 함수로 나눔. 지금은 함수만 남아있으며 어떤 프로그램이든 가장 기본적인 단위가 함수이다. 이 장에서는 함수를 잘 만드는법을 소개함. 방법 1) 작게 만들어라! 함수를 만드는 첫째 규칙은 “작게!”이다. 그리고 두번쨰 규칙 또한 “작게!”이다. 함수는 작은 것이 좋다고 근거를 댈 수는 없지만, 작가의 오랜경험을 바탕으로 나온 조언이다. 그렇다면 얼마나 짧아야 좋은걸까?? 작가의 기준 = 블록과 들여쓰기 if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다. 대개 거기서 함수를 호출하기에 바깥을 감싸는 함수(enclosing function)가 작아지며, 블록 ..
도입 소프트웨어에서 변수, 함수, 인수, 클래스, 패키지 등 여러 부분에서 이름을 쓰게 된다. 더불어 소스코드, 소스파일이 담긴 디렉터리 등에도 마찬가지이다. 이렇듯 이름을 짓는건 프로그래밍의 시작이라 할 수 있고 이러한 이름들을 잘 짓는 방법을 알아보자 방법1) 의도를 분명히 밝혀라 말 그대로 이름에 의도를 분명하게 표현할 것**(정말 중요)** 변수의 존재 이유, 수행 기능, 사용 방법들에 대해 주석이 필요 없도록 만들어야함. int d; => elapsedTimeInDays, daysSinceCreation, daysSinceModification 등 위 예시와 같이 정확한 의미를 함축적으로 담아야 한다. ⇒ 코드 맥락이 코드 자체에 명시적으로 드러나야 함. 방법2) 그릇된 정보를 피하라 코드에 그..
클린 코드를 읽는 이유 모든 프로그래머는 좋은 코드를 짜고자 할 것이다. 하지만, 모든 프로그래머는 나쁜 코드를 짠 경험은 누구나 있다. 그 이유는 무엇일까? 몰라서? 급해서? 아마 모두 맞는 말이지만 어떤 이유에서는 나쁜 코드를 짜놓고 보통은 “나중에 다시 손보지 뭐” 라는 안일한 생각 때문이다. 이러한 생각은 르블랑의 법칙을 몰랐기 때문이다. 나중은 돌아오지 않는다. 나쁜 코드로 인해 치르는 대가 개발 속도를 크게 떨어뜨림 초반엔 진도가 빠르게 나가도 나중에 코드를 고칠때 간단한 변경이 없기 마련이다. 나쁜 코드가 쌓일 수록 쓰레기 더미는 쌓여가고 팀 생산성이 떨어짐 원초적 난제 개발 마감을 맞추기 위해 속도를 냄 → 속도를 내다보면 한 개발에 시간을 많이 투자하지 못함 → 나쁜 코드 양성 → 프로젝..
