Docs: Add TheEssenseOfObjectOrientation Chapter 00~04

[fkdl0048]

오랜만에 다시 돌아왔습니다..!

++ 논의사항을 하나로 변경된 줄 몰랐습니다.. 본문에 적어두겠습니다.

느낀점

협력의 중요성이 등장하면서 계속해서 머릿속으로 코드가 동적인 흐름으로 흐르는 것을 상상하게 되는 것 같습니다. 동적인 코드가 동작하려면 정적인 코드가 필요하듯이, 객체지향을 공부하면 할수록 정적인 구조도 계속해서 고민하게 되는 것 같습니다. 어떻게 보면 구조의 프레임 같은 역할이라고 생각이 되기도 하면서 좀 더 멀리서 보면 언어가 그 프레임에 해당되는 것 같기도 합니다. 이 챕터에선 또 다르게 행동과 싱태를 이런 시점으로 바라보게 되는 것 같은 느낌이 드네요.

논의사항

• 책에서 직접적으로 언급하지 않지만, 계속해서 동일한 행동(인터페이스)에 대해서 말한다는 느낌을 받았습니다. 행동으로 타입을 바라볼 수 있다면 두 가지 설계 방법에 대해서 좀 더 이야기 해보면 좋을 것 같습니다.
  • 코드을 작성하다 보니 동일한 행동을 가진 구조라 인터페이스로 묶어서 관리(추상클래스든, 인터페이스든)
  • 처음부터 도메인에 맞는 구조를 설계하여 행동으로 묶어서 코드를 작성하기
  • 그 외

[github-actions]

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

[yeslee-v]

프로젝트에 대해 설계를 충분히 했다고 하더라도 언제든지 변경될 수 있기 때문에, 말씀주신 두 가지 방법을 혼합하여 사용하는 방향으로 생각해보았습니다. 초기 단계에 반복되는 행동이 있다면 메서드 등으로 분리할 수 있겠지만, 중간에 (혹은 나중에) 추가될 경우에는 전자의 방식대로요.

[jongfeel]

저는 조금 다른 시각으로
인터페이스를 설계할 줄 안다는 건 다음과 같은 걸 생각하고 있다고 볼 수 있다고 봅니다.

• 인터페이스는 메소드를 정의해야 하므로 행동에 대해 먼저 생각하게 하는 효과가 있다.
• 인터페이스는 구현된 후에 객체가 생성이 되면 타입으로 바라보고 행동을 요청할 수 있으므로 객체가 달라도 역할은 같게 만들 수 있다는 생각을 가지게 한다.

그러면 객체는 다르게 생성하더라도 결국 같은 역할을 하는 타입을 바라볼 수 있다면
조금 더 객체지향적인 방법으로 설계하고 있다고 볼 수 있습니다.

물론 코드를 작성하다가 같은 역할을 책임지게 하면 좋겠다는 생각이 들면 인터페이스로 묶을 수도 있기도 합니다. 초기 설계 이후로 변경에 대한 리뷰만 잘 해준다면 크게 문제는 없다고 봅니다.

[hemil0102]

전략 패턴을 적용하면 같은 행동을 하는 타입으로 구현된 객체를 동적인 상황에서 교체할 수 있도록 구현할 수 있다는 이점도 있는 것 같습니다.

[TaeHyoungKwon]

• 코드을 작성하다 보니 동일한 행동을 가진 구조라 인터페이스로 묶어서 관리(추상클래스든, 인터페이스든)
• 처음부터 도메인에 맞는 구조를 설계하여 행동으로 묶어서 코드를 작성하기

---

저는 상황에 따라서, 적절히 선택해서 사용하는 편 인데, 매우 크고 앞으로 유지보수를 빡세게 해야하는(변경이 잦은) 그런 프로젝트라면, 처음부터 도메인에 맞는 구조를 설계 하는 방향으로 선택하고, 그외의 경우는 코드를 작성하는 과정, 과정마다 설계를 진행 하고 있습니다

[dhlee3994]

책에서 직접적으로 언급하지 않지만, 계속해서 동일한 행동(인터페이스)에 대해서 말한다는 느낌을 받았습니다. 행동으로 타입을 바라볼 수 있다면 두 가지 설계 방법에 대해서 좀 더 이야기 해보면 좋을 것 같습니다.

• 코드을 작성하다 보니 동일한 행동을 가진 구조라 인터페이스로 묶어서 관리(추상클래스든, 인터페이스든)
• 처음부터 도메인에 맞는 구조를 설계하여 행동으로 묶어서 코드를 작성하기
• 그 외

먼저 행동으로 껍데기를 만들고, 만들다보면 처음에 발견하지 못했거나 요구 사항이 추가되었거나 해서 생긴 공통점들을 묶는 식으로 하는 것 같습니다.
애초에 처음부터 행동을 생각하지 않고 만들었던 적은 없는 것 같습니다.

[wooyaggo86]

상황에 따라 다르지만, 기존 소프트웨어를 다룰 때는 이미 정해진 규칙에 따라 작업해야 하는 경우가 많습니다. 이 부분은 상태를 먼저 고려한다고 생각할 수 있을 것 같습니다. 임베디드 소프트웨어의 경우에는 상태에 대한 제약이 더 크기 때문에 상태를 좀더 우선순위에 놓고 설계할 수 있을 것 같습니다.

하지만 일반적으로는 어떤 기능을 만들지 인터페이스를 먼저 생각하고, 그에 맞춰 작업하는 것이 더 자연스럽다고 생각합니다.

[wooyaggo86]

이 부분은 항상 +1이지만, interface로 인해서, IDE 적절한 도움이 없으면 오히려 시간을 잡아먹게되서.. trade-off 가 있는 것 같습니다.