TIL #220924

📚 TIL

---

오브젝트, 방송대 출석수업, AC2

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

 

오늘은 오브젝트 책 5장을 읽었어요

데이터 중심 설계를 개선해보면서 GRASP 패턴을 배워봤어요

정리하다보니 내용이 엄청 많네요.. ㄷ ㄷ

 

5장 책임 할당하기

 

• 책임에 초점을 맞춰서 설계할 때 직면하는 가장 큰 어려움은 어떤 객체에게 어떤 책임을 할당할지를 결정하기가 쉽지 않다는 것이다
• 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 두 가지 원칙을 따라야 한다
  • 데이터보다 행동을 먼저 결정하라 - 데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할 뿐이다
  • 협력이라는 문맥 안에서 책임을 결정하라 - 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다
• 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다
• 메시지를 먼저 결정하기 때문에 메시지 송신자는 메시지 수신자에 대한 어떠한 가정도 할 수 없어 메시지 수신자가 캡슐화된다
• 대중적으로 가장 알려진 책임 할당 기법은 GRASP 패턴이다
• GRASP은 "General Responsibility Assignment Software Pattern(일반적인 책임 할당을 위한 소프트웨어 패턴)"으로 객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리한 것이다
• 설계를 시작하기 전에 도메인에 대한 개략적인 모습을 그려 보는 것이 유용하다
• 도메인 모델은 도메인을 개념적으로 표현한 것이지만 그 안에 포함된 개념과 관계는 구현의 기반이 돼야 한다
• INFORMATION EXPERT(정보 전문가) 패턴: 책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 책임을 할당한다
• LOW COUPLING(낮은 결합도) 패턴: 설계의 전체적인 결합도가 낮게 유지되도록 책임을 할당하여 의존성을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킨다
• HIGH COHESION(높은 응집도) 패턴: 높은 응딥도를 유지할 수 있게 책임을 할당하여 복잡성을 관리할 수 있는 수준으로 유지한다
• CREATOR(창조자) 패턴: 아래 조건을 최대한 많이 만족하는 B에게 객체 A의 생성 책임을 할당한다
  • B가 A 객체를 포함하거나 참조한다
  • B가 A 객체를 기록한다
  • B가 A 객체를 긴밀하게 사용한다
  • B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다(이 경우 B는 A에 대한 정보 전문가다)
• 협력과 책임이 제대로 동작하는지 확인할 수 있는 유일한 방법은 코드를 작성하고 실행해 보는 것뿐이다
• 변경에 취약한 클래스란 코드를 수정해야 하는 이유를 하나 이상 가지는 클래스다
• 변경에 취약한 클래스는 응집도가 낮으므로 변경의 이유에 따라 클래스를 분리해야 한다
• 코드를 통해 변경의 이유를 파악할 수 있는 방법은 두 가지가 있다
  • 인스턴스 변수가 초기화되는 시점을 살펴보는 것 - 클래스의 속성이 서로 다른 시점에 초기화되거나 일부만 초기화된다는 것은 응집도가 낮다는 증거이므로 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다
  • 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것 - 메소드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래스의 응집도가 낮은 것이므로 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다
• 클래스를 분리하면 응집도를 향상시킬 수 있으나 모든 클래스에 결합되어야해서 전체적인 결합도가 높아지고 변경이 어려워진다
• 역할을 사용하여 객체의 구체적인 타입을 추상화하도록 하면 문제를 해결할 수 있다
• POLYMORPHISM(다형성) 패턴: 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하여 객체의 타입에 따라 변하는 로직을 담당할 책임을 할당할 수 있다
• PROTECTED VARIATIONS(변경 보호) 패턴: 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하여 변화와 불안정성이 다른 요소에 나쁜 영향을 미치지 않도록 방지하는 설계를 할 수 있다
• 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계하거나 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만들어 변경에 대비할 수 있다
• 책임과 객체 사이에서 방황할 때 최대한 빠르게 목적한 기능을 수행하는 코드를 작성하고 코드 상에 명확하게 드러나는 책임들을 올바른 위치로 이동시키는 것이 좋다
• 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리팩터링이라고 부른다
• 긴 메서드는 응집도가 낮기 때문에 이해하기도 어렵고 재사용하기도 어려우며 변경하기도 어려운데, 몬스터 메서드라고 부른다
• 작고 목적이 명확한 메서드는 변경을 처리하기 위해 어떤 메서드를 수정해야 하는지를 쉽게 판단할 수 있다
• 메서드의 크기가 작고 목적이 분명하기 때문에 재사용하기도 쉽고 주석들을 나열한 것처럼 보이기 때문에 코드를 이해하기도 쉽다
• 메서드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시켜서 자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 객체를 자율적으로 만들어야 한다

 

밤에는 스터디에 참여했어요!

책을 읽으면서 궁금했던 점과 중요하다고 생각되는 것을 적어봤어요

서로 질문에 답하는 시간을 가지고 실습도 해봤어요

저는 실습에는 열심히 참여를 못했어요 객체지향 코드 작성은 아직 먼 이야기네요..

 

---

 

🧈 방송대 출석수업 수강하기 - 수리통계학

 

오늘은 수리통계학 출석수업을 수강했어요

1강부터 8강 점추정까지 진도를 나갔어요

매주 주말에 수업을 듣네요 ㅠ 휴 이제 수업 3번 남았어요!

과제는 10월 25일까지라 급하지 않아서 다행이에요!

그치만 과제가 3개나 쌓여서 얼른 해야겠어요

오늘 하려고했다가 하나도 못했네요 하핫

 

---

 

🧈 AC2 멘토링 참여하기

 

오늘은 마지막 멘토링을 하는 날이에요!

지금까지의 멘토링을 회고해보는 시간을 가졌어요

멘토링을 하면서 기억에 남았던 주제를 이야기해봤어요

그리고 2022년 남은 3개월동안 뭐할건지 이야기해봤어요

그러다 개발자로서 근무한 6개월 회고를 써보겠다고 얘기했는데요

20분동안 간단하게 월별로 회고를 해보는게 어떻냐고 제안해주셨어요

같이 회고를 써보고 이야기를 나눴어요 ㅎㅎ

글을 어떻게 써야할지 막막했는데 적당히 적어두니까 압박이 줄어들어서 좋았어요~

 

---

 

😁 오늘 한 일

---

 

📕 공부하기

- 오늘은 책을 읽고 수업을 들었어요

- 으아 9월 수업 끝이네요 ㅎㅎ 수업 끝나면 진이 빠져요ㅠ

- 낮에 마트가서 장보고 염색하느라 공부를 많이 못했어요 ㅋㅋ

- 저녁에 다이소도 다녀왔어요 ㅎㅎ 이것저것 많이 했네요

 

🥬 맛있는것 먹기

- 오늘 점심은 엄마아빠랑 대패삼겹쌈밥을 먹었어요

- 채소 종류가 많아가지고 맛있게 먹었어요~

 

 

💇‍♀️ 염색하기

- 오늘은 머리 염색을 했어요! 뿌리가 많이 자랐더라고요

- 색은 더 어두워졌지만 새로 자란 머리 구분이 없어져서 마음에 들어요~~