객체지향 사실과 오해 5장 ~ 부록A

[hemil0102]

객체지향의 사실과 오해 5 ~ 7장 + 부록. A

역하, 책임, 협력 관점에서 본 객체지향

소프트웨어는 사용자에게 원하는 기능을 제공해줘야 한다.

소프트웨어 출신 사업가가 많다고 했던가? 책을 통해 살펴보니 소프트웨어 자체가 사용자 중심으로 사고를 형성하는 것을 알 수 있다.
따라서 타인에게 관심을 갖고 문제를 해결해주는 관점을 기르는 것이 중요하다 할 수 있겠다.

지속 가능성, 도메인 모델

우리는 늘 변화하는 세상에 살고 있다. 한 번 작성한 코드도 계속 변화를 하고, 또 작성하면서 프로그램은 완성되어 간다.
같은 일을 여러번 갈아 엎고 처음부터 다시 해야하는 것은 시간 적으로도 낭비이며, 에너지도 불필요하게 소모된다.
도메인 모델은 어떤 변화에도 사용성을 확보하는 틀을 제공해주는데,
그럼 도메인 모델을 어떻게 만들어야 시간이 지나고 모든 것이 변화해도 사용성을 확보하는가?
도메인 모델링의 설명이 구조를 수집하고 표현하기 위한 기법이므로,
책에서 말한 것 처럼 어떤 변하지 않는 것을 잘 파악해내는 능력이 중요하다.
여기서 변하지 않는 다는 것은 추상적인 단위에서 개념적인 변치 않음을 말한다.
예를 들어서 이동수단은 이동의 필요한 무언가를 제공해주므로, 그 내부에는 여러 방식으로 이동을 구현하겠지만,
이동수단 그 자체의 의미는 크게 변하지 않는다. 이런 변치 않는 개념으로 도메인을 설계하는 것이 바람직하다 생각한다.
그리고 우리는 일상생활에서 수많은 것들과 상호작용을 하는데 여기에 멘탈모델 설계도 중요해보인다.

메시지, 객체의 책임을 결정하고 협력을 이끌어낸다.

어떤 요청에 대해 행위를 수행하기 위해서 책임은 메시지를 알아들어야 그것을 수행할 수 있으므로 당연한 말인 것 같다.
메시지는 추상적이지만 명확해야 올바른 행위를 이끌어낼 수 있다.
따라서, 사람과 사람 사이의 커뮤니케이션에서도 원하는 바를 명확하게 제시해서 소통하면 좋겠다.
올바른 메시지를 만들어 내는 것이 올바른 책임을 만들어내고 더 나아가 올바른 협력으로 공동의 목표를 잘 이룰 수 있겠다.

구현보다 인터페이스 설계에 집중하라.

사실 일상 생활에서도 적용되는 말이다. 어떤 사람과 사람의 교류에서 그 사람과 대화를 할 때 그 사람의 모든 것을 파악하기란 그 사람이 되지 않고서는 불가능하다. 하지만 우리는 사람과 교류할 때 어떤 이야기가 통하고 어떤 감정이 전달 되었을 때 어떤 반응이 오는지를 관찰하고 이에 따라서 인터페이스를 파악하여 메시지를 전달하기도 한다.

따라서 모든 것을 파악하고 구현 관점으로 간다는 것에는 엄청난 노력이 들어가는데,
적절한 메시지를 보내고 반응을 받고 또 메시지를 보내면서 인터페이스를 잘 설계한다면,
모든 것을 다 알지 못해도 우리는 협력을 할 수 있을 것 같다.

역할, 책임, 협력 나누기 연습(클릭하면 커짐)

논의할 부분

사용자의 목표와 원하는 것을 잘 확인하려면 어떻게 해야할까요? 사용자의 니즈를 잘 처리하는 인터페이스 설계 방법?

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[jongfeel]

👍
중간에 질문들을 넣어 주셔서 답변을 해 봤습니다.

[jongfeel]

자신이 구조를 만들면 그렇지 않지만
다른 팀원이 만든 구조라면 공유와 리뷰가 필요하고
다른 업체가 만든 구조라면 더 많은 회의와 협력이 필요할 수 있습니다.
이런 협의 과정을 거치면 어떻게든 이해할 수 있는 방향으로 갈 수는 있을 거라고 봅니다.

[yeslee-v]

결국 이 상황에서 조차도 '협력'은 필요하다고 생각합니다.

[jongfeel]

책에 설명되어 있는 내용이긴 한데
인터페이스에 열려 있고, 캡슐화를 통해 내부를 숨기는 형태로
객체들 끼리의 느슨한 결합이 이루어진다면
협력 구조가 크게 요동치지 않는다 라고 합니다.
실제 맞기도 하고요.

부록에도 그런 안정적인 구조를 위해
패키지나 모듈화를 하는 것도 좋은 방법이라고 하고 있죠.

[jongfeel]

예측할 수 없다라는 의미는
아직 어떻게 변경이 될지 결정이 되지 않았다의 의미가 더 강하다고 볼 수 있습니다.

로그인의 예제를 들면
어떤 서비스를 사용하기 위해 id, password를 체크하는 로그인 기능을 만들었지만
경험이 많은 사람이라면 소셜 로그인 기능이 나중에 추가될 걸 예상할 수는 있을 겁니다.
하지만 소셜 로그인 기능을 추가한다라는 결정이 아직 이루어지지 않은 상황이므로
예측할 수 없다라고 표현한 것이죠.

[yeslee-v]

기획자의 입장에서는 (개발자가) 전혀 생각하지 못한 기능들을 요구할 수 있기 때문이지 않을까?라고 생각해보았네요.
일을 하다보면, 회사의 방향성과 굉장히 다르다고 생각되는 서비스가 뜬금없이 들어갈 수도 있고요?

[jongfeel]

으흠
이건 소프트웨어 공학에서 분석/설계 쪽의 이슈이기도 하고
더 큰 그림에서 보자면 프로젝트 관리 쪽 얘기이기도 합니다.

소프트웨어 공학의 교조적인 방법으로 인터뷰, 설문조사, 프로토타이핑 등이 있는데
요구사항 분석-정제-명세-고객 확인을 통해 만들어내는 방법론입니다.

애자일 얘기를 끼얹으면, 애자일 선언문 4개 중 하나인 "계약 협상을 따르기 보다는 고객과의 협력을" 원칙을 잘 지켜보면 좋을 수 있습니다. 애자일은 고객의 요구사항에 대한 변경을 계속 수용하는 쪽으로 하는 방법이니까요.

도메인 모델쪽 얘기를 해보면, 도메인 전문가와 함께 지속적인 멘탈 모델에 대한 공유 및 확인 작업을 통해 달성할 수도 있죠. 크게 보면 또 애자일 얘기와 다르진 않긴 합니다.

[yeslee-v]

결국 끊임없이 대화해야 한다(협력)고 생각합니다.

[jongfeel]

Pull request의 본문 논의 주제는 코멘트로 추가합니다.

지속적인 도메인 모델의 공유 및 수정, 확인 작업을 통해 설계해 보면 정답에 가까울 것 같습니다.
책에서는 메시지를 먼저 생각하고 데이터를 나중에 생각하라고 했는데
순서는 중요하지 않은 것 같고

1. 메시지 - 인터페이스
2. 데이터 - 필요한 정보
   에 대한 정의가 잘 이루어지고
3. 출력의 방법 - 대부분 컴퓨터 시스템의 GUI를 통해 원하는 결과 표현 혹은 그렇지 않은 데이터의 경우 클라우드 서비스에 저장
   까지 잘 정의해준다면 좋을 것 같습니다.

[yeslee-v]

사용자의 목표와 원하는 것을 잘 확인하려면 어떻게 해야할까요? 사용자의 니즈를 잘 처리하는 인터페이스 설계 방법?

잘 확인하는 것은 사용자가 말하는 바를 제대로 이해하고, 어떠한 단어를 사용했을 때 서로가 동일한 의미로 언급하는 것이 맞는지가 중요하다고 생각합니다.
인터페이스 설계 방법은 이해한 바를 토대로 작성하면 되지 않을까 싶은데 이 부분은 잘 모르겠네요.

[dhlee3994]

사용자의 목표와 원하는 것을 잘 확인하려면 어떻게 해야할까요? 사용자의 니즈를 잘 처리하는 인터페이스 설계 방법?

꾸준한 확인, 변경이 답인 것 같습니다 ㅠㅠ