책임주도 설계 적용에 대한 간단한 질문 남겨드립니다.

Chanuk님 안녕하세요. 😊좋은 질문 남겨 주셔서 감사합니다.제가 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.답변이 늦어져서 죄송합니다. 현실적으로 DB 스키마가 이미 정해져 있거나, 기존 데이터를 마이그레이션해야 해서 새롭게 설계하기 어려운 경우, 또는 DBA가 별도로 관리하는 환경에서는 책임주도 설계를 적용하기가 쉽지 않을 것 같습니다. 이런 상황에서도 객체지향적인 설계를 현실적으로 적용할 수 있는 방법이 있을까요? (DAO를 중간 계층으로 두면 어느 정도 해결될까요? 아니면 도메인 레이어와 퍼시스턴스 레이어는 분리된 영역이니 크게 상관없을까요? 반대로, 두 레이어가 지나치게 달라지면 오히려 유지보수가 더 어려워지지는 않을까 하는 걱정도 듭니다.)근본적으로 DB 설계와 객체지향 설계는 접근방식과 목적이 다르기 때문에 신규 프로젝트라고 하더라도 두 구조 사이에 차이가 발생할 수 밖에 없습니다.이런 차이를 임피던스 불일치(impedance mismatch) 문제라고 부르는데 DB는 데이터 관점에서 중복을 최소화하는 방향으로 설계해야 하고 객체지향 설계는 강의에서 설명드렸던 것처럼 행동 관점에서 안정적인 구조를 만드는 것을 목적으로 하기 때문입니다. 임피던스 불일치 문제를 해결할 목적으로 만들어진 도구를 ORM(Object Relational Mapping)이라고 부릅니다. Java 진영의 JPA 표준과 Hibernate 구현체가 ORM의 대표적인 예라고 할 수 있습니다. ORM을 사용하면 직접 쿼리를 작성할 필요 없이 어느 정도 DB와 클래스 사이의 차이점을 상쇄시킬 수 있습니다. 물론 ORM은 만능이 아니기 때문에 모든 이슈를 다 해결해 주지는 못합니다. 따라서 실용적인 관점에서 완전한 객체지향 설계를 하려고 하시기 보다는 질문에서 언급하신 것처럼 매핑이 좀 더 수월한 방식으로 객체 구조를 선택하실 필요가 있습니다.ORM을 사용하는 경우에도 해결하기가 수월하지 않은 경우가 있는데 말씀하신 것처럼 레거시 테이블이 정규화가 안된 상태로 장기간 유지된 경우가 여기에 해당합니다. 이렇게 극단적으로 매핑이 어렵지만 객체지향 설계 방식을 선태하시는게 장점이 크다고 판단되시면 테이블과 1:1로 매핑되는 데이터 용 클래스를 만들어서 데이터베이스에서는 이 데이터용 클래스를 이용해서 데이터를 조회하신 후 객체 구조로 다시 매핑하는 방법도 있습니다. 이 방식은 테이블 스키마에 얽매이지 않고 객체지향 설계를 자유롭게 할 수 있다는 장점이 있지만 데이터용 클래스와 객체를 위한 클래스를 함께 유지해야 한다는 단점도 존재합니다. 문제의 복잡도와 유지보수 관점에서의 장단점을 기반으로 적합한 방법을 선택하시면 될 것 같아요. 그리고, 책임주도 설계가 이론적으로는 유지보수에 강하다고 하지만, 실제로는 아직 구조가 다소 복잡하게 느껴져서 오히려 유지보수성을 해칠 수도 있지 않을까 합니다. 이런 복잡함은 설계 패턴에 익숙해지면 자연스럽게 해소될까요? 말씀하신 것처럼 객체지향 설계에 대해 아직 익숙하지 않다보니 복잡하고 어렵게 느끼시는게 아닐까 싶어요. 절차적인 설계에서 객체지향 설계로 이동하는 상황을 패러다임 전환(paradigm shift)라고 부를 정도로 절차적인 사고방식을 객체지향적인 사고방식으로 바꾸는 일은 매우 어렵고 힘든 일이기는 합니다(저도 겪었던 문제구요). 절차적인 방식은 새로운 코드를 작성하거나 코드를 읽을 때는 객체지향보다 쉽게 느껴집니다. 반면에 객체지향은 기존 코드에서 수정할 부분을 찾거나 코드를 수정할 때 절차적인 방식보다 더 쉽게 느껴집니다. 다시 말해서 절차적인 방식은 새로운 코드를 작성할 때는 유리하지만 유지보수의 측면에서는 좋지 않고, 객체지향은 새로운 코드를 작성할 때는 불리하지만 유지보수 측면에서는 유리하다고 볼 수 있습니다. 제가 생각에 객체지향이 복잡하다고 느끼시는 이유는 처음 코드를 작성할 때 들어가는 노력이 절차적인 방식보다 더 크기 때문이 아닐까 싶어요. 유지보수 단계에서의 장점을 이해하기 위해서는 실제로 변경이 일어날 때 코드를 수정해본 경험이 필요하기 때문에 객체지향에 익숙해지시고 요구사항 변경이 빈번하게 발생하는 상황에서 코드를 수정하는 경험이 쌓이면 유지보수 측면에서 객체지향이 유리한 이유를 이해하시게 될거라고 생각합니다.답변이 되었는지 모르겠네요. 🙂행복한 주말 보내세요!

객체지향 설계에서 메서드를 설계할 때 궁금한 점이 있습니다.

선홍님 안녕하세요.좋은 질문 해주셔서 감사합니다. 🙂제가 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.답변이 늦어져서 죄송합니다. 객체의 메서드에는 파라미터로 식별자인 id를 전달하는 것보다는 완전한 객체를 전달하는 것이 좋습니다.객체지향에서 객체가 다른 객체를 알아야 하는 이유는 메시지를 전송하기 위해서입니다.이때 객체가 다른 객체를 영구적으로 알아야 한다면 클래스 내부의 객체 참조로 구현하고, 메서드가 실행되는 시점에만 일시적으로 알기만 하면 된다면 메서드의 파라미터로 전달해 주시면 됩니다.이 관점에서 보면 객체의 파라미터로는 객체를 전달하는게 적합하다고 할 수 있습니다. 강의에서 식별자인 id를 파라미터로 받는 클래스이 있는데 ReservationService와 DAO들이 해당됩니다.이 클래스들은 객체지향에서 말하는 상태와 행위를 함께 포함하는 객체가 아니라 예매를 수행하거나 Reservation을 조회하는 등의 행위 관점에서 만들어진 클래스들입니다.이 클래스들은 실제 객체가 아니고 내부에서 id를 이용해서 책임을 수행할 객체를 찾는 작업이 필요하기 때문에 id를 파라미터로 받는다고 보시면 됩니다. 정리하면 현재 메서드를 구현하고 있는 대상이 상태와 행위를 하나의 단위로 묶어서 특정한 책임을 수행하는 '객체'라면 메서드의 파라미터로 객체를 받도록 구현하시는게 좋습니다.그렇지 않다면 파라미터로 id를 받으셔도 무방합니다. 🙂 답변이 되었는지 모르겠네요.행복한 주말 보내세요!

[오타제보] 6-4. 캡슐화

이상민님 안녕하세요.매의 눈으로 오류를 잡아주셔서 정말 감사드립니다. 🙂말씀하신 것처럼 LSP를 OCP로 수정하는게 맞네요.먼저 pdf 배포본을 수정해서 올려놓고 동영상은 최대한 빨리 보정해서 다시 올리도록 하겠습니다!행복한 주말 보내세요.감사합니다.

리스코프 치환원칙에 대해 질문드립니다!

이석운님 안녕하세요.좋은 질문 남겨주셔서 감사합니다. 리스코프 치환 원칙의 의미에 대해서 잘 알고 계시네요. 🙂강의에서도 이석운님의 의견과 유사하게 설명하고 있습니다.강의의 6분 41초 부분을 보시면 "이렇게 클라이언트 입장에서 서브 타입이 슈퍼 타입을 대체할 수 있도록 설계하는 원칙을 리스코프 치환원칙이라고 부릅니다"라고 설명하고 있어요. 리스코프 치환 원칙의 핵심은 어떤 클래스가 다른 클래스의 서브타입인지 여부를 판단하기 위해서는 두 클래스만 봐서는 안되고, 이 클래스들을 사용하는 클라이언트의 관점에서행동이 호환 가능한지 여부를 살펴봐야한다는 것을 의미합니다. 말씀하신 예에 따르면 Collection 인터페이스의 add 오퍼레이션이 있고, Collection 인터페이스륵 구현한 어떤 클래스 AnyCollection에 add 메서드를 오버라이딩 했다고 해볼게요.이 때 AnyCollection 클래스가 Collection 인터페이스의 서브타입(서브클래스가 아니라)이 되려면 Collection 인터페이스 대신 AnyCollection 인스턴스가 전달되더라도 Collection을 사용하는 기존 코드가 오류 없이 정상적으로 실행되어야만 리스코프 치환 원칙을 만족한다고 말할 수 있습니다. 리스코프 치환 원칙의 의미와 리스코프 치환 원칙을 만족시키는 설계를 만들기 위한 가이드라인은 제가 만든 다른 강의인 "오브젝트 - 설계원칙편(https://inf.run/Hr6j7)"에서 깊이 있게 다루고 있습니다.강의를 통해 알고 계신 내용을 한번 복습해 보시는 것도 좋을것 같아요. 🙂 답변이 되었는지 모르겠네요.감사합니다.

도메인 모델을 잘 정의하기 위해서 어떻게 해야할까요?

Binsk님 안녕하세요.좋은 질문 해주셔서 감사합니다. 🙂제가 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.답변이 늦어져서 죄송합니다. 약간은 의아하게 들릴 수도 있겠지만 도메인 모델을 코드와 별개의 산출물로 보기 보다는 거의 같거나 또는 같은 내용을 서로 다른 형식으로 표현한 것 정도로 바라보는게 유용하다는 말씀을 드리고 싶어요.강의에서 ‘표현적 차이’라는 개념을 설명드렸던 것처럼 코드의 구조를 통해 도메인 모델의 구조를 떠올릴 수 있도록 만드는게 좋습니다.도메인 모델에 대한 이런 관점을 기반으로 하는 방식이 “도메인 주도 설계(Domain-Driven Design)"인데 관심이 있으시다면 한번 학습해 보시기를 권해드립니다. 이 관점을 중심으로 질문에 답변 드리도록 할게요. Q: 도메인 모델은 개발 프로세스 중 어느 시점에 정의하는 것이 좋은지?A: 어느 한 시점에 도메인 모델을 정의한다기 보다는 개발하는 기간 동안(또는 유지보수 기간 동안) 지속적으로 코드와 함께 도메인 모델을 정의하고 발전시켜 나가는게 좋습니다. 초반에는 도메인에 대한 지식이 명확하지 않고 요구사항이 계속 변경될 수 있기 때문에 소프트웨어의 생명주기 전반에 걸쳐 계속해서 도메인에 대한 관점을 변경하고 개선시키게 됩니다. 따라서 도메인 모델을 어느 한 시점에 정의한다기 보다는 소프트웨어가 종료될 때까지 계속해서 도메인 모델을 개선해야 한다고 생각하시면 좋습니다. Q: 도메인 모델을 정의하는 것은 개발자가 주도적으로 이끄는 것인지 아니면 기획자와 같은 다른 팀원들과 함께 만들어 나가는 것인지?A: 도메인 모델은 도메인에 대한 관점이기 때문에 코드뿐만 아니라 요구사항을 분석하고 커뮤니케이션할 때도 영향을 미치게 됩니다. 따라서 도메인 모델을 어떤 직군이 주도적으로 만들어 간다기 보다는 서로 협력하면서 같이 성장시켜 나가는 방식이 좋습니다. 다만 개발 직군 이외의 다른 직군분들이 이런 방식에 대해 가치가 있다고 생각하지 않거나 신경을 쓸 여유가 없으실 수도 있습니다. 이런 경우에는 개발자들이 주도적으로 논의를 이끌어가면서 도메인 모델을 정리하는게 효율적일 수 있습니다. 앞 답변에서 말씀드린 것처럼 이런 논의는 일회성으로 끝나면 안되고 지속적으로 이뤄지는게 좋습니다.Q: 만들어진 도메인 모델을 토대로 설계 및 개발을 진행하다 도메인 모델을 변경해야만 하는 순간이 있는지?A: 앞에서 말씀드린 것처럼 도메인 모델은 고정적인 것이 아니라 도메인에 대해 더 잘 알게 되거나 요구사항이 변경되서 도메인에 변화가 일어난다면 그에 맞게 도메인 모델도 변경되게 됩니다.Q: 좋은 도메인 모델을 만들었는지 평가해볼만한 방법들이 있는지?A: 코드가 도메인 모델을 반영하도록 만들었다고 가정할 때 요구사항이 변경되더라도 전체적인 코드의 구조가 크게 흔들리지 않는다면 좋은 도메인 모델을 만들었다고 볼 수 있습니다. 다시 말해서 도메인의 본질에 대한 관점이 코드 안에 안정적으로 정착됐다는 것을 의미합니다.더 자세한 내용이 궁금하시다면 에릭 에반스가 쓴 “도메인 주도 설계(https://www.yes24.com/product/goods/5312881)"를 한 번 읽어보시기를 추천드립니다.에릭 에반스는 책 전반에 걸쳐서 Binsk님이 궁금해하시는 부분에 대한 답을 체계적으로 정리해 놓았습니다.(이후에 나온 대부분의 도메인 주도 설계 책들에는 이 관점이 누락되어 있는 경우가 많아서 읽기 힘드시더라도 에릭 에반스의 책을 보시는걸 추천드립니다.) 답변이 되었는지 모르겠네요. 🙂행복한 주말 보내세요!

4-2 값 객체 질문

Yojae Jang님 안녕하세요.제가 오늘 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.답변이 늦어져서 죄송합니다. 값 객체는 기본적으로 크기고 작고, 일시적으로 사용한 후에 곧바로 메모리를 해제하는 방식으로 사용됩니다.따라서 일반적인 백엔드 환경에서는 의도적으로 엄청난 양의 값 객체를 생성한 후에 참조를 계속 유지해서 가비지 컬렉터에 넘겨지지 않도록 하지 않는 이상 값 객체로 인해 OOM이 발생할 확률은 거의 없다고 보셔도 무방합니다.JDK에 포함된 많은 클래스들이 값 객체 방식으로 구현되어 있음에도 OOM을 고민하지 않고 쓰는 것처럼 직접 만든 값 객체라고 하더라도 OOM에 대한 걱정없이 편하게 사용하셔도 괜찮습니다. 물론 일반적인 환경이 아니라 메모리가 아주 작은 환경에서 실행해야 하거나 게임의 그래픽 구성 요소처럼 크기가 매우 큰 객체들이 대량으로 생성되는 경우도 있을 수 있습니다. 이 경우에는 값 객체를 매번 생성하는 대신 Flyweight 패턴(https://refactoring.guru/ko/design-patterns/flyweight, https://gameprogrammingpatterns.com/flyweight.html)을 이용해서 여러 객체들 사이에서 동일한 객체를 공유하는 방법을 사용할 수 있습니다.여러 객체 사이에 동일한 객체를 공유하는 대신 한 시점에 하나의 객체에 의해서만 독점적으로 사용된다면 Object Pool 패턴(https://gameprogrammingpatterns.com/object-pool.html)을 사용할 수도 있습니다. 위 방법들은 전체적으로 코드를 복잡하게 만들기 때문에 정말 OOM이 발생할 수 있는 꼭 필요한 상황에서만 사용하시는게 좋을 것 같아요. 🙂 답변이 되었는지 모르겠네요.감사합니다.

getter 사용에 대한 질문입니다.

folklore님 안녕하세요.좋은 질문 해주셔서 감사합니다. 답변을 드리면 한군데서 사용된다고 하더라도 메시지를 전송하는 방식으로 설계를 하시는게 좋습니다.어떤 객체의 getter를 통해 받은 데이터를 이용해서 처리하는 로직이 원래는 그 객체가 수행해야 하는 책임이라면 해당 객체에게 로직을 구현하고 메시지를 전송해서 책임을 수행하도록 만들어야 합니다.이렇게 해야하는 이유는 요구사항 변경에 따라 수정되는 부분을 최소화하고 싶기 때문입니다. 예를 들어 다음과 같이 A가 B의 getter를 이용해서 원래의 A가 해야하는 로직을 구현하고 있다고 해보겠습니다.(사진)이때 B의 데이터가 변경된다면 A와 B 두 개의 클래스를 함께 수정해야 합니다.반면에 로직을 B에 넣고 메시지에 의존하도록 만들었다면 B만 수정하면 되겠죠. 만약 B에서 A를 사용하는 로직을 또 다른 클래스인 C에서도 사용해야 한다고 가정해 보겠습니다.(사진) 이를 위해서는 B의 로직을 A로 옮긴 후에 B와 C 모두 A에게 메시지를 전송하도록 수정해야 합니다.따라서 A, B, C 3개의 클래스를 함께 수정해야 합니다.(사진)반면에 A에 로직이 구현되어 있었다면 간단히 C가 A를 호출하도록 만들기만 하면 되겠죠. 많은 클래스를 수정한다는 이야기는 많은 코드를 테스트해야 한다는 것을 의미합니다.B와 아무런 상관도 없는 C때문에 B도 함께 테스트를 해야하고, QA를 받아야할 수도 있습니다.따라서 만약 객체지향 설계를 하기로 했고 처음부터 메시지를 기반으로 설계하는 것이 가능하다면, 기본 원칙을 따르는 것이 변경으로부터 발생하는 문제를 최소화할 수 있는 가장 좋은 길입니다. 🙂 답변이 되었는지 모르겠네요.감사합니다.

7-3 Reader의 소유권 이동에 관해

hajechoa0104님 안녕하세요.좋은 질문 남겨주셔서 감사합니다. Java의 패키지에 대응되는 C++ 요소는 네임스페이스(namespace)입니다. Java에서는 import를 이용해서 다른 패키지에 대한 의존성을 표현하는데 비해 C++에서는 using namespace를 이용해서 다른 네임스페이스에 대한 의존성을 표현합니다.따라서 Reader를 reader 패키지에서 game 패키지로 이동시킨다는 말을 "reader 네임스페이스에서 game 네임스페이스로 이동"시킨다는 의미로 이해하시면 됩니다. 답변이 되었는지 모르겠네요. 🙂감사합니다!

6-1. 변경과 설계 마지막 추상화 관련 질문 입니다.

이상민님 안녕하세요.좋은 질문 남겨 주셔서 감사합니다. 언제 추상화를 도입할 것인가에 대한 절대적인 법칙이 없다보니 이 질문에 대해 명확하게 몇번이라고 말씀 드리는게 꽤나 조심스러운데요어떤 부분이 지속적으로 변경될 것이라는 확신이 없다면 추상화를 최대한 늦게 도입하는게 좋다는 부분에 대해 동의한다고 말씀하셨으니 조금은 부담없이 제 기준을 말씀드려 볼게요. 🙂 일반적으로 프로그래밍에서 반복적으로 발생하는 문제에 대한 기본적인 가이드는 “3의 규칙(Rule of three)”을 따르는 것입니다.만약 유사한 역할, 책임, 협력이 세번 발생한다면 이를 공통의 디자인 패턴으로 만들 것을 고려합니다.만약 서로 다른 도메인에 적용할 수 있는 코드가 있다면 프레임워크로 만들 것을 고려합니다.만약 세번째로 유사한 코드를 중복시키고 있다면 중복을 제거해서 새로운 추상화를 만듭니다. 하지만 앞에서 말씀드린 것처럼 설계에는 절대적인 법칙이 없기때문에 이 규칙을 맹목적으로 따를 필요는 없고 상황에 따라 유연하게 결정하시면 됩니다. 만약 어떤 코드가 한 두달 사이에 연속적으로 변경되고 있고 사업적으로도 당분간 해당 부분에 대해 다양한 방식을 시도해 보려는 방향성이 잡혀 있다면 두번째 변경이라고 하더라도 추상화를 도입하는게 유리한 경우가 있습니다.어차피 변경이 일어난다면 최대한 빨리 추상화를 도입해서 불필요한 중복 코드가 늘어나는 것을 방지하는게 유리하기 때문입니다.반대로 어떤 부분이 몇년에 한번 발생한다면 세번째라고 하더라도 추상화를 추가하지 않을 때도 있습니다.이 경우에는 세번째로 수정했다고 해서 네번째 변경이 반드시 일어난다고 확신하기가 어렵고 해당 로직을 리팩터링하고 테스트한 후에 재배포하는 우선순위가 그렇게 높지 않은 경우입니다.하지만 자주 변경되지 않지만 여러 코드에서 사용되기 때문에 코드를 자주 읽어야 한다면 추상화를 도입해서 의미를 명확하게 만드는게 좋은 경우도 있습니다. 결론적으로 추상화를 도입할 때의 영향과 비용을 판단하는게 중요합니다.코드를 리팩터링하는게 문제가 아니라 기존 코드를 다시 테스트하고, QA를 통과하는 비용이 상대적으로 클 때가 있기 때문입니다.3의 규칙은 가이드일 뿐이기 때문에 결국 변경이 발생할 때의 영향을 감수할만한 지, 변경이 자주 일어나는지, 의미를 명확하게 하는데 리소스를 쓸 필요가 있는지에 따라 추상화를 도입하는 시점은 달라지게 됩니다.개인적으로 추상화를 추가하는 비용 대비 이익을 확신하기 애매하다면 그 부분은 중요하지 않은 부분일 것이기 때문에 우선 순위가 높은 작업이 있다면 일단 두는 편입니다. 답변이 되었는지 모르겠네요.감사합니다. 😊

객체 지향 설계 원칙에 대한 질문입니다

미르뷰님 안녕하세요.좋은 질문 남겨 주셔서 감사합니다. ‘협력에 필요한 행동을 먼저 결정한다’라는 의미는 시스템의 기능에 먼저 집중하고, 그 기능을 부분적으로 수행할 객체를 나중에 결정한다는 뜻으로 이해하시면 됩니다.강의에서 사용한 영화 예매 시스템을 예로 들면 시스템이 제공해야 하는 기능은 사용자가 원하는 특정한 시간의 상영을 예매하는 것입니다.이 기능을 구현하기 위해서는 알고리즘과 데이터가 필요할 거에요.여기에서 '행동을 먼저 결정한다'는 말은 알고리즘을 먼저 생각하고 분해한다는 뜻으로 생각하시면 됩니다. ‘행동에 적합한 객체를 나중에 선택’한다는 말은 나눠진 알고리즘에 적합한 이름을 붙이는 것을 의미합니다.알고리즘에 이름을 붙여야 하기 때문에 알고리즘이 이미 존재하는 상태에서(행동을 먼저 결정) 이름을 나중에 붙일 수 밖에 없죠(객체를 나중에 선택). 강의에서도 설명드린 것처럼 객체지향은 알고리즘을 특정한 원칙에 따라 객체로 분배하는 방식을 말합니다.이렇게 머릿 속에 떠오르는 알고리즘을 나눠서 적절한 객체에게 할당하는 방식을 책임 주도 설계라고 부르고 기초편 강의에서는 GRASP이라는 패턴 형식으로 알고리즘을 객체에 할당하는 방법을 설명하고 있습니다.따라서 협력을 설계할 때 협력할 대상을 선택하는 도구는 알고리즘입니다.그 알고리즘의 일부가 어떤 이름으로 불리건 상관없습니다.일단 알고리즘을 나눠놓는게 중요합니다. 그 후에는 이렇게 나눠진 행동들에 이름을 붙여야겠죠.객체의 이름으로는 우리가 잘 아는 이름을 붙이는게 좋을겁니다.따라서 이름으로 좋은 대상은 도메인을 구성하는 명사들일거에요.이렇게 이름을 붙이기 좋은 형태로 후보들을 모아놓은 것을 '도메인 모델'이라고 부릅니다.도메인을 이야기하지 않고는 요구사항을 논의할 수 없기 때문에 도메인을 구성하는 명사들이 우리에게 익숙할테니까요.따라서 우리에게 익숙한 도메인 개념을 나눠놓은 행동 조각들의 이름으로 사용하면 나중에 코드의 위치를 기억하기가 쉬울겁니다. 정리하면 '협력에 필요한 행동을 먼저 결정하고 행동에 적합한 객체를 나중에 선택하라’라는 말은 ‘알고리즘을 객체지향 원칙에 따라 나눈 후에 나눠진 각각의 알고리즘에 적합한 이름을 나중에 붙여라’라는 의미로 이해하시면 됩니다.강의에 나오는 아래 장표가 이 과정을 설명한 것이라고 보시면 됩니다.(사진) 이 내용을 이해하시고 다시 한번 강의를 복습하시면 객체지향 설계 방법이 이해가 되실거에요. 😊미리 책임과 협력을 결정하지 않고 알고리즘을 코드로 작성한 후에 객체로 분배할 수도 있는데 이 방법은 “설계원칙편”에서 다루고 있습니다. 답변이 되었는지 모르겠네요.감사합니다.