TIL #220917

📚 TIL

---

오브젝트, 노마드코더 캐럿마켓, 방송대 수업, AC2

🖍 오브젝트 책 읽고 스터디 참여하기

 

오늘부터 오브젝트 책 읽기를 시작했어요!

오늘부터 스터디가 시작되기 때문이에요 ㅎㅎ 그래서 1~3장을 읽었어요

1장 객체, 설계에서는 티켓 판매 애플리케이션을 구현해보면서 객체지향 설계를 배웠어요

2장 객체지향 프로그래밍에서는 영화 예메 시스템을 예시로 객체지향 프로그래밍의 강력함을 알게 되었어요

3장 역할, 책임, 협력에서는 세 단어로 객체지향 설계의 핵심을 이해했어요

저는 객체지향을 잘 몰라서 오브젝트 스터디에 참여하였는데 많이 배울 수 있을 것 같아요!

책 내용이 좋아서 핵심적인 문장들을 정리해봤어요

 

1장 객체, 설계

 

• 모든 모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해하기 쉬워야 한다
• 결국 필요한 최소한의 의존성만 유지하고 결합도를 낮추는 객체지향적 설계를 해야 한다
• 객체를 인터페이스와 구현으로 나누고 캡슐화로 객체 내부의 세부적인 사항을 감춘다
• 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하면 응집도를 높일 수 있다
• 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍이라고 부른다
• 절차적 프로그래밍은 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다
• 데이터와 프로세스가 동일한 모듀 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍이라고 부른다
• 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다
• 책임의 이동 - 객체지향 설계에서는 각 객체에 책임이 적절하게 분배되고 객체는 자신을 스스로 책임진다
• 객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것이다
• 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다
• 그러므로 결국 설계는 트레이드오프의 산물이다
• 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다
• 의인화는 현실에서는 수동적인 존재를 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙이다
• 훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다
• 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다

 

2장 객체지향 프로그래밍

 

• 프로그래밍하는 동안 어떤 클래스가 필요한 지를 고민하기 전에 어떤 객체들이 필요한지 고민해야 한다
• 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다
• 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 한다
• 객체지향 패러다임이 강력한 이유는 요구사항을 분석하는 초기 단계부터 프로그램을 구현하는 마지막 단계까지 객체라는 동일한 추상화 기법을 사용할 수 있기 때문이다
• 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결될 수 있다
• 예제에서 클래스로 구현했을 때 인스턴스 변수의 가시성은 private이고 메서드의 가시성은 public이다
• 훌륭한 클래스를 설계하기 위한 핵심은 어떤 부분을 외부에 공개하고 어떤 부분을 감출지를 결정하는 것이다
• 클래스의 내부와 외부를 구분해야 하는 이유는 경계의 명확성이 객체의 자율성을 보장하고 프로그래머에게 구현의 자유를 제공하기 때문이다
• 객체는 상태와 행동을 함께 가지는 복합적인 존재이며 스스로 판단하고 행동하는 자율적인 존재다
• 캡슐화와 접근 제어는 객체를 외부에서 접근 가능한 퍼블릭 인터페이스와 내부에서만 접근 가능한 구현 두 부분으로 나눈다
• 인터페이스와 구현의 분리 원칙은 훌륭한 객체지향 프로그램을 만들기 위해 따라야 하는 핵심 원칙이다
• 프로그래머의 역할을 클래스 작성자와 클라이언트 프로그래머로 구분하는 것이 유용하다
• 클래스 작성자는 새로운 데이터 타입을 프로그램에 추가하고, 클라이언트 프로그래머는 클래스 작성자가 추가한 데이터 타입을 사용한다
• 구현 은닉은 클라이언트 프로그래머는 내부 구현은 무시한 채 인터페이스만 알고 있어도 클래스를 사용할 수 있기 때문에 머릿속에 담아둬야 하는 지식의 양을 줄일 수 있게 해준다
• 클래스 작성자는 인터페이스를 바꾸지 않는 한 외부에 미치는 영향을 걱정하지 않고도 내부 구현을 마음대로 변경할 수 있다
• 의미를 좀 더 명시적이고 분명하게 표현할 수 있다면 객체를 사용해서 해당 개념을 구현하면 전체적인 설계의 명확성과 유연성을 높일 수 있다
• 객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 메시지를 전송하는 것뿐이다
• 메시지를 수신한 객체는 스스로의 결정에 따라 자율적으로 메시지를 처리할 방법을 결정한다
• 수신된 메시지를 처리하기 위한 자신만의 방법을 메서드라고 부른다
• 메시지와 메서드의 구분에서부터 다형성의 개념이 출발한다
• 오버라이딩은 부모 클래스에 정의된 같은 이름, 같은 파라미터 목록을 가진 메서드를 자식 클래스에서 재정의하는 경우를 가리킨다
• 오버로딩은 메서드의 이름은 같지만 제공되는 파라미터의 목록이 달라 원래의 메서드를 가리지 않는다
• 코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다. 클래스 사이의 의존성과 객체 사이의 의존성은 동일하지 않을 수 있다
• 코드를 이해하기 어려워지나 코드는 더 유연해지고 확장 가능해진다는 의존성의 양면성이 있다
• 부모 클래스와 다른 부분만을 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법을 차이에 의한 프로그래밍이라고 부른다
• 다형성이란 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답할 수 있는 능력을 의미한다
• 메시지와 메서드를 실행 시점에 바인딩하는 것을 지연 바인딩 또는 동적 바인딩이라고 부른다
• 전통적인 함수 호출처럼 컴파일 시점에 실행될 함수나 프로시저를 결정하는 것을 초기 바인딩 또는 정적 바인딩이라고 부른다
• 상속을 구현 상속과 인터페이스 상속으로 분류할 수 있고 구현 상속을 서브클래싱, 인터페이스 상속을 서브타이핑이라고 부른다
• 순수하게 코드를 재사용하기 위한 목적으로 상속을 사용하는 것을 구현 상속이라고 한다
• 다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유할 수 있도록 상속을 이용하는 것을 인터페이스 상속이라고 한다
• 상속은 구현 상속이 아니라 인터페이스 상속을 위해 사용해야 한다
• 추상 클래스와 인터페이스는 트레이드오프가 된다
• 추상화를 사용하면 추상화의 계층만 따로 떼어 놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술할 수 있고 설계가 좀 더 유연해진다
• 상속은 캡슐화를 위반하고 설계를 유연하지 못하게 만든다는 문제가 있는데 합성은 상속이 가지는 두 가지 문제점을 모두 해결한다
• 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 합성이라고 부른다

 

3장 역할, 책임, 협력

 

• 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다
• 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다
• 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다
• 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다
• 객체의 행동을 결정하는 것이 협력이라면 객체의 상태를 결정하는 것은 행동이다
• 협력은 객체를 설계하는데 필요한 일종의 문맥(context)을 제공한다
• 책임을 크게 '하는 것'과 '아는 것'의 두 가지 범주로 나누어 세분화할 수 있다(크레이그 라만)
• 책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에 메시지보다 추상적이고 개념적으로도 더 크다
• 객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것이다(크레이그 라만)
• 적절한 협력이 적절한 책임을 제공하고, 적절한 책임을 적절한 객체에게 할당해야만 단순하고 유연한 설계를 창조할 수 있다
• CRC 카드는 역할을 식별하고, 책임을 할당하며, 협력을 명시적으로 표현하는 구체적이면서도 실용적인 설계 기법이다
• 자율적인 객체를 만드는 가장 기본적인 방법은 책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 정보 전문가 패턴이다
• 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법을 책임 주도 설계라고 부른다
• 메시지가 객체를 선택하게 하면 객체가 최소한의 인터페이스, 충분히 추상적인 인터페이스를 가질 수 있게 된다
• 객체가 가질 수 있는 상태는 행동을 결정하고 나서야 비로소 결정할 수 있다
• 역할을 구현하는 가장 일반적인 방법은 추상 클래스와 인터페이스를 사용하는 것이다
• 협력에 참여하는 후보가 여러 종류의 객체에 의해 수행될 필요가 있다면 그 후보는 역할이 되지만 단지 한 종류의 객체만이 협력에 참여할 필요가 있다면 후보는 객체가 된다
• 협력 ─ reference → 역할 ─ select from → 객체 ─ instance of → 클래스
• 협력을 구체적인 객체가 아니라 추상적인 역할의 관점에서 설계하면 협력이 유연하고 재사용 가능해지며 설계의 구성 요소를 추상화할 수 있다
• 추상화가 가지는 두 가지 장점은 협력의 관점에서 역할에도 동일하게 적용될 수 있다
• 연극 안에서 배역을 연기하는 배우라는 은유는 협력 안에서 역할을 수행하는 객체라는 관점이 가진 입체적인 측면들을 훌륭하게 담아낸다
• 협력이라는 문맥 안에서 역할은 특정한 협력에 참여해서 책임을 수행하는 객체의 일부다

 

밤에는 스터디에 참여했어요! 저 빼고 다 백엔드분들이었어요 ㄷ ㄷ

그래서 제가 한분씩 질문을 드렸어요 ㅋㅋ

면접 대비도 되고 인출하는 연습도 할 수 있어서 좋았어요

그리고 자율성을 높이게 설계를 변경하는 실습을 진행해봤어요

다양한 설계를 배우니 사고가 확장되는게 좋네요 ㅎㅎ

 

---

 

🖍 노마드코더 캐럿마켓 강의 듣기

 

오늘은 4.9부터 4.13까지 수업을 들었어요

반응형으로 sm, lg, xl 등 크기를, dark로 디자인 모드를 적용할 수 있어요

Tailwind 2.0까지는 큰 css 파일에서 필요없는 클래스를 삭제하는 방식으로 동작했는데요

Tailwind 3.0부터는 Just-In-Time 컴파일러로 필요한 클래스를 바로 생성해준대요

그래서 선택자를 쌓아서 사용할 수 있고 대괄호를 사용해서 필요한 값을 CSS 없이 적용할 수 있대요

우와 지금도 많이 배운 것 같은데 5강부터는 더 많은걸 배운대요

Tailwind 기능이 엄청나게 많은가봐요

 

---

 

🖍 방송대 수업 듣기 - 수리통계학

 

오늘부터 수리통계학 수업을 듣기 시작해서 1~3강을 수강했어요

1강 통계적 추론의 기초개념에서는 통계적 추론의 정의와 관련 용어, 과정과 역사를 이해했어요

2강 통계학과 확률에서는 확률, 확률변수, 확률분포, 기댓값을 학습했어요

3강에서는 결합확률분포, 공분산과 상관계수, 적률생성함수, 조건부확률분포를 배웠어요

배웠던 수업들과 내용이 겹쳐서 복습하는 느낌이네요

 

---

 

🖍 AC2 멘토링 참여하기

 

오늘은 CTA를 실습하는 멘토링 시간을 가졌어요!

CTA는 인터뷰하는 사람의 전문성을 얻어내는 인터뷰 방식인데요

AC2 워크샵에서 배운걸 써먹어보려고 멘토님을 대상으로 실습을 해봤어요 ㅎㅎ

기억을 떠올릴 수 있는 질문하기, 인터뷰의 의도 드러내기라는 피드백을 얻었어요

다음주에는 마지막 멘토링 시간이라 회고를 해보기로 했어요~

 

---

 

😁 오늘 한 일

---

 

📕 공부하기

- 오늘은 책을 읽고 강의를 들었어요

- 오브젝트 책이 객체지향이지만 되게 좋네요!

 

😄 친구들이랑 놀기

- 오늘은 인천에 사는 동기들이랑 만나서 놀았어요

- 다른 지역에 사는 동기가 인천에서 일을 하러 와서 자취방에 놀러갔어요!

- 점심으로 닭갈비먹고 디저트사서 자취방에서 유튜브보다가 낮잠잤어요 ㅎㅎ

- 떠들고 디저트먹고 편하게 놀았어요~ 가까이 사니까 좋네요!