리셋 되지 말자

너무 잘 정리를 해주신 글이 있어서 링크 적음...!! https://defacto-standard.tistory.com/113 "고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다." - Pass "추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다." "자주 변경되는 구체 클래스에 의존하지 마라." 무슨소린지 1도 모르겠었지만(물론 지금도 모름) 자주 변하는 것보다는 자주 변하지 않는 것에 의존하도록 하라는 것 같다. 자주 변하는 것 vs 자주 변하지 않는 것(거의 변화가 없는 것) 자주 변하는 것 : 구체적인 것 자주 변하지 않는 것 : 개념이나 전략 등의 추상적인 것 예시1 : 자동차와 타이어 자동차 객체와 타이어..

단일 책임 원칙(SRP)와 인터페이스 분할 원칙(ISP) - 클래스를 나누느냐 인터페이스를 나누느냐 SRP와 ISP는 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다.프로젝트 요구사항과 설계자의 취향에 따라 선택될 수 있다. 하지만 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 할 수 있다. 인터페이스 최소주의 원칙 인터페이스를 통해 메서드를 외부에 제공할 때 최소한의 메서드만 제공하라는 것이다. 상위 클래스는 풍성하게, 인터페이스는 작게 앞의 게시물 '상속과 인터페이스'에서 상위 클래스는 풍성할수록 좋고, 인터페이스는 작을수록 좋다고 언급했다. 이는 리스코프 치환 원칙(LSP)로 예를 들 수가 있다. LSP에 따라 하위 객체는 상위 객체인 척 할 수..

"클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다." - 로버트 C. 마틴 인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 한다. - 위키백과 예시(책의 예시가 이해가 안가서 다른 사이트를 많이 찾아보고 혼자 생각해냄) Action 인터페이스 package isp01; public interface Action { public abstract void buy(); public abstract void sell(); }위와같은 인터페이스가 존재할 때, 구매자와 판매자를 구현한다고 가정한다. Guest(구매자) package isp01; public class Guest implements A..

LSP-개방 폐쇄 원칙 "서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다." - 로버트 C. 마틴 객체 지향에서의 상속은 계층도가 아닌 분류도가 돼야 한다. 따라서 객체 지향의 상속은 아래의 조건을 만족해야 한다. 하위 클래스 is a kind of 상위 클래스 : 하위 분류는 상위 분류의 한 종류이다. 구현 클래스 is able to 인터페이스 : 구현 분류는 인터페이스할 수 있어야 한다. 계층도 형태의 클래스 아버지를 상위 클래스(base type)으로 하는 딸 이라는 하위 클래스(sub type)가 있다고 가정한다. 전형적인 계층도 형태이며, 객체 지향의 상속을 잘못 적용한 예다. 아버지 춘향이 = new 딸(); 춘향이가 아버지의 역할도 해야한다. -> 이상하다..

OCP-개방 폐쇄 원칙 "소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다." - 로버트 C. 마틴 역시 잘 모르겠다. 이를 의역하면 아래와 같다. "자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다." 모르겠다. 코드적으로 해석해보자면 "기존의 코드를 수정하지 않고, 추가적인 기능을 추가할 수 있어야 한다." 예시1 - JDBC JDBC를 사용하는 사용자는 데이터베이스가 MySQL에서 Oracle로 바뀌더라도 Connection(연결)을 설정하는 부분 외에는 따로 수정할 필요가 없다. Connection 설정 부분을 별도의 설정 파일로 분리해두면 클라이언트 코드는 단 한줄도 변경할 필요가 없다. JDBC뿐만 아니라 i..

SRP-단일 책임 원칙 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다" - 로버트 C. 마틴 잘 모르겠다. 예시를 들어보자.아래와 같이 남자라고 하는 클래스와 남자 클래스에 의존하는 다양한 클래스가 있다고 한다. 남자가 역할이 너무 많다. 만약 남자가 여자친구와 헤어졌다고 하면, 기념일 챙기기, 키스하기는 더이상 필요가 없게 된다. 이러한 경우에 역할(책임)을 분리하라는 것이 '단일 책임 원칙' 이다. 위의 예에서는 클래스에 단일 책임 원칙을 적용했지만 단일 책임 원칙은 속성, 메서드, 패키지, 모듈, 컴포넌트, 프레임워크 등에도 적용될 수 있는 개념이다. 예제1 - 속성이 단일 책임 원칙을 지키지 못하는 경우 객체 지향 세계에서 남자는 군대에 가고, 여자는 절대 군대에 가지 ..

SOLID 객체지향의 4대 특성 캡슐화 상속 추상화 다형성 SOLID SRP(Single Responsibility Principle):단일 책임 원칙 OCP(Open Closed Principle):개방 폐쇄 원칙 LSP(Liskov Substitution Principle):리스코프 치환 원칙 ISP(Interface Segregation Principle):인터페이스 분리 원칙 DIP(Dependency Inversion Principle):의존 역전 원칙 위의 5가지 원칙은 응집도는 높이고 결합도는 낮추라는 고전 원칙을 객체 지향의 관점에서 재정립한 것이라고 할 수 있다. http://toby.epril.com/?p=727 참고 결합도: 모듈(클래스) 간의 상호 의존 정도로서 결합도가 낮으면 모듈..