안 좋은 코드 시리즈 4탄

 

 

 

안 좋은 코드 시리즈 4탄

 

16. 추측성 일반화 (YAGNI 원칙 위배)

불필요하게 복잡한 코드는 지양하자. 안 쓰는 메소드를 굳이 넣어서 주석 달지 말자. 

 

코드의 3원칙

(1) YAGNI - 미래를 생각해서 미리 기능을 추가해놓지 말자.

(2) KISS - 웬만하면 간단하고 이해하기 쉬운 것을 선택하자.

(3) DRY - don't repeat yourself . 중복을 피하자 (같은 코드와 로직을 반복하지 말자)

 

 

17. 긴 매개변수 목록

매개변수가 많으면 가독성이 떨어진다.

해결방법 ) 질의 함수로 바꾸기, 객체를 통채로 넘기기, 플래그 인수를 제거하기, 여러 함수를 클래스로 묶기

 

(1) 질의 함수로 바꾸기

클래스 변수에서 해결이 된다면 매개변수를 넣지 않고, 클래스 내에서 계산하고 바로 return 하는 것.

 

(2) 플래그 인수 제거하기

if - else 구조는 하나의 클래스 안에 두 가지 계산을 하는 것임(덜 객체지향적)

그래서 if에 해당하는 클래스와 else에 해당하는 클래스를 각각 만들어서 관리하는 것이 좋다.

 

 

18. 거대한 클래스 (Large Class)

클래스에 책임이 과중되면 코드가 복잡하게 되고, 

중복 코드 발생 가능성이 높아지고, 클래스 내의 필드와 메소드 간 연관성이 낮아지고 응집력도 떨어진다.

응집력 ) 클래스 내 필드와 메소드 간 연관성. 낮으면 객체지향 프로그래밍에 좋지 않다.

중복 코드를 함수로 추출하는 것이 중요하다. 

 

 

19. 메시지 체인

클래스도 프라이버시가 있다. 

클라이언트 코드에서 객체 내부 구조에 대해 많이 아는 것은 좋지 않다.

클래스 간 강한 결합은 피하자.  (예를 들면 클래스가 클래스에 꼬리를 물고 들어가는 것..)

 

 

20. 인터페이스 사용하지 않는 것

인터페이스와 추상 클래스를 잘 쓴다는 것은 객체지향에 대한 이해가 깊다는 것.

동일한 구조의 클래스는 하나의 인터페이스 아래 통합해 유연한 코드를 만들자. (슈퍼 클래스 추출하기)

 

추상클래스와 인터페이스의 차이는??

추상클래스 : 구현이 일부 완료된 부분 클래스. 공통된 것을 빼서 처리하는 것이 추상클래스.

인터페이스 : 이름(틀)만 제공한다. 여러 클래스를 이 틀에 맞춰 만들 수 있게 제공함.