본문 바로가기

프로그래밍 놀이터/디자인 패턴, 리펙토링125

[Clean Code] 클래스 ○ 클래스는 캡슐화 ( encapsulation ) 을 잘 활용한다. ○ 클래스는 작아야 한다. - 코드 라인도 적거니와 단일 책임 원칙, single responsibility principle( SRP ) 을 지켜야 한다. ○ 클래스는 응집도가 커야 한다. - 메소드와 변수가 서로 의존하며 논리적 단위로 묶인다는 의미. - 응집도가 낮은 녀석들은 다른 클래스로 뺄 수 있다. ○ 추상화를 잘 활용하면 변경이 쉽다. 2012. 2. 28.
[Clean Code] 형식 ☆ 형식을 맞추는 목적 - 코드는 혼자 짜는 경우가 적다. 의사소통과 서로의 코드에 대한 가독성 등을 고려했을 때 통일된 형식을 지키는 것이 좋다. ☆ 적절한 행 길이를 유지하라. - 클래스와 함수 등은 최대한 짧은 것이 좋다. ☆ 신문기사처럼 작성하라. - 신문기사처럼 읽어내려가는 형식으로, 중요한 것 ( 헤드라인 ) 은 가장 윗쪽에 오도록 배치한다. ☆ 개념은 빈 행으로 분리하라. ☆ 세로 밀집도를 높이고, 수직 거리는 줄여라. - 의미 없는 주석 등으로 연관성 있는 코드들을 떨어뜨리지 말라. - 비슷한 개념의 것. 종속 함수 등은 가까이에 배치하라. ☆ 변수선언은 그 변수를 사용하는 곳의 가장 가까운 곳에서 선언하라. ☆ 인스턴스 변수 ( member 변수 ) 는 상단에 모아서 선언하라. ☆ 가로 .. 2012. 2. 28.
[Clean Code] 주석. ♧ 주석은 나쁜 코드를 보완하지 못한다. ♧ 주석 대신 코드로 의도를 표현하라. ♧ 좋은 주석은 매우 한정적이다. - 법적인 주석 ( Copyright 등 기술 ) - 정보를 제공하는 주석 ( kk:mm:ss 형식 ) - 의도를 설명하는 주석 ( 한번에 이해하기 어려운 알고리즘 등을 설명 ) - 의미를 명료하게 밝히는 주석 ( API 자체가 잘못설계되어 이해가 어려울 때 이를 보충해주는 주석 ) - 결과를 경고하는 주석 ( API 형태로. 사용자에게 경고를 함. i.e) 오래 걸리는 작업처리. not-thread-safe ) - TODO 주석 - 중요성을 강조하는 주석 ( 직관적으로는 중요하지 않아서 삭제되거나 편집될 수 있는 부분을 경고 ) - 공개 API 의 Javadoc 형태 ♧ 나쁜 주석 - 별 .. 2012. 2. 28.
[Clean Code] 함수 ◇ 작게 만들어라 - 첫번째 규칙은 작게. 두번째 규칙도 작게. ◇ 블록과 들여쓰기를 확실하게 해라. ◇ 한가지만 해라!! - 함수는 한 가지를 해야 하고, 그 한 가지를 잘 해야 하고, 그 한가지만 해야 한다. ◇ 위에서 아래로 코드 읽기 : 내려가기 규칙 - 책을 읽어 내려가는 것처럼 정렬한다. ◇ Switch 문은 Class 로 분기한다. ( 최대한 사용을 자제한다. ) ◇ 서술적인 이름을 사용하라. ◇ 함수 인수를 적게 하라. - 가장 이상적인 인수 갯수는 0개 (무항) - 3개(삼항)은 가능한 피하는 것이 좋고, 4개 이상(다항)은 사용해선 안된다. ◇ 플래그 인수는 함수를 2개로 쪼개서 처리한다. ◇ 인수가 많을 경우에는 class 로 묶어서 전달하거나, member 변수를 사용한다. ◇ 부수.. 2012. 2. 28.
[Clean Code] 의미 있는 이름. □ 의도를 분명히 밝혀라. □ 그릇된 정보를 피하라. - 약어는 피하는 편이 좋다, - List 가 아니면 list 라는 변수명을 쓰지 않는다. ( 예를 들자면.. ) □ 일관성 있는 이름을 써라. - 한쪽에서 write 로 썼으면 계속 write 를 써라, state 등으로 일관성을 깨지 마라. □ 의미 있게 구분하라. - a1, a2, data, info 이런 의미가 불분명한 녀석은 의미있는 언어로 치환하라. - account, accounts, accountInfo, accountData 처럼 비슷하면서 구분이 안 되는 녀석은 확연히 구분되게 하라. □ 발음하기 쉽고 이해하기 쉬운 이름을 사용하라. - 그래야 의사소통이 쉽다. □ 검색하기 쉬운 이름을 사용하라. - 매직 넘버는 전역상수로 치환하라... 2012. 2. 28.
[Clean Code] 클린 코드란 무엇인가? 클린코드란? The C++ Programming Language 저자 Bjane Stroustrup - '보기에 즐거운' 코드. ( 오류, 메모리 누수, Race Condition, 일관성 없는 명명법 등은 즐겁지 않6다. ) - '한가지를 잘 하는' 코드. ( 함수, 클래스, 모듈은 주변과 연관성이 없이 (혹은 적게) 한가지 일만 한다. ) 나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 클린 코드는 한 가지를 제대로 한다. Object Oriented Analysis and Design.. 2012. 2. 28.
[Design Pattern/Java] equals 메소드를 오버라이드 할 때는 hashCode 메소드도 항상 같이 오버라이드 하자. 안녕하세요. 돼지왕 왕돼지입니다. 오늘은 equals 메소드를 오버라이드 할 때는 hashCode 메소드도 항상 같이 오버라이드 하자. 라는 주제로 이야기해보겠습니다. 이 글은 "Effective Java" 글을 요약한 내용입니다. hashCode 를 왜 override 해줘야 하는데? hashCode 메소드를 제대로 오버라이드 하지 않아 코드 결함이 생기는 경우가 흔합니다. equals 메소드를 오버라이드 하는 모든 클래스에서는 반드시 hashCode 메소드도 오버라이드 해야 합니다. 그렇지 않으면, Object.hashCode 메소드의 보편적 계약을 위반하게 되므로, HashMap 과 HashSet 및 HashTable 을 포함하는 모든 해시( hash ) 기반의 컬렉션들과 우리 클래스를 같이 사용할.. 2012. 2. 22.
[Design Pattern/Java] Equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. 안녕하세요. 돼지왕 왕돼지입니다. 오늘은 Equals 메소드를 오버라이딩 할 떄는 보편적 계약을 따르자. 라는 주제로 이야기해보고자 합니다. 이 글은 "Effective Java" 의 글을 요약 정리한 것입니다. Introduction. Object 의 function 들은 기본적으로 sub class 에서 override 하여 사용 하도록 설계하였습니다. 하여, 모든 Object 들은 기본적으로 Object 의 function 들을 override 하여 사용하는 것이 좋습니다. 하지만, equals 메소드를 오버라이딩 할 때는 보편적 계약을 따라야 합니다. Instance 의 동일 여부를 판정하는 equals 메소드의 오버라이딩은 간단한 것 같지만, 잘못되는 경우가 많아서 참담한 결과를 초래할 수 있기.. 2012. 2. 22.
[Design Pattern/Java] finalizer ( 파이널라이저 ) 사용을 피하자. 안녕하세요 돼지왕왕돼지입니다. 오늘은 finalizer (파이널라이저) 사용을 피하자. 라는 주제로 이야기를 해볼까 합니다. 이 글은 "Effective Java" 를 기반으로 작성하였습니다. Finalizer 왜 피해야 하는가? - Finalizer 는 예측 불가에다가 위험하기도 하며 일반적으로 불필요하다. 파이널라이저를 사용하면 예측이 어려운 프로그램 실행과 성능 저하 및 이식성의 문제가 생길 수 있다. 파이널라이저의 문제점 - 신속하게 실행된다는 보장이 없다. 객체가 사용할 수 없게 되는 시점부터 파이널라이저가 실행되는 시점까지는 긴 시간이 소요될 수 있다. 즉! 실행시간이 중요한 작업을 "절대!" 하지 말아야 한다는 것. ( ex) finalizer 에서 파일 닫기 ) - Finalizer 의 수.. 2012. 2. 13.