프로젝트 디자인 패턴 문제

Question

현재 저는 유치원, 초등학교 및 고등학교에 맞춤화 된 C# "학교 시스템 프로젝트"에 참여하고 있습니다. 이를 위해 필자는 문자 그대로 사용자 정의 기능을 사용하여 유사한 클래스를 갖는 세 개의 별개 프로젝트를 만들었습니다.

문제는 주로 버그와 새로운 기능으로 인해 클래스를 수정해야 할 때마다 3 개의 프로젝트에서 유사한 클래스를 업데이트해야한다는 것입니다.

지금, 나는 내 감각에 와서 내 디자인 패턴이 이것보다 좋음을 알게되었습니다. 내 유형의 프로젝트에서 사용자 정의 된 기능과 유사한 클래스를 공유하는 업계 표준은 무엇입니까? 모두 사용할 수있는 라이브러리 클래스를 만드는 것이 좋을까요, 아니면 더 나은 옵션이 있을까요?

Answer 1

라이브러리를 만들고 공통 속성 및 기능을 가진 기본 클래스 School을 정의합니다.

public abstract class School 
{ 
    public string Name { get; set; } // common property for each school 

    public int GetStudentCount() // common method for each school 
    { 
    } 
} 

그런 다음 각 학교에 대한 어린이 수업을 정의하고 다른 학교에는없는 행동을 지정하십시오.

public class Elementary : School 
{ 
    public string SomethingSpecial { get; set; } 
} 

추상화 및 가상화 방법 및 속성을 사용하여 재정의되어야하거나 무시할 수있는 기본 동작을 정의 할 수도 있습니다.

이렇게하면 도메인 객체 (학교, 학생, 교사 등 사용하는 모든 엔티티)와 그 동작을 정의하는 라이브러리가 하나만 있습니다. 그리고 당신이 무언가를 바꿔야 할 때마다, 당신은 단지이 하나의 도서관에서 작동합니다.

Visitor 및 Factory 메소드와 같은 일부 디자인 패턴을 확인하여 새로운 아키텍처 설계가 명확해질 수도 있습니다.

Answer 2

나는 추상적 인 패턴을 살펴볼 것이다.

예를 볼 수 있습니다 here.

Answer 3

클래스를 수정하려고하면 버그가 발생합니다. 따라서 수업 설계에 SOLID 원칙을 구현해야합니다. 특별히 단일 책임, 개방/폐쇄, 인터페이스 분리 및 종속성 반전/IOC. 당신은 그런 http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

비즈니스 로직에서 데이터 액세스 http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

에 대한 작업 패턴의 저장소 및 단위를 소개합니다 (당신이 고체에 대해 충분히 생각이없는 경우) SOLID 원칙에 대한 학습을위한 다음 문서를 참조 할 수 있습니다 여러 논리와 같은 로직을 기반으로 패턴을 사용할 수 있습니다. 팩토리 메소드 패턴을 사용할 수 있고, 하나 이상의 클래스를 사용할 수 있습니다. 어댑터 클래스를 사용할 수 있으며, 관찰자 ​​패턴 등을 사용할 수있는 모든 통지를 보낼 수 있습니다.

Answer 4

기본 디자인 패턴 사소한 변화를 다루기 위해 공유 할 수 무엇이든 공유하고 차이가 발생하는 경우 만 다른 - 일정한 구조

템플릿 방법 및 전략

그들은 기술적 인 수준에서만 차이가 있지만 일반적인 원칙을 공유 할 수 있습니다.

Answer 5

당신은 특정 프로젝트가 3 개의 프로젝트 사이에서 공통적이며 3 개의 프로젝트 모두에서이 클래스를 별도로 사용한다고 말하고 있기 때문에.이제는 이러한 공통 클래스를 변경하려는 경우 이러한 세 가지 프로젝트를 모두 변경해야합니다.

반드시 디자인 원칙 (OO 원칙)을 준수해야합니다.

,이 세 가지 프로젝트 외부

추출물 모든 일반적인 클래스를 "다양 무엇을 캡슐화"더 이상의 클래스가있는 경우 유틸리티 프로젝트처럼, 하나의 클래스 또는 단일 프로젝트에 보관하십시오. 세 가지 프로젝트 모두에서 그 유틸리티 프로젝트를 공유하십시오.

이제 공통된 클래스에 추가되거나 새로운 버그가 수정 될 때. 그것의 1 개의 장소 변화.