개발자 노트

정말 오랜만에 글써보네요! 운 좋게 스타트업에 취직 후... 일을 배우고, 사내에서 스터디를 진행하다보니 글을 작성할 시간이 없었습니다. ㅜ조금 여유가 생겨 회사에서 스터디했던 내용들을 공유드리고자 오랜만에 키보드를 두드리고 있네요. 이 카테고리에서 소개드릴 내용은 로버트 마틴님이 2000년 초반에 말했던 객체지향 5원칙을 설명드리려 합니다. 많은 블로그에서 이 주제를 다뤘겠지만, 잘 이해가 되지 않고 추상적으로 다가오는 글들이 많더군요. 그래서 직접 로버트 마틴님이 쓴 원문을 바탕으로 따로 정리해보았습니다. 정리하는 과정에서 최대한 영어 원문 그대로 의미를 전달하고 싶었습니다. 그래서 한글로 번역한 단어 옆에 영어 단어를 표시해두었습니다. 아무래도 의미가 퇴색 될수밖에 없는 것 같습니다... 예를 들어..

The Dependency Inversion Principle 앞서서 OCP와 LSP에 대해서 배웠습니다. OCP는 변경은 허용하되 수정을 막자는 원칙이였고, LSP는 베이스 클래스가 서브 클래스로 치환될 수 있다는 원칙이였습니다. 이 두 원칙을 엄격히 사용하는데서 비롯되는 구조에 대해 말씀드리겠습니다. 이 구조 자체가 원칙이 되며 이 이름은 The Dependency Inversion Principle이라고 합니다 소프트웨어, 뭐가 문제야? 우리는 소프트웨어를 만드는 개발자로서, 우리 스스로 나쁜 디자인으로 내몰고 있습니다. 왜 이런 일이 일어날까요? 이 문제의 핵심은 바로 bad design을 정의를 하지 않았다는 것에 있습니다. 따라서 나쁜 디자인에 대해 설명드리겠습니다. Bad Design Bad..

INTRODUCTION 용어정리 client, user 특정 클래스나 객체를 사용하는 객체,함수,클래스 등 ISP란? Interface Segeregation Principle의 약자로, 인터페이스를 분리해야한다는 원칙입니다. 문제점 이 원칙이 지켜지지 않았을 경우엔 뚱뚱한 인터페이스(또는 오염된 인터페이스)가 만들어집니다. 이 인터페이스는 대게 응집성이 좋지 않습니다. 다시말해 연관성이 떨어지는 함수가 한 인터페이스에 집중되어 있다는 뜻입니다. 목표 이 fat 인터페이스는 ISP에 따라 분리되어야 하는데, 이 인터페이스를 사용하는 클라이언트는 단일 클래스로 볼것이 아니라, 응집성있는 인터페이스인 추상화된 베이스 클래스를 알아야합니다. 앞으로 알아볼 내용 fat 또는 polluted의 단점 어떻게 이 인..

참고 자료 https://en.wikipedia.org/wiki/Liskov_substitution_principle (wiki liskov-substitution-principle) http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod (LSP article) https://en.wikipedia.org/wiki/Design_by_contract (wiki design_by_contract) Introduction 앞서 OCP의 핵심 메커니즘은 추상화와 다형성을 이용하는 것이였습니다. 바로 상속을 이용하여 abstract base class로부터의 derived class를 생성할 수 있었습니다. 그렇다면 어떤 디자인 규칙(rule)이 이러한 특수..

Open-Closed Principle 클래스, 모듈, 함수 등은 확장에 대해선 열려있어야 하고, 수정에 대해선 닫혀있어야 한다. - MEYER Bertrand(1988) Object-Oriented Software Construction 확장은 허용하고, 수정은 허용하면 안된다. 다시 말하자면, 클래스는 수정없이 확장 가능해야 한다. 원칙 구현 방법 방법은 두 가지가 있습니다. 두 방법은 일반화 방법을 사용하는 것이 공통적이나, 목표나 기술 그리고 결과에서 차이를 가집니다. 1. Meyer's open-closed principle 방법 상속을 통하여 구현하라. 설명 상속을 이용하면, 부모 클래스는 상속을 통하여 구현할 수 있으므로 open에 대해서는 개방적이고, 자식 클래스를 통해 부모 클래스..

단일 책임 원칙 출처 https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html 의문점 도대체 reason to change?는 뭘까? 사람들이 해석하는 reason to change 버그 픽스? 리팩토링? 핵심 reason to change 와 responsibility를 연관 짓는 것. 위 2가지 사항은 프로그래머의 책임 => 프로그램의 디자인이 누구에게 반응해줘야 하는가?! 예시 1.CEO CEO에게 보고하는 것은 C-Level결정임 (CFO, COO, CTO) 2.CFO finance 컨트롤하는 것에 책임 3.COO 회사를 운영하는데 책임 4.CTO 회사의 기술적인 개발에 책임이 있음 [java code] p..