2012-05-21 2 views
4

몇 가지 구현 (예 : 메모리 내, NHibernate, XML 기반 등)을 가질 수있는 인터페이스 집합이있는 경우 클래스 이름 자체에 네임 스페이스 힌트를 제공하는 것이 현명합니까? 예를 들어 :클래스 이름에 네임 스페이스 힌트를 포함해야합니까?

MyDomain.Infrastructure.ISomeProvider 
MyDomain.Infrastructure.ISomeOtherProvider 
MyDomain.Infrastructure.IYetAnotherProvider 

그때이있을 수 있습니다 두 번째 경우

MyDomain.Infrastructure.Impl.MemoryBased.SomeProvider 
MyDomain.Infrastructure.Impl.MemoryBased.SomeOtherProvider 
MyDomain.Infrastructure.Impl.MemoryBased.YetAnotherProvider 
MyDomain.Infrastructure.Impl.XmlFileBased.SomeProvider // etc... 
MyDomain.Infrastructure.Impl.NHibernate.SomeProvider // etc... 

MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedSomeProvider 
MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedSomeOtherProvider 
MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedYetAnotherProvider 
MyDomain.Infrastructure.Impl.XmlFileBased.XmlSomeProvider // etc... 
MyDomain.Infrastructure.Impl.NHibernate.NHibernateSomeProvider // etc... 

, 내가 클래스가 내 코드 어디에서나 사용하고있는 구현 분명 이름 자체는 있지만 네임 스페이스별로 그룹화 한 다음 클래스 이름에 포함 시키려면 약간 중복 된 것처럼 보입니다. 그렇습니까?

세 번째 옵션은 수 있습니다 : 이제 그룹에있는 유일한 방법을 중복 네임 스페이스를 제거하지만, 한

MyDomain.Infrastructure.ISomeProvider 
MyDomain.Infrastructure.Impl.MemoryBasedSomeProvider 
MyDomain.Infrastructure.Impl.MemoryBasedSomeOtherProvider 
MyDomain.Infrastructure.Impl.MemoryBasedYetAnotherProvider 
MyDomain.Infrastructure.Impl.XmlSomeProvider // etc... 
MyDomain.Infrastructure.Impl.NHibernateSomeProvider // etc... 

/클래스 이름 접두사입니다 클래스를 구성 할 수 있습니다. 내가 폴더로 그들을 분리하고 수동으로 새로 만든 된 파일의 네임 스페이스를 조정할 수있을 것 같아요. 이 스타일들 중 하나에 대해 다른 것들보다 확실한 이점이 있습니까? 1

MyDomain.Infrastructure.Impl.MemoryBased.SomeProvider 
MyDomain.Infrastructure.Impl.MemoryBased.SomeOtherProvider 
MyDomain.Infrastructure.Impl.MemoryBased.YetAnotherProvider 
MyDomain.Infrastructure.Impl.XmlFileBased.SomeProvider // etc... 
MyDomain.Infrastructure.Impl.NHibernate.SomeProvider // etc... 

+0

down-voted, vote-to-close - 심각하게? 이것은 아주 좋은 질문입니다. – ColinE

+0

사용자에게 콘텐츠를 경고 할 수있는 권한을 부여하는 문제는 필연적으로 사용자가 우월감을 높이는 것 이외의 다른 이유로 전혀 권한을 남용하지 않기를 선택하게되는 것입니다. – Chris

+0

트렌드가 올바른 방향으로 움직이기 때문에 3x + 1이있는 것처럼 보입니다. – ColinE

답변

1

옵션 # 나의 선호하는 옵션이 될 것이다. 구현 당 여러 프로젝트 (메모리, ORM, XML)에 포함시켜야한다고 주장 할 수 있습니다. 그런 다음 해당 시점의 IoC 컨테이너 및 요구 사항에 따라 런타임에 필요한 구현을로드 할 수 있습니다.

네임 스페이스를 뒤범벅하고 클래스 이름에 구현 유형을 추가하면 잔인하며 네임 스페이스가 외부/다른 개발자에게는 무의미 해 보일 것입니다.

4

좋은 질문입니다. 다른 질문에 대답하겠습니다. 누군가가 한 번에 ISomeProvider의 여러 구현을 사용해야 할 가능성이 얼마나 높습니까? 그렇다면 네임 스페이스만으로 명확성을 확보하게되면 불쾌한 정규화 된 네임 스페이스가 필요하게됩니다.

그렇지 않은 경우 구현의 특성을 나타 내기 위해 네임 스페이스를 사용하지만 전체에서 동일한 이름을 공유합니다. 어쨌든, API가 구체적인 구현이 아닌 인터페이스에 의해 정의된다는 사실은 사람들이 어떤 옵션을 선택하든 관계없이 구현을 매우 쉽게 교환 할 수 있음을 의미합니다.

관련 문제