객체 지향 연습 하기 프로젝트

ppzxc
2018년 3월 30일•3 min

효과적으로 TDD, 리팩토링, OOP 연습해보기 (?)

  • 블랙잭 게임과 UML 공부, 디자인 패턴등 고급이라면 고급일수 있는 테크닉, 기술 등을 공부해 보면서, 기초가 튼튼하지 못하다는 느낌을 받음.
  • 업무든 공부든 프로젝트든 문제가 생기면, 문제를 해결하려, 결론으로 달려가기만 해서 원론적인 생각이나 고민, 깊이 없이 결과만 내놓고 이만하면 됐다는 마음을 먹음.
  • 학부시절 C, C++를 다뤘지만, 이마저도 기억이 희미함.
  • C는 절차지향, C++는 객체지향이며 업무에 사용하는 Java 조차도 절차지향적으로 코딩하고 있음…

따라서, 객체 지향의 기본, 기초를 튼튼히 닦고싶어 관련 자료부터 조사해 봄

CodeSquad, 조엘온소프트웨어 참고

  • 순수 프로그래밍 언어만으로 프로그램을 구현하는 연습 ( DB, 프레임웤 등 기타 부산물이 결합되면 테스트가 어려움 )

연습하기 좋은 프로그램

  • 게임과 같이 요구사항이 명확한 프로그램.
  • 의존관계가 없는 프로그램으로 연습.
  • 약간은 복잡한 로직이 있는 프로그램 -> 게임

예제

  • 로또 ( 콘솔 UI )
  • 사다리 타기 ( 콘솔 UI )
  • 볼링 게임 점수판 ( 콘솔 UI )
  • 체스 게임 ( UI 콘솔 )
  • 지뢰 찾기 게임 ( UI 콘솔 )

게임의 경우 규칙이 명확하기 때문

소트웍스 앤솔러지 - 객체 지향 생활 체조 9가지 원칙

규칙 1 메소드당 들여쓰기 한 번

  • 한 메서드 길이는 5줄로 제한하기
  • 한 메서드당 하나의 제어 구조
  • 한 메서드당 하나의 문장 단락

정확히 한가지 일을 하는 메서드로 작업을 하면, 코드가 달라지기 시작한다. 애플리케이션의 단위가 작아짐에 따라 재사용의 수준은 기하급수적으로 상승하기 때문이다.

규칙 2 else 예약어 금지

  • 읽기 힘든 지저분한 코드가 나오기 쉽다.
  • 조건문은 곧잘 코드 중복의 원흉이 되기도 한다.
  • STRATEGY 패턴은 다형성을 이용해 분기를 막는다. 상태 분기가 몇군데 걸쳐 중복되 있다면 STRATEGY 패턴 적용을 고민하라.
  • 간단한 경우라면 보호절(guard clause)와 조기 반환(early return)으로 대체 가능하다. [무슨 말이징~?]
  • 널 객체 패턴 (null object pattern)을 시도해보면 특정 상황에서 도움이 된다.

의미 없는 분기를 금하고, 분기가 있다면 여러 패턴을 이용해 else 조건문을 줄이라는 말인것 같다.

규칙 3 원시값과 문자열의 포장

  • 어떤 메소드가 int 값을 매개 변수로 받는다면, 그 메서드 이름은 해당 매개 변수의 의도를 나타내기 위해 모든 수단과 방법을 가리지 말자.
  • 원시형 변수로는 컴파일러가 의미적으로 맞는 프로그램 작성을 안내할 수 없다. 객체로라면 아주 사소하더라도 컴파일러와 프로그래머에게 그 값이 어떤 값이며, 왜 쓰고 있는지에 대한 정보를 전하는 셈이다.

원시값이나 문자열은 포장해서 그 사용법과 의미를 정확하게 전달하자.

규칙 4 한 줄에 한 점만 사용

  • 코드 한 줄에서라도 점이 하나 이상 있으면, 그 곳에서 다른 동작이 일어나고 있다는 뜻이다.
  • 어쩌면 두 객체를 동시에 다루고 있을 수도 있다.
String boardRepresentation() {
   StringBuffer buf = new StringBuffer();
   for (Location l : squares())
      buf.append(l.current.representation.substring(0, 1)); // 이곳..
   return buf.toString();
}

처음에 이해가 잘 안되어 어떤 부분인지 유심히 봤는데, 해당 부분이다. 리팩토링 포인트임을 숙지하자.

규칙 5 축약 금지

  • 메서드의 이름이 길어진다면, 책임 소재의 오류나 클래스의 부재라는 신호탄이다.
  • 클래스와 메서드 이름은 한두 단어로 유지하려고 노력하고 문맥이 중복되는 이름을 자제하자.
  • 클래스 이름이 Order라면, 메소드를 shipOrder라고 이름 지을 필요가 없다. 짧게 ship으로 표현하면, 클라이언트에서는 order.ship()으로 호출된다.
  • 이 훈련을 위해 모든 엔티티는 한두 단어로 된 이름을 축약 없이 가져야 한다.

의미 없는 이름 짓기를 피하자.

규칙 6 모든 엔티티를 작게 유지

  • 50줄 이상 되는 클래스와 파일이 10개 이상인 패키지는 없어야 한다는 뜻이다.

  • 50줄 이상의 클래스는 보통 한 가지 일 이상을 하는 것이며, 따라서 코드의 이해와 재사용을 점점 더 어렵게 끌고 간다.

  • 50줄 짜리 클래스는 스크롤 하지 않고도 한 화면에 볼 수 있다는 부가적인 혜택도 있으며, 한 눈에 파악하기도 쉽다.

  • 클래스를 작성할때 난감한 경우는 같이 있어야 말이되는 동작의 묶음이 있을 때다. 이는 패키지를 최대한 활용해야 하는 곳이기도 하다.

  • 클래스가 점점 작아지고 하는일이 줄어들며 패키지 크기를 제한함에 따라 패키지가 하나의 목적을 달성하기 위해 모인 연관 클래스들의 집합을 나타낸다는 사실을 알아차리게 된다.

  • 패키지도 클래스 처럼 응집력 있고 단일한 목표가 있어야 한다.

  • 패키지를 작게 유지하면 패키지 자체가 진정한 정체성을 지니게 된다.

규칙 7 2개 이상의 인스턴스 변수를 가진 클래스 사용 금지

  • 대부분의 클래스가 간단하게 하나의 상태 변수를 처리하는 일을 맡아 마땅하지만 몇몇 경우 둘이 필요할 때가 있다.
  • 새로운 인스턴스 변수를 하나 더 기존 클래스에 추가하면 클래스의 응집도는 즉시 떨어진다.

심화 내용인것 같다. 여러 관련 인스턴스 변수는 사실 일급 콜렉션안에서 연관되어 있다는 내용인데 이를 이용해 클래스를 쪼갤수 있다는 것이다. 사실 이해가 잘 안된다. 여러번 봐야 겠다 규칙 7

규칙 8 일급 콜렉션 사용

  • 콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.
  • 콜렉션은 그 자체로 포장돼 있으므로 콜렉션과 관련된 동작은 근거지가 마련된 셈이다.

필터에 대한 내용과 클래스를 그룹으로 묶고 원소 규칙을 적용하는 등 여러가지 일을 할 수 있단다.. 점점 이해가 안되기 시작한다. 이것 또한 다시 보기 규칙 8

규칙 9 게터/세터/속성 사용 금지

  • 말이 필요 없다.. 규칙 9
  • 7,8,9는 넘나 한방에 이해 안되는 것들..

끝으로

프로젝트 구현시 이를 지켜 TDD, 리팩토링과 함께 묶어 연습을 시작해야 할 때인것 같다!

By CodeSquade

  • 1단계 메소드 분리 연습 - 규칙 1, 2
  • 2단계 객체 분리 연습 - 규칙 3, 6, 7, 8
  • 3단계 객체 지향, 클린 코드 - 규칙 4, 5, 9

Reference

객체 지향
© 2019, Built with Gatsby