* 주관적인 생각이 포함된 포스팅입니다. 디자인 패턴 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴. 유지보수와 확장이 쉬운 설계를 할 때 주로 SOLID 법칙을 적용해야 한다고 들한다. 내가 알기론 디자인 패턴은 이 SOLID 원칙은 준수하여 제시된 설계 패턴인 것으로 알고 있다. SOLID 원칙이 도구라면 디자인 패턴은 결과물인 셈? SOLID 원칙을 되새기며 설계할 필요 없이 디자인 패턴을 적용하면 된다는 것! 디자인 패턴은 패턴 카탈로그에서 제시한 생성, 행동, 구조라는 3가지로 용도에 따라 분류가 가능하다. 생성패턴: 객체 인스턴스를 생성하는 패턴으로, 클라이언트와 그 클라이언트가 생성해야 하는 객체 인스턴스 사이의 연결을 끊어주는 패턴 행동패턴: 클래스와..
* 주관적인 생각으로 작성한 리뷰입니다. 계기 지금 진행 중인 객체지향 스터디의 첫 스타트는 ‘객체지향의 사실과 오해’를 읽음으로 시작됐다. 객체지향 개념에 대해 관심이 없었기 때문에 이 책이 유명하다는 사실도 몰랐다. 객체지향 개념에 관심이 없던 사람이니 당연히 나는 객체지향에 대해서 1%도 모르는 사람이었다. 참 모순이다. 객체지향에 관심이 없는 사람이 객체지향 프로그래밍 스터디를 하고 있지 않은가? 두번째 읽을 책이 스프링과 관련된 책이었기 때문에 그저 스프링에 관련된 스터디이겠거니 하고 단순하게 스터디에 참여하게 되었다. 이러한 이유로 나는 ‘객체지향의 사실과 오해’를 읽게됐다. 책을 읽기 전 계기에 말했다시피 나는 객체지향 개념이 한참이나 부족한 사람이었다. 그럼에도 개발이 되긴 했으니까.. (..
1주차 때와 같이 노션으로 공유합니다.. Chapter.5 책임과 메시지 https://glass-milkshake-24b.notion.site/Chapter-5-ebb4d3543fb2444a98203712334742da Chapter.5 책임과 메시지 목차 glass-milkshake-24b.notion.site Chapter.6 객체 지도 https://glass-milkshake-24b.notion.site/Chapter-6-f88bdb2c9eff4348b3aeb42d54e557b1 Chapter.6 객체 지도 목차 glass-milkshake-24b.notion.site Chapter.7 함께 모으기 https://glass-milkshake-24b.notion.site/Chapter-7-2641..
노션에 열심히 정리해서 티스토리로 옮기려고 했지만, 일부가 복사되지 않아 링크로 대체했습니다.. 노션에 정리한 이유는 PDF로 내보내기 위함입니다.(그리고 실시간 저장돼서 편함, 책 읽으면서 정리할 때 딱임) Chapter.1 협력하는 객체들의 공동체 https://glass-milkshake-24b.notion.site/Chapter-1-4dbc9b3348ed41aa8edb93f4b189c415 Chapter.1 협력하는 객체들의 공동체 시작 glass-milkshake-24b.notion.site Chapter.2 이상한 나라의 객체 https://glass-milkshake-24b.notion.site/Chapter-2-f8d2d76ee89c487ba65fc2c8d870440b Chapter.2 이..
※본 포스팅은 지극히 주관적이므로 정확하지 않을 수 있습니다. 시작 클래스를 작성하기 위한 다섯 가지의 유명한 디자인 패턴이다. SOLID는 다음과 같은 원칙의 약자이다. S: 단일 책임 원칙(Single Responsibility Principle, SRP) O: 개방-폐쇄 원칙(Open-Closed Principle, OCP) L: 리스코프 치환 원칙(Liskov Substitution Principle, LSP) I: 인터페이스 분리 원칙(Interface Segregation Principle, ISP) D: 의존관계 역전 원칙(Dependency inversion Principle, DIP) 이 5가지의 원칙을 하나하나씩 예제와 함께 살펴보자 SRP, 단일 책임 원칙 SRP: 단일 책임 원칙(S..
템플릿 메소드(Template Method) 패턴 : 행동패턴 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법. 변하지 않는 기능은 슈퍼클래스에 만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 한다. 평소에도 사용하던 방법이었는데, 이게 패턴이었다고..? 슈퍼 클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 prtected 메소드 등으로 만든 뒤 서브 클래스에서 이런 메소드를 필요에 맞게 구현해서 사용하는 방법이다. -토비의 스프링에서- 예제를 확인해보면 단번에 이해가 될 것이다. Car 클래스 public abstract class Car { // 선택적으로 오버라이드 가능한 훅 메소드 protected void star..
