오브젝트 독서회 2회차 - 2장 객체지향 프로그래밍

🧵 Slog
1

오브젝트 독서회 2회차

Intro

오브젝트 독서회 2회차를 진행했습니다.
독서회는 계속해서 새로운 환경에서 새로운 영감을 얻기 위해서 되도록 장소를 겹치지 않고 바꿔가면서 진행하고 싶었습니다.
이번에도 스페이스 클라우드라는 서비스를 통해 세상의 모든 스터디에서 진행했습니다.
2번 방을 사용했으며, 방 자체는 지난 스터디룸보다 깔끔했습니다.
하지만 지난 스터디룸은 원두 아메리카노 무제한 이용이 가능했고, 방에 에어컨이 있었는데 이번 장소는 에어컨이 없었습니다.

원래는 지난 주에 2회차 독서회를 하기로 했지만, 맴버들의 개인사유로 1주 뒤로 미루게 되었습니다.
스터디룸에서 다행히 환불을 하지 않는다는 조건으로 1주 뒤로 미뤄주어 비용손해 없이 스터디룸을 이용했습니다.
@아메리카노 님께서 휴가로 불참하셨고, 독서회 내용을 댓글로 정리해주신다고 하셨습니다.
@eundini93 님께서 음료를 제공해주셨습니다. 감사합니다.

이번에는 모두 목표한 2장을 사전에 읽어오고 19시 20분까지 정리 한 뒤 개인 독후감을 발표하고 이어서 관련된 이야기를 진행했습니다.
지난 독서회에서 시간을 제한시간 없이 자유롭게 이용해도 되겠다는 피드백이 있었고 4명이서 진행했기 때문에 편하게 2장에 대한 나눔을 진행했습니다.

독후감 문장

38P

앞으로의 설명을 위해 '영화’와 '상영’이라는 용어를 구분할 필요가 있을 것 같다.

@muki4742

40P

할인을 적용하기 위해서는 할인 정책을 함께 조합해서 사용한다.

@Vincent

이번 장의 목표는 지금까지 설명한 요구사항을 객체지향 프로그래밍 언어를 이용해 구현하는 것이다.

@freebear

41P

진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다.

@Vincent @freebear @eundini93

어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것이다.

@Vincent @freebear @eundini93

객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다.

@Vincent @freebear @eundini93

문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 부른다.

@Vincent

42P

일반적으로 클래스의 이름은 대응되는 도메인 개념의 이름과 동일하거나 적어도 유사하게 지어야 한다.

@muki4742

도메인의 개념과 관계를 반영하도록 프로그램을 구조화해야 하기 때문에 그림 2.4와 같이 클래스의 구조는 도메인의 구조와 유사한 형태를 띠어야 한다.

@eundini93

43P

여기서 주목할 점은 인스턴스 변수의 가시성은 private이고 메서드의 가시성은 public이라는 것이다.

@eundini93

클래스를 구현하거나 다른 개발자에 의해 개발된 클래스를 사용할 때 가장 중요한 것은 클래스의 경계를 구분 짓는 것이다.

@Vincent @muki4742

클래스는 내부와 외부로 구분되며 훌륭한 클래스를 설계하기 위한 핵심은 어떤 부분을 외부에 공개하고 어떤 부분을 감출지를 결정하는 것이다.

@freebear

경계의 명확성이 객체의 자율성을 보장하기 때문이다.

@Vincent @muki4742

44P

객체가 상태와 행동을 함께 가지는 복합적인 존재라는 것이다.

@Vincent

객체가 스스로 판단하고 행동하는 자율적인 존재라는 것이다.

@Vincent @muki4742

객체지향의 핵심은 스스로 상태를 관리하고, 판단하고, 행동하는 자율적인 객체들의 공동체를 구성하는 것이다. 객체가 자율적인 존재로 우뚝 서기 위해서는 외부의 간섭을 최소화해야 한다. 외부에서는 객체가 어떤 상태에 놓여있는지, 어떤 생각을 하고 있는지 알아서는 안 되며, 결정에 직접적으로 개입하려고 해서도 안 된다. 객체에게 원하는 것을 요청하고는 객체가 스스로 최선의 방법을 결정할 수 있을 것이라는 점을 믿고 기다려야 한다.

@Vincent

뒤에서 살펴보겠지만 인터페이스와 구현의 분리(separation of interface and implementation) 원칙은 훌륭한 객체지향 프로그램을 만들기 위해 따라야 하는 핵심 원칙이다.

@freebear

45P

프로그래머의 역할을 클래스 작성자와 클라이언트 프로그래머로 구분하는 것이 유용하다.

@muki4742

객체의 외부와 내부를 구분하면 클라이언트 프로그래머가 알아야 할 지식의 양이 줄어들고 클래스 작성자가 자유롭게 구현을 변경할 수 있는 폭이 넓어진다.

@muki4742

설계가 필요한 이유는 변경을 관리하기 위해서라는 것을 기억하라.

@Vincent

47P

그 개념이 비록 하나의 인스턴스 변수만 포함하더라도 개념을 명시적으로 표현하는 것은 전체적인 설계의 명확성과 유연성을 높이는 첫걸음이다.

@Vincent

48P

객체지향 프로그램을 작성할 때는 먼저 협력의 관점에서 어떤 객체가 필요한지를 결정하고, 객체들의 공통 상태와 행위를 구현하기 위해 클래스를 작성한다.

@Vincent

49P

객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 메시지를 전송(send a message) 하는 것뿐이다. 다른 객체에게 요청이 도착할 때 해당 객체가 메시지를 수신(receive a message) 했다고 이야기한다. 메시지를 수신한 객체는 스스로의 결정에 따라 자율적으로 메시지를 처리할 방법을 결정한다. 이처럼 수신된 메시지를 처리하기 위한 자신만의 방법을 메서드(method) 라고 부른다.

@Vincent @muki4742 @eundini93

52P

부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴을 Template Method 패턴이라고 부른다.

@Vincent

59P

여기서 이야기하고 싶은 것은 코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다는 것이다. 다시 말해 클래스 사이의 의존성과 객체 사이의 의존성은 동일하지 않을 수 있다.

@Vincent @muki4742 @eundini93

한 가지 간과해서는 안 되는 사실은 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드를 이해하기 어려워진다는 것이다. 코드를 이해하기 위해서는 코드뿐만 아니라 객체를 생성하고 연결하는 부분을 찾아야 하기 때문이다. 반면 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드는 더 유연햊고 확장 가능해진다. 이와 같은 의존성의 양면성은 설계가 트레이드오프의 산물이라는 사실을 잘 보여준다.

@Vincent @freebear @muki4742 @eundini93

설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다는 사실을 기억하라.

@muki4742

여러분이 훌륭한 객체지향 설계자로 성장하기 위해서는 항상 유연성과 가독성 사이에서 고민해야 한다.

@freebear

61P

인터페이스는 객체가 이해할 수 있는 메시지의 목록을 정의한다는 것을 기억하라.

@muki4742

63P

다형성이란 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답할 수 있는 능력을 의미한다. 따라서 다형적인 협력에 참여하는 객체들은 모두 같은 메시지를 이해할 수 있어야 한다. 다시 말해 인터페이스가 동일해야 한다는 것이다.

@Vincent

이를 지연 바인딩 또는 동적 바인딩이라고 부른다. 그에 반해 진통적인 함수 호출처럼 컴파일 시점에 실행될 함수나 프로시저를 결정하는 것을 초기 바인딩 또는 정적 바인딩이라고 부른다. 객체지향이 컴파일 시점의 의존성과 실행 시점의 의존성을 분리하고, 하나의 메시지를 선택적으로 서로 다른 메서드에 연결할 수 있는 이유가 바로 지연 바인딩이라는 메커니즘을 사용하기 때문이다.

@Vincent

64P

인터페이스를 재사용할 목적이 아니라 구현을 재사용할 목적으로 상속을 사용하면 변경에 취약한 코드를 낳게 될 확률이 높다.

@Vincent @muki4742

67P

따라서 책임의 위치를 결정하기 위해 조건문을 사용하는 것은 협력의 설계 측면에서 대부분의 경우 좋지 않은 선택이다.

@Vincent @freebear

추상화를 중심으로 코드의 구조를 설계하면 유연하고 확장 가능한 설계를 만들 수 있다.

@freebear

설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다는 사실을 기억하라.

@muki4742

여러분이 훌륭한 객체지향 설계자로 성장하기 위해서는 항상 유연성과 가독성 사이에서 고민해야 한다.

@freebear

61P

인터페이스는 객체가 이해할 수 있는 메시지의 목록을 정의한다는 것을 기억하라.

@muki4742

63P

다형성이란 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답할 수 있는 능력을 의미한다. 따라서 다형적인 협력에 참여하는 객체들은 모두 같은 메시지를 이해할 수 있어야 한다. 다시 말해 인터페이스가 동일해야 한다는 것이다.

@Vincent

이를 지연 바인딩 또는 동적 바인딩이라고 부른다. 그에 반해 진통적인 함수 호출처럼 컴파일 시점에 실행될 함수나 프로시저를 결정하는 것을 초기 바인딩 또는 정적 바인딩이라고 부른다. 객체지향이 컴파일 시점의 의존성과 실행 시점의 의존성을 분리하고, 하나의 메시지를 선택적으로 서로 다른 메서드에 연결할 수 있는 이유가 바로 지연 바인딩이라는 메커니즘을 사용하기 때문이다.

@Vincent

64P

인터페이스를 재사용할 목적이 아니라 구현을 재사용할 목적으로 상속을 사용하면 변경에 취약한 코드를 낳게 될 확률이 높다.

@Vincent @muki4742

67P

따라서 책임의 위치를 결정하기 위해 조건문을 사용하는 것은 협력의 설계 측면에서 대부분의 경우 좋지 않은 선택이다.

@Vincent @freebear

추상화를 중심으로 코드의 구조를 설계하면 유연하고 확장 가능한 설계를 만들 수 있다.

@freebear

8장에서 살펴보겠지만 컨텍스트 독립성(context independency) 이라고 불리는 이 개념은 프레임워크와 같은 유연한 설계가 필수적인 분야에서 그 진가를 발휘한다.

@muki4742

69P

현실적으로는 NoneDiscountPolicy만을 위해 인터페이스를 추가하는 것이 과하다는 생각이 들 수도 있을 것이다.

@eundini93

여러분이 작성하는 모든 코드에는 합당한 이유가 있어야 한다. 비록 아주 사소한 결정이더라도 트레이드오프를 통해 얻어진 결론과 그렇지 않은 결론 사이의 차이는 크다. 고민하고 트레이드오프하라.

@Vincent @freebear @eundini93

72P

이처럼 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 합성이라고 부른다.

@muki4742

코드 재사용을 위해서는 상속보다는 합성을 선호하는 것이 더 좋은 방법이다.

@Vincent

객체지향이란 객체를 지향하는 것이다.

@muki4742

객체지향에서 가장 중요한 것은 애플리케이션의 기능을 구현하기 위해 협력에 참여하는 객체들 사이의 상호작용이다. 객체들은 협력에 참여하기 위해 역할을 부여받고 역할에 적합한 책임을 수행한다.

@eundini93

독서회 참여하신 분들 추가 피드백을 댓글로 남겨주세요!
아까 오프라인에서 나눔 하셨던 내용도 정리해서 올려주시면 감사드리겠습니다!

11개의 좋아요
2

2장에서는 객체지향의 핵심 개념이라고 생각되는 트레이드오프 에 대한 개념이 처음으로 소개됩니다.

트레이드오프는 IT 소프트웨어 개발 분야가 아닌 여러 분야에서도 사용되는 보편적인 용어로, 원하는 목표에 대해 모든 것을 동시에 만족할 수는 없으므로 적절한 자원 내에 선택하는 것을 의미합니다.

대한민국의 개발자들은 소프트웨어 개발 분야로 처음 취업을 하면 직장상사에게 가장 많이 듣는 말의 내용 중 하나는 밑의 문장일 거라고 생각합니다.

회사는 학교가 아니다.
학교에서 배운 이론은 실무에서 사용할 수 없고
실무의 방식을 따라야 한다.

이 말은 실무에서는 학교에서 배운 이론을 사용하지 않는다는 뜻일 것입니다.

기업에서는 언제 도망갈지 모르는 개발자에게 커리어패스를 충족시켜줄 코드품질이 나오도록 기다려줄 여력은 없으며, 공부시키는 것도 돈이고, 언제 도망갈지 모르기 때문에 전문 지식이 필요한 대학교의 이론을 도입하기 보다는 아무나 채용하더라도 유지보수 할 수 있도록 1년차의 수준의 초보적인…누구나 디버깅을 할 수 있는 낮은 품질의 소스코드를 지향하게 되는 것이라고 생각합니다.

그러면서 10년, 15년, 20년차 개발자도 1년차 수준의 추상화 수준을 지닌 정말 돌아만가는 코드를 짜게 되고, 그런 코드를 만드는 본인들도 고급 소프트웨어 스킬을 요구하는 회사로 이직을 할 수 없게 되고, 그 코드를 받아서 유지보수하는 주니어 개발자도 코드를 유지보수하는 기간이 커리어패스에 도움이 되지 않는다고 생각하며, 선배들에게 코드로 배울 것이 없어서 도망가게 되는 거라고 생각합니다.

그렇게 되면 남아있는 사람들이 계속 저수준의 코드를 유지보수하게 되고, 본인들도 애정을 들인 코드가 아니기 때문에 추상화에 대해 고민하지 않은 코드를 계속해서 만들어 나가고 그런 코드가 축적되어 갈 수록 유지보수 시간은 점점 길어져만 갈 것입니다.

그럼 추후 그 프로젝트를 리뉴얼하게 되었을 때 재사용할 수 있는 코드는 적을 것이고… 전부 새로 만들어야 할 것입니다.

소프트웨어 설계란, 거창한 개념이라기 보다는 유지보수할 때 방향을 제시해주는 하나의 컨셉이라고 생각합니다.

많은 사람들이 C#을 사용할 때 프로젝트를 처음 개발하면서 만들어갈 때의 생산성에 대해서만 생각하고, 유지보수 할 때의 생산성은 신경 쓰지 않습니다. (???: MVVM… 그게 돈이 되나?)

IT 솔루션은 많은 시간과 돈을 들여서 개발한 제품이므로 한번 생산된 이후 오랜 시간을 사용해야합니다. (???: 시간은 금이라고 친구~)

고객의 요구는 계속해서 추가되고 변화될 것이므로 변화에 대해 효과적이고 유연한 코드를 생산단계부터 고려하면서 생산해야 하며, 변화에 유연한 코드를 생산하는 이론이 곧 객체지향 패러다임인 것입니다.

지구 상에 존재하는 자원 중에서 무한한 것은 없고, 사람의 시간도 유한한 자원이므로 슈퍼개발자가 결코 제품을 혼자서 품질이 좋은 제품을 개발할 수는 없을 것입니다. (???: 우리 회사는 포괄임금제이므로, 당신의 급여에 야근비가 포함되어 있습니다. 야근하세요.)

여러 사람이 협업하면서 서로의 다른 가치관과 경험에 대해서 하나로 묶어 줄 수 있는 저명한 이론, 곧 기준이론이 있어야 여러 사람이 함께 협업하여 제품을 생산하고 유지보수하는 과정에서 공통된 용어를 통해 소통의 비용을 줄이며 같은 가치관을 갖고 개발하면서 시간을 줄일 수 있습니다.

그래서 SOLID 원칙이 나오는 것이고, SOLID 원칙대로 여러 사람들에게 개발을 시켜봤더니 여러 사람들에게 공통적으로, 반복적으로 나타나는 특징들을 디자인 패턴이라고 부르는 것일 것입니다…(GoF 아저씨들에게 따로 여쭤보지는 못했습니다만, 아마 그럴 거 같아요)

이런 추상화 스킬들을 학사 졸업 기준으로, 대학교에서 처음 프로그래밍을 접하면서 4년의 시간을 과제를 하고 공부를 하며 이론을 훈련합니다.

물론 개발자는 직장인으로서, 기본적으로 회사의 돈을 받는 회사원입니다.
회사원으로서 맡은 바 데드라인을 어기지 않는 한도 내에서 제품을 개발하고 고객과 소통해야 합니다.

주니어 개발자는 보통 추상화가 익숙하지 않으므로, 대학교에서 배운 이론을 신경쓰면서 업무를 하면 업무가 느릴 수밖에 없습니다.
추상화만 하면서 소스코드를 몇번이고 갈아엎어대는 모습을 목격하기 쉽습니다.
그런데 이것은 무척 자연스러운 러닝커브입니다.
그렇기 때문에 이것을 억제하는 것이 아니라 자연스러운 과정이라고 생각하면서 무작정 내가 모르는거 하지마 가 아닌 이론을 기준으로 한 트레이드오프에 대한 기준을 선배 개발자들이 제시해준다면 성장하는 주니어가 나의 일을 성실하게 대신해줄 것입니다.

특히 .NET 주니어 개발자를 성실하게 육성하는 일은 한국땅에 메말라 버린 .NET 에코시스템을 다시 회생할 수 있는 기회이며, 한국에서 유명한 오픈소스가 생산될 수 있는 기반이며, 활성화된 에코시스템은 많은 사람들에게 이직의 기회로 돌아올 것이라고 생각합니다.

개인의 성장이 회사의 성장으로, 개인과 기업이 서로 감사함으로 이어질 수 있는 기업문화가 한국땅에 널리 퍼지면 좋겠습니다.
특히 .NET에서 그런 일이 빈번하게 발생했으면 좋겠습니다.

위와 같은 다짐을 했던 독서회였습니다.

12개의 좋아요
3

저는 조직 관리에 관심이 많았는데, 객체의 자율과 책임이랑 조직 구성원의 자율과 책임이 상당히 유사하다고 느껴졌습니다. 조직 관리에서도 자율과 책임이 잘 되어있어야 하는 것처럼 객체지향의 객체에도 이와 같은 것이 적용되는 것을 보고 많이 비슷해서 새삼 놀랬습니다. 객체를 조직의 구성원처럼 관리해야 한다는 관점을 배울 수 있어서, 이번 회차는 굉장히 흥미로웠습니다.

6개의 좋아요
4

책을 읽지 않아도, 독서회를 참가 안 해도, 마치 제가 읽은 듯 합니다.

정리를 잘 해주셔서 감사합니다.

5개의 좋아요
5

제가 이번 회차를 하면서 상당히 말이 많았던 시간이 아니었나 싶습니다.
제가 얘기를 많이 하면서 이번 회차에서 관련 없던 이야기도 많이 했는데 다들 잘 들어주시고 같이 의견 나눠주셔서 감사합니다.

정말 제가 요즘 일하면서 제일 많이 하는 말이 있습니다.
‘이 걸 이렇게 까지 해야할 필요가 있어요?’
제가 첫 회사에 입사했을 때 당시의 사수분은 깃헙도 스택오버플로우도 모르시고 개발을 실무 지식이 없는 1년차처럼 개발하셨습니다. 물론 그 분도 그 때 당시 8년차가 되었을 때까지(지금은 12년차가 되셨겠군요) 배움이 없는 회사만을 다니셨기 때문에 그러셨을 것이라 지금은 생각이라도 하지만 그 때는 그 분 밑에서 배우면서 너무 많은 반대의견을 생각한 끝에 저 혼자 여기저기 커뮤니티를 알아보면서 C#과 윈폼에 대해서 배웠었습니다. 저도 그런 사수분 밑에서 개발을 배웠다보니 추상화를 제대로 해본 적이 없었습니다.
그래서 최근에 저보다 경험 많은 동료 분과 함께 협업을 하는 과정에서 제 지식 수준에서는 이해할 수 없는 러닝커브가 생겨 위에서 했던 말을 입에 달고 살고 있습니다. 그 과정에서 어디까지 추상화할 지도 제 선택이고 어디까지 의존성을 부여할 지도 제 선택이라는 것을 이번 장에서 많이 느꼈습니다. 트레이드오프 라는 말을 좀 더 와닿게 느낄 수 있던 회차라 엄청 좋았습니다.

또한, 스터디를 하면서 부가적으로 했던 말들 중에 하나를 덧붙이자면 얼마 전에 체리피커에 대한 동영상을 하나 보았는데, 감명 깊어 해당 내용을 토대로 같이 의견도 나누었습니다. 아래는 의견을 나누기 전에 저의 주장입니다. @Vincent 님이 말씀하셨던 것처럼 저 역시도 같은 의미의 말을 했었습니다.

기업은 신입에게 실무를 가르치고 신입을 올바르게 육성할 사회적 책임이 있다.
대학교는 이론을 배우는 곳이고 직장은 이론을 바탕으로 실무를 배우고 익히는 곳이다.

예전에 대학교를 다닐 때에 강연에서 들은 말입니다. 저는 강연 때 이 말을 듣고 엄청 공감을 많이했습니다. 하지만 제가 겪은 대부분의 한국 기업은 기업이 가진 사회적 책임을 지지 않으려 했습니다. 어떤 직군을 막론하고 신입에게 대학교를 다닐 때 부터 이론이 아닌 실무 지식을 쌓고 오길 바랍니다. 그러면서 회사는 직원을 회사와 함께 성장하는 인적 자원이 아니라 회사가 돌아갈 때 필요한 하나의 톱니바퀴같은 부품처럼 생각하는 걸 과거 회사를 다니면서 많이 느꼈고, 전형적인 체리피커의 모습이 아닐까 생각이 되었습니다.
제가 이런 경험들을 통해 느낀 게 하나 있습니다. 미래에 언젠가 회사에서 누군가를 책임지는 직급이 된다면 내가 경험한 악한 사람들 처럼 되지 말아야겠구나.
이 글을 보시는 분들도 제가 본 영상들이 도움이 되었으면 좋겠습니다.

아래는 제가 감명깊게 보았던 체리피커 에 대한 관련 유튜브 영상입니다.

부가적으로 이 영상을 보고 다른 분이 추천해주신 유튜브 영상입니다.
제가 올린 링크는 유튜버의 말투가 거슬리실 수도 있어 아래 영상을 추천드립니다.

5개의 좋아요
6

안녕하세요 오브젝트 독서회 2회차 내용 정리해봤습니다.

제가 책을 읽으며 중요하다고 혹은 와닿는 문장입니다.

41P

훌륭한 협력이 훌륭한 객체를 낳고 훌륭한 객체가 훌륭한 클래스를 낳는다.

44P

첫 번째 사실은 객체가 상태와 행동을 함께 가지는 복합적인 존재라는 것이다. 두 번째 사실을 객체가 스스로 판단하고 행동하는 자율적인 존재라는 것이다.

48P

객체지향 프로그램을 작성할 때는 먼저 협력의 관점에서 어떤 객체가 필요한지를 결정하고, 객체들의 공통 상태와 행위를 구현하기 위해 클래스를 작성한다.

59P

여기서 이야기하고 싶은 것은 코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다는 것이다. 다시 말해 클래스 사이의 의존성과 객체 사이의 의존성은 동일하지 않을 수 있다.

61P

따라서 어떤 클래스를 기준으로 하느냐에 따라 상속 관계에 참여하는 클래스의 역할이 달라진다.

69P

여러분이 작성하는 모든 코드에는 합당한 이유가 있어야 한다. 비록 아주 사소한 결정이더라도 트레이드오프를 통해 얻어진 결론과 그렇지 않은 결론 사이의 차이는 크다. 고민하고 트레이드오프하라.

Chapter 02를 읽으며 전체적으로 객체지향을 보다 직관적으로 알 수 있었다고 생각합니다.
제가 아직 경험이 많지 않기에 객체지향처럼 구조를 이해해야하는 부분에서 직관적이지 않아 이해하거나 코드를 작성할 때 헷갈리는 부분이 많았습니다. 이러한 부분에서 Chapter02는 객체지향에서 자주 사용되는 단어를 구체적으로 정의하고 설명하고 활용하고 상호작용하는 예시를 알려주어 이해하기 좋았습니다.

저녁에 뵙겠습니당 !

6개의 좋아요
7

기능에만 집중하다보면 유지보수를 쉽게 하기 위해서라는 목표를 잊는 것 같은데 좋은 말씀 감사합니다. 당장은 무의미하다는 소리를 듣더라도 계속해서 시도해봐야겠네요 ㅎㅎ

3개의 좋아요