솔리드 원리와 디자인 패턴을 이해할 수 없습니다.

Question

저는 최근 OOP에 들어가려고 노력 중이며, SOLID 원칙 및 디자인 패턴에 문제가 있습니다. 나는 사람들이 왜 그것을 사용 하는지를보고, 나는 그것들을 정말로 사용하기를 원하지만, 클래스를 스펙으로 개발하는 것에 대해 머리를 감쌀 수는 없다. 나는 그러한 것에 대한 나의 이해를 도울 수있는 어떤 것도 정말로 고맙게 생각한다.

Answer 1

나는 대학에서 2 주 동안 디자인 패턴을 사용하고, 책을 아무렇지도 않게 읽었습니다 (Gang of Four). 각 패턴이 제공 한 것을 이해하고 그것들을 사용하여 문제를 해결하는 것은 매우 어려웠습니다. OO 프로그래밍에 많은 경험이없는 개발자였습니다.

나를 실제로 클릭하도록 만든 책은 Head First Design Patterns입니다. 먼저 문제를 제시하고, 개발자가 고려한 다양한 접근 방식을 적용한 다음, 어떻게 수정하여 디자인 패턴을 사용했는지를 보여줍니다. 그것은 매우 간단한 언어를 사용하고 책을 매우 매력적으로 유지합니다.

디자인 패턴이 결국 솔루션을 설명하는 방법이되지만 에이 있으면 솔루션에 클래스를 적용 할 수 없습니다. 다양한 문제에 대한 좋은 해결책을 제시하는 지침으로 생각하십시오. SOLID에 대한

하자 토론 :

1. 단일 책임. 수업에는 단 하나의 책임 만 있어야합니다. 즉, 예를 들어, Person 클래스는 데이터베이스 자체의 지속성과 같은 개인 자체에 관한 도메인 문제에 대해서만 고민해야합니다. 이를 위해서는 예를 들어 PersonDAO를 사용하는 것이 좋습니다. Person 클래스는 책임을 가능한 한 짧게 유지하려고 할 수 있습니다. 클래스가 너무 많은 외부 종속성 (즉, 다른 클래스)을 사용하면 클래스에 너무 많은 책임이 있다는 증상입니다. 이 문제는 개발자가 객체를 사용하여 실제 세계를 모델링하고 너무 멀리 가져 가려고 할 때 종종 발생합니다. 느슨하게 결합 된 응용 프로그램은 탐색하기가 쉽지 않고 실제 세계의 작동 방식을 정확하게 모델링하지 않습니다.
2. 닫힘. 클래스는 확장 가능해야하지만 수정할 수는 없어야합니다. 즉, 클래스에 새 필드를 추가해도 문제가되지 않지만 기존 필드를 변경하는 것은 쉽지 않습니다. 프로그램상의 다른 컴포넌트들은 상기 필드에 의존 할 수있다.
3. 리 스키브 치환. 하위 클래스 dog와 하위 클래스 cat이 전달되면 animal 유형의 객체를 예상하는 클래스가 작동해야합니다. 즉, Animal에는 cat이라는 하위 클래스가 껍질을 벗기 수 없으므로 예를 들어 bark라는 메소드가 없어야합니다. Animal 클래스를 사용하는 클래스는 또한 Dog 클래스에 속한 메서드에 의존해서도 안됩니다. "이 동물이 개라면, 개를 동물에게 던지십시오. 동물이 고양이라면, 고양이에게 동물을 던지십시오."와 같은 일을하지 마십시오.
4. 인터페이스 분리 원칙. 인터페이스를 가능한 한 작게 유지하십시오. 학생이기도 한 선생님은 IStudentAndTeacher라는 단일 인터페이스 대신 IStudent 및 ITeacher 인터페이스를 모두 구현해야합니다.
5. 의존성 반전 원리. 개체는 종속성을 인스턴스화해서는 안되지만 전달되어야합니다. 예를 들어 Engine 객체가있는 Car는 engine = new DieselEngine()이 아니라 engine이 생성자에서 전달되어야한다고 말합니다. 이 방법으로 자동차 클래스는 DieselEngine 클래스에 결합되지 않습니다.