Nextstep 2회차 정리

오늘 강의는 크게 TDD와 OOP에 대한 강의였다.
그 동안 자바/스프링부트로 개발을 하면서 이론으로 배운 OOP를 내가 적용하고 있는게 맞는지, 이 이론을 어떻게 코드에 적용해야할지 헷갈렸는데 가려운 곳을 긁어주는 듯한 강의였다. 아하하는 포인트가 있었고(감동적일 정도) 이러한 가이드를 바탕으로 하나씩 이론을 적용해가면 OOP를 실전에 적용하는 센스가 점점 늘 것 같다.

이 한 강의만으로도 80만원의 돈이 아깝지 않았다.

[OOP 개념정리]

• Domain ? 현업에서 말하는 도메인과는 다른 의미, 코드에서의 도메인은 핵심 비즈니스 로직을 구현하고 상태를 가지는 객체를 의미함
• Setter는 캡슐화를 위반
• Getter도 사용을 지양(이 부분은 좀 충격, 게터를 남발하다보니 내 코드가 OOP를 실현하기 어려웠다는 것을 깨달았다.)
• 메서드/생성자 argument에 final 키워드(코틀린 스타일이라고 함. 그리고 불변이 유지보수 측면에서 중요하기 때문에 혹여나 내부에서 바꿀 수도 있는 가능성 원천 차단)
• 접근제어자 final은 상속/overriding을 막기 위해 쓰는게 좋음.(상속의 폐혜)
• OOP에서 무엇인가 비교할때 equals, hashcode, tostring을 이용하여 객체끼리 비교하는 습관(무심코 값끼리 비교하려고 하지 말 것)
• List를 전달할때 Collections의 unmodifiable api 이용
• Coupling ? 객체간 의존관계
• 메서드에 Public 접근제어자를 쓸 때 고심할 것. 정말 Public일때만 사용하라.(의존관계가 높아질 수로 리팩토링이 어려워짐)__(알고는 있는데 실제로 웹 개발시에 인터페이스, Public이 영향을 주는 경험을 한 적이 없어서 피부로 와닿지가 않는다. 스프링에서 서비스 인터페이스를 관습적으로만 사용했어서ㅠ)
• 도메인 객체에 한 번만(적게) 사용하는 메서드가 있을 경우? 클래스를 분리할 시점인지 고민하기(한 번만 사용했다는 건 다른 데서 중복이 있을 수 있어서 그런듯)
• public메서드를 위한 private 메서드는 그 갯수가 얼마든지 상관없다. 다만 public이 많아지면 클래스 분리를 고려
• 캡슐화가 잘 됐다는것(=역할 분리가 잘 됐다는 것)은 하나의 멤버변수를 모든 메서드가 사용하고 있는 상태(극단적으로 말해서) 이러면 버그 발생 빈도가 준다.
• 어떤 기능이 이 클래스의 책임인지 아닌지 고민

[TDD 개념정리]

• TDD 사이클 (테스트작성(실패) -> 로직구현 -> 테스트 성공 -> 리팩터링)
• TDD에서 가장 중요한 요구사항 분석(이라고하고 쪼개기라 읽는다.) 각각의 요구사항이 상태시점별(snapshot)로 고려되기 때문에 독립적이다. 이로 인해 작업 순서가 상관 없게 되는 것.
• main을 시작으로 개발을 시작하던 과거 방식은 작업 순서가 중요하지만 TDD는 그렇지 않다는 점이 장점.(회사에서 협업시에도 작업이 세분화/독립되어있기 때문에 더 효율적일듯)
• 단위테스트가 어려운 케이스들이 많다. I/O관련, 랜덤값, 날짜/시간 등등
• 테스트하기 어려운 부분과 쉬운부분을 분리하는 설계가 중요.
• 로직 복잡도가 높은 경우 TDD를 해야함. 효과가 좋기 때문.
• Test케이스와 Code는 정말 필요한 경우에 작성해야함. 유지보수 빡세짐. 뭐하나 고치면 테스트케이스도 다 고쳐야하니까, ex 메서드를 타 클래스로 옮김? 프로덕션 코드 뿐아니라 테스트도 다 옮겨야함.
• Fixture ? 테스트 전제가 되는 상태를 만드는 과정, 픽스쳐가 길어지면 의심할 것. 픽스쳐는 간단할 수록 좋다.
• Test만을 위한 메서드는 절대 생성하지 말 것. 그러나 생성자는 괜찮다.
• private 메서드는 public 메서드를 통해 간접적으로 테스트할 것. 그러나 private을 테스트하고 싶다는 열망이 강하게 들때는 다른 클래스를 생성해야할 시점인지 고민할 것.
• 조각코드를 테스트하고 싶은 경우 메서드로 뺄 것. 그런데 이때 단순히 메서드를 추출하는 개념이 아님. OOP적인 접근으로 객체에 메시지를 보내는 형식이어야함.
• 테스트하기 어려운 부분이 발생하고 이 부분이 연관관계에 의해 연쇄적으로 영향을 줄 경우, 연관관계를 가진 객체들 중 상위 객체로 보내는 것을 염두.

오늘 강의 중 핵심 POINT

개인적으로 감명받은 부분

Getter와 주체적인 객체

• 상태정보를 가진 객체에서 상태 데이터를 바꾸는 것은 상당히 중요하다. 따라서 세터는 금한다. 그러나 게터도 상태데이터를 바꾸는 것을 간접적으로 영향 줄 수 있다.
• 게터를 사용할 경우 타 객체에 나의 상태정보를 그대로 알리고 이를 꺼내서 사용할 수 있게 하는 것이다.
• 이 경우에는 해당 상태에 대해 같은 기능을 하는 중복코드가 다수 발생할 여지가 있다.
• 객체에게 메시지를 보내는 방식으로 개발하여, 주체적인 객체가 될 수 있도록 하여 재사용성을 높임.
• ex) 자동차의 위치 정보를 그대로 노출하지 말고 비교하는 메서드를 생성하여 외부에서 메시지를 보낼 수 있도록한다.
• ex) 자동차가 움직일때 이동가능여부를 객체의 외부에서 판단하게 하지 말 것(은 아니나 지양, 판단의 차이)