객체지향 프로그래밍과 설계(14)

POCU의 개체지향 프로그래밍 및 설계 강의를 듣고 정리한 내용입니다.

단일 책임 정신

Only do one thing One reason to change

클래스 하나에서 너무 많은 일을 하지 마라

• ‘하나’의 개념이 매우 주관적
• 의의
  • 이 코드를 보는 대부분의 사람이 이해할 수 있는 크기로 클래스를 만들자!
• 물론 주관적이므로 팀과 동료에 따라 달라짐

얻어갈 교훈

• 각 클래스의 책임을 분명하게 결정하자
• 각 함수의 책임을 분명하게 정의하자고 말했던 것과 마찬가지
• 특정 오류 상황이 있을 때 대응이 쉽다
  • 그 오류를 검사하고 처리해야 하는 곳이 명확함
  • 앞에서 말했던 입력값 검증이 좋은 예

개방-폐쇄 정신

Open for extension, Closed for modification

• 클래스 내부 수정 없이 동작을 확장할 수 있어야 한다.
• 안 바꾸면 좋은 점
  • 이 클래스를 사용하는 코드가 망가지진 않음
• 절대적인 것 아님. 내부 수정이 필요하다면 하면 된다.
  • 기존 코드를 고쳐서 breaking change를 만드는 게 유지보수가 용이
  • breaking change : 호환성 문제가 발생할 수 있는 수정사항

리스코프 치환 정신

1. 부모 클래스의 객체를 사용하는 코드 A 가 있음
2. 나중에 자식 클래스의 객체를 거기에 대신 사용함(치환)
3. 이 때 A가 아무 문제없이 동작해야 한다.

• 즉, 부모가 할 수 있었던 일은 자식도 다 할 수 있어야 함.
• 안 지키면 호출자 코드가 어느 순간 작동하지 않을 수 있음
  • 자료형만 보면 실제 객체가 뭔지 모른다.
• 100% 이렇게 될 수는 없다.
  • 모든 자식을 알기 전에 부모를 추상화하기 어려움
  • 자식을 추가할 때 부모의 동작을 바꾸는 일이 꽤 있음

인터페이스 분리 정신

큰 인터페이스가 몇 개 있는 것보다 작은 인터페이스가 많이 있는 게 좋다.

• 이것도 마찬가지. 극단으로 가지 말고 프로젝트 참가자들이 가장 잘 이해할 수 있는 방향으로 가야 한다.

의존 역전 정신

• 객체끼리 통신할 때 구체적인 것 말고 추상적인 것에 의존하라.
• 이전 인터페이스 중 가이드 ‘인터페이스를 어디에 사용해야 하는가’에 따르자.

소프트웨어 품질

• 소프트웨어 품질의 시작은 개발자의 실수를 줄이는 환경 구축
• 모두가 이해하기 쉬운 코드를 작성할 것
• 언제부터 디커플링을 고려해야 하는가?
  • 협업 환경에서 잦은 변경으로 서로 일 못하는 상황이 생길 때
  • SOLID 정신이 그때부터 도움이 될 수 있음

정리 : 필요하면 사용한다!!!

• 필요 없는 걸 굳이 하려는 사람은 민페
• 성능이 불필요한 곳에서 모든 걸 기계어로 작성하는 사람도 민폐
• 뭔가 새롭고 대단해 보이는 것은 필요할 때만 사용해라…!!! 명심 !

Reference

POCU 강의