DIP (Dependency Inversion Principle) 는 의존성 역전 준말로 아래와 같은 원칙을 가지고 있습니다. A. 상위 모듈은 하위 모듈에서 아무것도 가져오지 않아야 한다.B. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항(구체적 구현)은 추상화에 의존해야 합니다. DIP 원칙을 처음 봤을 때 구현에 의존하지 말고 추상화 계층에 의존을 하라는 이전의 원칙과 비슷하게 느꼈습니다. 하지만 DIP는 단순히 인터페이스에 의존하는 것을 넘어, 고 수준 모듈과 저 수준 모듈의 관계까지 아우르는 원칙입니다. 즉 전체 시스템의 모듈들이 구체적인 구현에 의존하지 않는다면 유연하게 소프트웨어를 확장을 할 수 있습니다.  DIP 관련 예시를 살펴 보겠습니다.  알림이라는 클래스가 이메일 서비스와 ..

ISP 는 Interface Segregation Principle (인터페이스 분리 원칙) 준말로 아래와 같은 원칙을 가지고 있습니다. 클라이언트가 자신이 이용하지 않는 메서드에 의존하면 안된다. 클라이언트가 목적과 용도에 맞게 인터페이스를 제공하여 사용하지 않는 메소드를 제거해야 한다는 것입니다. 즉 사용하지 않는 메소드는 상속 받지도 말고 구현 하지도 말아라 입니다.  이는 인터페이스를 더 작고 특화된 단위로 분리함으로써 클라이언트의 의존성을 최소화하고 유연성을 높이는 것을 목표로 합니다.하나의 큰 인터페이스 대신 여러 개의 작은 인터페이스로 나누어 각 클라이언트가 필요한 기능 만을 구현할 수 있도록 하는 것입니다. 이렇게 함으로써 시스템의 결합도를 낮추고 유지보수성을 향상시킬 수 있습니다. 차의 ..

리스코프 치환 원칙(LSP)은 SOLID 원칙중에서 가장 이해하기가 어려웠습니다. 우선 리스코프라는 이름을 가진 분이 연구를 했다고 하는데 컴퓨터 과학 분야에 유명한 분인 것 같습니다. 튜링상을 받았다고 하니 대단하신 분이죠.  LSP 를 한 줄로 정리해서 말하면서브 타입은 언제나 기반 타입으로 교체를 할 수 있어야 한다. 내용이 너무 어려워서 이걸 풀어서 쉽게 설명 드리면 부모 클래스의 인스턴스를 사용하는 위치에 자식 클래스의 인스턴스를 사용 했을 때 코드가 원래의 의도대로 동작을 해야 한다는 의미입니다. 추상층에서 정의된 부모가 제공해준 메소드들을 재 정의를 하지 말고 사용을 하라는 의미 입니다.(부모가 준 정보를 훼손하지 말고 사용하라는 뜻 같습니다) 다형성의 원리도 클래스를 상속 및 합성하여 타입..

OCP 를 한문장으로 정리하면 아래와 같습니다.   확장에 대해서는 개방적이고 수정은 폐쇄적이어야 한다. OCP 자료 참고한 영상이 있는데 OCP 원칙을 예시로 IT 기업인 애플로 비유했을 때 이해가 확 되었다.애플의 제품들을 보면 다른 기기와 호환성을 별로 였지만, 애플 기기간에 호환성을 최고이다 .즉 아이폰, 맥북, 아이패드, 에어팟의 호환성은 애플만의 감성 영역이고 생태계를 잘 구성해놓은것 같다.어디까지 비유이지만 수정에 대해서 닫혀 있어야 하고 확장에는 열려있어야 한다면 생각해봐야 하는 게추상화와 다형성이 아닐까 한다. OCP가 어려운 내용은 아니고 변경이 될만한 부분에 대해서 생각해보고 인터페이스 or 추상클래스로 추상화를 한 후 다형성을 이용한 확장을 가능하게 하는 설계의 원칙이다. OCP 를..

객체 지향 SOLID 원칙은 코드를 작성하면서 지켜야할 객체 지향 몇가지 원칙중 하나입니다. 디자인 패턴을 공부할때 SOLID 원칙에 기반해서 패턴이 생성되기 때문에 필자는 이 참에 "객체 지향 기본을 잘 공부해야겠다" 라고 생각하고 공부를 했습니다. SRP를 하나의 문장으로 정의하면 아래와 같습니다.  한 클래스는 오직 하나의 변경 이유만을 가져야 합니다. 이는 객체 지향 프로그래밍(OOP)에서 클래스를 설계할 때, 하나의 클래스에 모든 기능을 넣는 '갓 클래스'를 경계하는 원칙입니다.처음에 저게 가능할까? 라는 생각을 했었습니다. 물론 개발하면서 객체 지향 원칙을 모두 다 지켜가며 할수는 없습니다. 다만 한 클래스의 변경 이유는 하나만 가져야 한다니 당황을 했습니다. 그래도 SOLID는 프로그래밍 신..

0. 필자의 디자인 패턴을 배우는 목적  회사에서 여러 프로젝트를 진행하면서 내가 작성한 코드가 더이상 나이질 기미가 안보이고 점점 스파게티로 코드 복붙 작성이 되는것 같아 어떻게 하면 고객 요구사항에 유연하게 대처하면서 코드 품질을 올릴수있을까를 생각하다고 예전 부터 공부를 하고 싶어했던 디자인 패턴 책을 구매를 하고 스터디를 하게 되었다 지금껏 읽어 왔던 개발 서적들은 저자가 말하고자 하는 바 자체를 이해하지 못하여 끝까지 읽기가 어려웠다. 물론 내 경험과 역량 부족이지만 지금까지 쌓아왔던 내 개발 경험에 비추어 보았을때는 글에서 소개되는 내용이 왜 필요하고 어떤점이 좋은지가 명확하게 판단하기가 너무 힘들었다. 그러다가 좀 더 쉽게 읽을수 있는 책을 찾다가 헤드 퍼스트라 디자인 패턴 책을 찾았다.  ..