10일차_지난 과제 돌아보며 객체지향 이해하기, 의존성과 설계의 관계 맛보기

지난 과제를 돌아보며 생각한 것 (with 객체지향)

(1) mvc의 필요성

• 지난 과제에서 mvc를 적용하려 한 사람들이라면 누구나 공감할 만한 부분이 있다. 바로, 사용자로부터 3자리 숫자를 입력하는 부분을 view에서 하기 까다롭단 것이다. 사실 이번 과제에선 mvc를 쓰지 않고 3자리 숫자 입력을 특정 모델이 책임지게 했으면 좀 더 객체지향적이며 자연스레 메서드도 작은 단위로 추출될 수 있었을 거 같다.

• 무슨 말이냐면, "숫자를 입력해주세요" 부분은 Player의 행위를 위한 객체에 속하면 더 좋았을 거 같다. 대신 이렇게 되면 mvc 개념을 넣긴 힘들어질것이다. 하지만, mvc란게 애초에 사람들이 구현을 하다 어떤 임계점에서 특정 패턴을 정리한 것뿐이지 무조건 써야 하는 것이 아니기에, 돌이켜보면 1주차 과제는 그 임계점을 넘지 않는 과제가 아니였을까 싶다.

(2) 객체지향 vs 절차지향(함수지향)

• 객치지향과 절차지향은 반댓말이 아니다. 그 이유는 절차지향을 하다가 발전된 게 객체지향이기 때문이다. 따라서 객체지향적인 코드가 절차지향적인 특성을 아예 안 갖는 건 아니다. 객체지향 역시 절차적으로 실행된다. 그렇다면 뭐가 다른 걸까? 이 실행의 목적이 다르다. 절차지향은 오직 순차적으로 실행되는 데에 목적을 두고 있고, 객체지향은 객체 간의 관계가 실행되는 데에 목적을 두고 있다.

• 좀 더 직관적으로 말해보자면, 절차지향은 데이터를 중심으로 함수를 구현하는 거고 객체지향은 기능을 중심으로 함수를 구현한다. 그렇다면 어떻게 해야 데이터 중심으로 함수를 구현하지 않고 기능 중심으로 함수를 구현할 수 있을까? 바로 데이터 위주의 사고가 아닌 행동 위주의 사고를 하는 것이다.

• 데이터 위주의 사고는 예를 들면 “자동차는 바퀴, 프레임, 엔진, 방향, 속도, 값들을 갖고 있어야겠다”라고 생각한 후 Car { private List<Wheel> wheels; private Speed speed; } 와 같은 식으로 코드를 짜는 것이다.

• 반면, 행동 위주의 사고는 “자동차는 달릴 수 있어야 하고, 속도 조절할 수 있어야 하고, 방향도 바뀔 수 있어야겠다.”라고 생각한 후 Car { public void drive(); public void accelerate(Speed speed) } 와 같은 식으로 코드를 짜는 것이다.

• 사실 전자의 결과물은 struct를 만든 거고 후자의 결과물이 class를 만든 것이다. 행동 위주의 사고를 하는 게 객체지향적인 코드를 짜게 될 확률이 올라간다.

참고

절차지향(Procedural Programming), 객체지향(Object Oriented Programming) 장단점 및 차이점

절차지향(Procedural Programming) 절차지향(Procedural Programming)이란, 물이 위에서 아래로 흐르는 것처럼 순차적인 처리가 중요시 되며 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법입니다. 절차지향(Procedural Programming) 특징 대표적인 예로는 C언어가 있습니다. 컴퓨터의 작업 처리 방식과 유사하기 때문에 객체지향 언어를 사용하는 것에 비해 더 빨리 처리 되어 시간적으로 유리합니다. 절차지향(Procedural Programming) 장단점 장점 - 컴퓨터의 처리구조와 유사해 실행속도가 빠릅니다. 단점 - 유지보수가 어렵습니다. - 실행 순서가 정해져 있으므로 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵습니다. - 디버깅이 어렵습니..

https://usefultoknow.tistory.com/entry/절차지향Procedural-Programming-객체지향Object-Oriented-Programming-장단점-및-차이점

(3) 연관관계 vs 의존관계

• 지난 과제에서 모델 간 의존성을 떨어트리고 싶었는데 사실 모델끼리 그 어떤 관계도 맺지 않는 건 어려운 일이었다. 특정 모델이 다른 모델을 attribute로 가져야 할 수도 있고, 다른 모델을 사용해야 할 수도 있다. 그렇다면 어디까지가 의존성을 높이지 않는 선에서 허용되는 건지 궁금해졌었다.

• 이에 대해 어느 정도 해답을 준 게 연관관계와 의존관계 라는 키워드였다. 연관관계는 우리가 알고 있는 has a 관계다. Car { private Speed speed; }와 같이 Car가 Speed를 변수로 갖는 Association 관계이다. 의존관계를 사실 잘 몰랐는데 이는 Car { public void accelerate(Speed speed) { return new Speed(); }와 같이 Car의 매개변수 혹은 반환타입으로 Speed를 사용하는 것이다. 이 경우 Car가 Speed에 의존적이라고 한다.

• 그렇다면 둘 중 모델 간 의존성을 높이는 것은 무엇일까? 이건 아래 강연를 보고 더 고민해보았다. 결론은 설계에 따라 다르다. 의존성이란건 특정 클래스가 변경될 때 다른 클래스도 변경될 가능성이 있단 걸 의미하는데, 의존성이 있어도 설계를 잘하면 변경으로 인한 파장 효과를 없앨 수도 있다. 이를 위한 기법으로 강의에선 event handler를 이야기 하는데 얼핏 저게 ddd에서 나오는 용어란 걸 알 수 있었다.

• 사실 나는 아직 객체지향도 완벽히 이해하지 못했는데 ddd까지 욕심 부리는 건 무리라고 판단했다. ddd가 정확히 뭔지도 잘 모르고 말이다.. 따라서 이번 2주차 과제에선 어쩌면 프리코스 기간 동안엔 의존성 결합에 대해 크게 집착하지 않기로 했다.

참고

[OOP] 클래스의 의존성 - 우아한 객체 지향 참고하여 수정

디자인 패턴을 공부하기 위해서는 클래스와의 관계를 파악하는 것이 중요하다. 그리고 클래스와의 관계를 파악할 때는 개인적으로 UML을 그려보는 것이 가장 좋다고 생각한다. 그리고 UML을 공부하다보면 항상 relationship의 개념이 모호할 때가 많다. 오늘은 그 모호한 개념들을 좀 더 확실하게 정리해보고자 UML의 대표적인 relationship에 대해 포스팅해보려 한다. 우아한 객체 지향 중 클래스 의존성 종류에 대한 조영호 님의 설명 👍 우아한 객체 지향 영상에서 조영호님이 쉽고 명확하게 설명해주셔서 감명받고 기존에 클래스간의 관계에 대해 정리해놓은 이 글을 수정하기로 했다. Association (A "has a" B) : 연관관계 보통 Association 관계에서 B는 A의 field에서 a..

https://jihyewoo.tistory.com/62

우아한 객체지향 후기 및 정리

https://www.youtube.com/watch?v=dJ5C4qRqAgA 우아한 형제들에서 진행한 우아한 객체지향 세미나에 가고 싶었는데 아쉽게도 가지 못했다. 발표해주시는분이 객체지향의 사실과 오해를 쓰신 조영호분이라서 더 가보고 싶었는데 아쉽다. 책에 내용이 좋아서 동영상으로라도 보고 싶었는데 유튜브에 동영상이 올라와서 보고 정리해본다. 개념 - 설계는 코드에 어디에 놓을건지를 정하는 것. - 의존성 문제의 핵심은 코드 변경시 영향을 주는지이다. - 의존성 문제는 디커플링이 되어야 한다. 관계설명 연관관계 (Association) A 클래스에 B클래스로 갈수 있는 영구적인 방법이 있는 경우 A → B class A { private B b; } 의존관계 (Dependency) A ---> B (..

https://wedul.site/635

[강연] ‘의존성을 이용해 설계 진화시키기’를 듣고

• 아래 강연을 듣고 정리하며 든 생각들은 (🐱)으로 표시했습니다.
[우아한테크세미나] 190620 우아한객체지향 by 우아한형제들 개발실장 조영호님
💻 우아한형제들의 기술조직 이야기를 전하는 우아한Tech 유튜브입니다.💻 발표 자료 공유 링크 https://bit.ly/2LtQvsl 객체지향에서 제시하는 다양한 설계 원칙과 개념들을 실제 프로젝트에 적용하기 위해 고려해야 하는 가장 중요한 요소는 변경과 의존성입니다. 이번 세미나에서는 의존성이라는 압력에 따라 설계를 진화시키는 과정을 통해 효과적이고 실용적인 객체지향 설계가 어떤 모습을 띄는지를 살펴봅니다. 우아한테크세미나는 구성원분들이 관심을 갖고 있는 기술적 주제에 대해 내외부 강사분을 통해 살펴보는 시간으로 꾸며지며, 구성원들뿐만 아니라 같은 고민과 관심을 가진 외부 개발자분들도 초대하여 진행됩니다. #우아한Tech #우아한개발자 #공유문화 #우아한테크세미나

https://www.youtube.com/watch?v=dJ5C4qRqAgA

• 설계 : 코드를 어떻게 배치할 것인지에 대한 의사 결정
• 같이 변경되는 코드를 같이 넣고, 같이 변경되지 않으면 따로 넣자

• 의존성 : A가 B에 의존(A→B)한단건 B가 변경될 때 A도 같이 변경될 수 있음(가능성)을 의미함
• 변경은 클래스 이름, 메서드 이름, 구현 등 뭐든 될 수 있음
• 의존성이 있다고 해서 무조건 변경되는 건 아님. 설계 잘하면 B가 변경되더라도 A에 영향 주지 않을 수도 있음

• 클래스 의존성
• 연관관계 : A에서 B로 이동할 수 있음 (영구적 경로)
• 의존관계 : A와 B가 협력하는 시점에 관계맺고 헤어짐 (🐱 의존성 아님ㅎ)
• 상속관계 : B의 구현만 바뀌어도 영향 받음
• 실체화관계 : B의 인터페이스 시그니처 바뀌었을 때만 영향 받음

• 패키지 의존성
• 패키지에 포함된 클래스 사이의 의존성
• 클래스 열었을 때 import에 다른 패키지 이름 있으면 의존성 있는 거임

• 의존성 관리 규칙 : 설계 시 가이드
• 가급적이면 양방향 의존성을 피하라
• 양방향 의존성을 가질 때 사실 그 두 클래스는 하나의 클래스여도 무방한 데 억지로 찢은 게 아닐지 의심해보기
• 양방향은 동시성 관리하기 빡셈
• 다중성이 적은 방향을 선택하라
• 일대다 말고 다대일로 표현하기
• 일대다의 경우 List, Collection, Set 같은 걸 변수로 가져야 할텐데 성능 이슈 관리나 객체들 관계 유지가 빡셈
• 되도록이면 의존성이 필요없다면 제거하라
• 패키지 사이의 의존성 사이클을 제거하라
• 패키지 사이엔 양방향 의존성이 있으면 안됨

• 예제 : 여러 객체에 분산된 validation logic 분리
• validation 로직과 주문 처리 로직은 변경 시점이 다를 거임
• 따라서 Order 객체에서 validation 로직은 떼어냈음
• 때로는 절차지향이 객체지향보다 좋다. 객체 안에 validation 로직 다 넣을 필요 없다.
• 상태 조금 체크하는 거면 객체 안에 넣는 게 나은데, 이를 체크하기 위해 여러 객체를 사용해야 한다면 떼어내는 게 나을 수 있다.
• 이가 객체의 결합도는 높이지만 응집도는 낮출 수 있다.

• 예제 : 도메인 로직의 순차적 실행으로 인한 도메인 간 높은 결합도 이슈 해결
• 첫 번째 방법 : 절차지향적으로 로직 모으기 → 비즈니스 플로우 한 눈에 볼 수 있음
• 이때 사이클 생기면 → 인터페이스 사용해서 의존성 역전시키기
• 두 번째 방법 : 도메인 이벤트 퍼블리싱

Today in 프리코스