2009-04-02 6 views
1

우리는 매우 구체적으로 모듈로 설명 할 수있는 우리의 응용 프로그램에 많은 기능을 가지고 있습니다. 일반적으로 일종의 설정 대화 상자가 있으며 사용자가 확인을 클릭하면 프로세스를 실행하고 해당 프로세스를 실행합니다. 때로는 좀 더 복잡해지기 때문에 사용자는 새 대화 상자를 열어 잠시 동안 대화 상자에서 작업하여 기본 데이터베이스를 변경하는 많은 작업을 수행합니다. 내가 모듈을 종료보다 끝이 있다면큰 프로젝트에서 어떻게 수업을 구성합니까?

내가 전형적으로 WorkerPanel.cs WorkerData.cs SetupOptions.cs이 될 수있는 몇 가지 표준 클래스

ConfigPanel.cs 
ConfigPanelData.cs 
ProcessRunner.cs 
ApiWrapper.cs (for calling the process from somewhere else) 

와 끝까지 (패널 상태는 실행 사이에 지속)

: lib 디렉토리/WhateverBackendStuffINeedToSupportModule ApiWrapper는

은 현재 각각에 대한 폴더가 있습니다

UI/Panels/ 
    Module1Panel.cs 
    Module2Panel.cs 
UI/PanelData/ 
    Module1PanelData.cs 
    Module2PanelData.cs 
UI/PanelManagers 
    Module1PanelManager.cs 
    Module2PanelManager.cs 
Core/Module1/ 
    Module1.cs 
    Module1Helpers.cs 
Core/Module2/ 
    Module2.cs 
    Module2Helpers.cs 

자세히 알 수 있듯이 모든 것이 실제로 확산됩니다. 50 개 이상의 모듈을 사용하면 폴더가 실제로 구성되지 않습니다. 심지어 하위 시스템에 의해 그들을 깨고, 그들은 여전히 ​​엉망입니다. 모든 것이 모여서 모든 것이 클래스 유형이 아닌 함수로 분리되도록하는 것이 나쁜 설계입니까?

Module1/ 
    Module1Panel.cs 
    Module1PanelData.cs 
    Module1PanelManager.cs 
    Module1PanelLib.cs 
    Module1PanelWrapper.cs 
Module2/ 
    Module2Panel.cs 
    Module2PanelData.cs 
    Module2PanelManager.cs 
    Module2PanelLib.cs 
    Module2PanelWrapper.cs 

어떻게 수업을 구성하고 장점/단점이 있습니까?

답변

0

는 그냥 모든 것이 기능보다는 클래스 형식으로 을 분리 함께 있도록 모든 것을 넣어 나쁜 디자인이 될 것인가?

일반적인 규칙은 상황, 개인 환경 설정 및 코드의 변경 패턴에 따라 다릅니다. 그러나 나는 다음과 같은 일을 제안 :

  • 는 중복을 제거하기 위해 상위 클래스에 공통 코드의 정도를 유지합니다. 어쩌면 일부 하위 클래스는 필요하지 않습니다.
  • "모듈"이 무슨 뜻인지 잘 모르겠지만 별도의 어셈블리를 사용하지 않고 같은 프로젝트에서 네임 스페이스 + 하위 디렉터리를 사용하여 물건을 분리하는 것이 좋습니다. 어셈블리를 전개 분리 등의 목적으로 만 사용하십시오.
  • "헬퍼 (helper)"클래스는 약간의 코드 냄새가납니다. 그들은 OO 원칙을 위반할 수 있습니다. 자세한 정보는이 링크를 확인하십시오 : http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx. 어쩌면 코드를 재구성하고 같은 클래스의 필요성을 줄이며 동시에 더 깨끗한 OO 디자인의 이점을 얻을 수 있습니까?