이름은 같지만 네임 스페이스가 다른 여러 클래스가 있습니까?

이름은 같지만 네임 스페이스가 다른 클래스가있는 코드 (중요한 경우 C #)를 만났습니다. 그것들은 모두 같은 논리적 인 것을 나타내는 경향이 있지만, 종종 같은 객체의 다른 "보기"입니다. 다른 네임 스페이스는 때때로 동일한 솔루션의 일부이며 동일한 dll입니다.

나는 내 생각을 가지고 있지만이 연습에 대해 확실한 도구를 사용하지 못하거나 피할 수있는 패턴을 사용하는 것으로 간주 될 수는 없습니다.

스머프 네이밍에 관한이 질문은 이것에 관한 것입니다 . 이름을 명확하게하려면 임의적이고 광범위하게 접두사가 필요할 수 있습니다.

이 연습에 관한 지침은 무엇입니까?

naming

— 텔라 스틴
소스

OOP에는 많은 예외가 있지만 처음에는 특히 모든 클래스가 동일한 수준의 접근성을 공유하는 경우이 나쁜 디자인을 고려합니다. 어떤 파일에서 클래스 이름을 읽을 때 네임 스페이스 지시문을 참조하지 않고 클래스가 어떤 네임 스페이스에서 즉시 있는지 알고 싶습니다.

— Leopold Asperger

동일한 상태를 처리하는 여러 관련 개체가있는 경우가 있지만 일반적으로 기능별로 구분됩니다. 뷰에 맞게 모델을 조정하는 객체가 하나있을 수 있습니다. 다른 하나는 객체에서 계산을 수행 할 수 있습니다. 다른 하나는 어댑터 또는 외관 일 수 있습니다. 당신이있을 그래서 FooAdapter, FooViewer, FooCalculator, 등 그러나 확실하게 똑같은 이름이 없습니다. 그러나 특정 수업에 대한 자세한 정보가 없으면 답변을 제공하기가 어렵습니다.

@JohnGaughan- Employee예제로 고려 하십시오. 다른 직원, HR 직원, 외부 직원 직원이 있습니다. 이름은 모두 "직원"이며 다양한 도우미 (EmployeeRepository, EmployeeView 등)가 있습니다. 그것들은 모두 같은 dll에 있으며, 공통된 속성 (이름, 제목)을 공유하지만 모두 다릅니다 (전화 번호, 급여).

— Telastyn

Employee여러 번 모델링하는 시스템으로 작업 한 결과 , 모든 속성이 결합 된 모델이 필요하고 type또는 department속성이 포함 된 것처럼 들립니다 . 그렇지 않으면 불필요한 코드 복제가 있습니다.

이것이 네임 스페이스가 시작되는 이유 중 하나가 아니 었습니까? 이름 충돌을 허용하려면?

— Dan Pichelman

답변:

나는 내 프로젝트 중 하나에서 이것을 보았고 작업 한 후에 그러한 사용법에 대해 대답하려고 노력할 것입니다.

코드 가독성

우선, 코드 가독성이 중요하며이 관행은 그에 반한다는 점을 고려하십시오. 누군가 코드를 읽고 함수가 있다고 가정 해 봅시다 doSomething(Employee e). Employee다른 패키지에 10 개의 서로 다른 클래스가 있기 때문에 먼저 입력 선언을 사용하여 입력 내용이 무엇인지 확인해야 하므로 더 이상 읽을 수 없습니다 .

그러나 이것은 높은 수준의 견해이며 우리는 종종 임의의 이름 충돌로 보이며, 그 의미는 나머지 코드와 패키지에 포함되어 있기 때문에 아무도 신경 쓰지 않거나 찾을 수 없습니다. 당신이 볼 경우 즉, 로컬 때문에 물론, 문제가없는 Employee내에서 hr우리가 직원의 HR보기에 대해 얘기하고 있음을 알 필요가 패키지로 제공된다.

이 패키지를 떠나 자마자 문제가 발생합니다. 다른 모듈 / 패키지 / 등에서 작업하고 직원과 함께 작업해야하는 경우, 해당 유형을 완전히 검증하지 않으면 이미 가독성이 떨어집니다. 또한 10 개의 다른 Employee클래스를 사용하면 IDE의 자동 완성이 더 이상 작동하지 않으며 직원 유형에서 수동으로 선택해야합니다.

코드 복제

이러한 각 클래스는 서로 관련되어 있기 때문에 중복이 많이 발생하여 코드가 저하 될 수 있습니다. 대부분의 경우 직원의 이름 또는 식별 번호와 같은 클래스가 있으며 각 클래스는 구현해야합니다. 각 클래스가 고유 한 관점을 추가하더라도 기본 직원 데이터를 공유하지 않으면 쓸모 없지만 비용이 많이 드는 엄청난 양의 코드가 생깁니다.

코드 복잡성

무엇을 물어볼 수 있을까요? 결국, 각 클래스는 원하는만큼 간단하게 유지할 수 있습니다. 실제로 문제가되는 것은 변경 사항을 전파하는 방법입니다. 기능이 풍부한 소프트웨어를 사용하면 직원 데이터를 변경할 수 있으며이를 모든 곳에 반영하려고합니다. 한 여성이 방금 결혼했고 이름을 X에서Y그것 때문에. 여기저기서이 작업을 수행 할 수있을만큼 어려운 일이지만,이 독특한 수업이 모두있을 때는 더욱 어려워집니다. 다른 디자인 선택에 따라 이는 각 클래스가 자체 리스너 종류를 구현해야하거나 변경 사항을 통지해야한다는 것을 의미 할 수 있습니다. 기본적으로 처리해야하는 클래스 수에 적용되는 요소로 변환됩니다. . 물론 더 많은 코드 복제와 더 적은 코드 가독성 .. 이와 같은 요소는 복잡성 분석에서 무시할 수 있지만 코드베이스의 크기에 적용될 때 반드시 성가시다.

코드 커뮤니케이션

디자인 선택과 관련된 위의 코드 복잡성 문제 외에도 높은 수준의 디자인 선명도를 낮추고 도메인 전문가와의 의사 소통 능력을 상실합니다. 아키텍처, 디자인 또는 요구 사항에 대해 이야기 할 때 더 이상 간단한 말을 자유롭게 할 수 없습니다 given an employee, you can do .... 개발자는 더 이상 employee그 시점에서 실제로 무엇을 의미 하는지 알 수 없습니다 . 도메인 전문가는 물론 그것을 알 것입니다. 우리 모두가 할. 일종의. 그러나 소프트웨어 측면에서 더 이상 의사 소통하기가 쉽지 않습니다.

문제를 제거하는 방법

이 사실을인지하고 후에 경우 팀이 그것을 해결하기 위해 문제가 충분히 큰 것을 동의한다, 당신이 그것을 다루는 방법에서 작업해야합니다. 일반적으로 관리자에게 전체 팀에게 일주일을 주도록 요청할 수 없으므로 쓰레기를 버릴 수 있습니다. 따라서 본질적으로 이러한 클래스를 한 번에 하나씩 부분적으로 제거 할 수있는 방법을 찾아야합니다. 이것에 대한 가장 중요한 부분은 팀 전체와 함께 Employee실제로 무엇인지 결정하는 것입니다. 마십시오 없는 한 신 직원에 개별 속성을 모두 통합 할 수 있습니다. 핵심 직원에 대해 더 많이 생각하고 가장 중요한 것은 해당 Employee수업이 상주 할 장소를 결정하는 것입니다.

코드 검토를 수행하는 경우 문제가 더 이상 더 이상 커지지 않도록하는 것이 특히 쉽습니다. 즉, 다른 사용자를 Employee다시 추가하려는 경우 모든 사람이 자신의 궤도에 멈춰야 합니다. 또한 새로운 하위 시스템이 합의 된 내용을 준수 Employee하고 이전 버전에 액세스 할 수 없도록주의하십시오.

프로그래밍 언어에 따라 @Deprecated팀이 변경해야 할 작업을 즉시 실현할 수 있도록 팀을 돕기 위해 결국 제거 될 클래스를 표시 할 수도 있습니다 .

오래된 직원 클래스를 제거하는 방법에 대해 각 개별 사례마다 가장 잘 제거되는 방법을 결정하거나 일반적인 패턴에 동의 할 수 있습니다. 클래스 이름을 붙여 실제 직원을 감싸거나 패턴 (장식 자 또는 어댑터가 떠오름)을 사용하거나 또는 또는

간단히 말해 :이 "연습"은 기술적으로는 건전하지만 길가에서 더 이상 발생하지 않는 숨겨진 비용으로 가득 차 있습니다. 문제를 즉시 제거 할 수는 없지만 해로운 영향을 즉시 포함시킬 수 있습니다.

— 솔직한
소스

Core 클래스를 갖는 것은 좋은 해결책처럼 보입니다. 다른 클래스도 확장 할 수 있습니다. IDE에 대해 자동 완성 기능은 상황에 가장 잘 맞는 클래스를 알 수있을 정도로 똑똑합니다. 전반적으로, 특히 코드베이스가 내부적으로 사용되는 경우 왜 이것이 큰 문제인지 알 수 없습니다.

— 알림 A

한 가지 상황을 벗어나면 충분히 똑똑하지 않습니다. 실제로 문제가되는 클래스가 모두 필요한 클래스를 고려하십시오. 자동 완성은 전혀 도움이되지 않습니다. 그리고 이것들을 다른 10 가지 클래스와 구분하지도 않습니다. 그러나 실제 문제는 새로운 팀원인데, 모든 패키지 도메인이 실제로 무엇이고 어떤 도메인을 선택해야하는지조차 모릅니다.

— Frank

동일한 이름의 여러 클래스가 동일한 컨텍스트에서 사용되는 경우 어렵습니다. 나는 그 경우를 보지 못했다. 이름이 같은 여러 클래스를 보았지만 언급 한 것과 동일한 컨텍스트에서 자주 사용되지는 않습니다.

— 알림 A

@randomA-슬프게도,이 경우는이 코드베이스에서 상당히 일반적입니다.

— Telastyn

좋은 지적이지만, 핵심 문제에 대한 해결책을 제시하지는 않았으며 핵심 문제가 해결 된 후에 만 방법론 ( "직원이 실제로 무엇인가")입니다. 당신이 버린 유일한 명백한 "솔루션"( "모든 개별 속성을 하나의 신-직원으로 통합"), 그렇습니다. DB.Employee, Marshalling.Employee, ViewModels.Employee, GUI.Views.Employee 등이 있다고 가정 해보십시오.

— Pablo H

Scala Collection Framework가 이에 대한 좋은 예입니다. 변경 가능하고 변경 불가능한 콜렉션뿐만 아니라 직렬 및 병렬 콜렉션 (나중에 분배 될 수도 있음)도 있습니다. 예를 들어 네 가지 Map특성이 있습니다.

scala.collection.Map
scala.collection.immutable.Map
scala.collection.mutable.Map
scala.collection.concurrent.Map

플러스 세 ParMap:

scala.collecion.parallel.ParMap
scala.collecion.parallel.immutable.ParMap
scala.collecion.parallel.mutable.ParMap

더 흥미로운 :

scala.collection.immutable.Map            extends scala.collection.Map
scala.collection.mutable.Map              extends scala.collection.Map
scala.collection.concurrent.Map           extends scala.collection.mutable.Map

scala.collecion.parallel.ParMap           extends scala.collection.Map
scala.collecion.parallel.immutable.ParMap extends scala.collecion.parallel.ParMap
scala.collecion.parallel.mutable.ParMap   extends scala.collecion.parallel.ParMap

따라서 ParMap확장 ParMap확장 Map및 Map확장 Map확장 Map.

그 밖의 무엇을 :하지만, 현실을 직시하자 것이다 당신은 그들에게 전화? 이것은 완벽하게 이해됩니다. 그것이 네임 스페이스를위한 것입니다!

— 요 르그 W 미타 그
소스

"이것은 네임 스페이스를위한 것입니다!" => +1

— svidgen

나는 이것을 좋아하지만 C # / .NET 세계에서 병렬 클래스를 병렬 하위 네임 스페이스로 옮길 때 도우미 클래스 System.Threading.Parallel과 충돌합니다.이 클래스는 병렬 처리를 위해 많이 사용됩니다. 컬렉션 클래스에서 '동시 액세스'를 의미하는 데 이미 사용중인 네임 스페이스 'Concurrent'를 사용하고 싶지 않았습니다. 타협으로 하위 네임 스페이스 'Parallelized'를 선택했습니다.

— redcalx

이것은 본질적으로 반대되는 두 가지 대답이 모두 정확한 실제 질문입니다. 다음 은 우리가 진행중인 프로젝트에 대한 토론 의 실제 예 입니다.

@Jorg와 @Frank의 두 가지 대답을 바탕으로 한 방향으로 가고 싶은 두 가지 중요한 고려 사항이 있다고 생각합니다.

동일한 이름의 클래스에서 둘 이상의 동일한 이름의 클래스를 사용해야하는 상황이 예상되는 경우 동일한 이름을 사용하지 않는 이유입니다. 즉, 작업해야 hr.Employee하지만 동시에을 통해 권한을 봐야 security.Employee하는 경우 실제로 성가 시게됩니다.
같은 이름의 수업이 모두 동일하거나 매우 유사한 API를이 있다면 반대로, 다음 경우의 좋은 예이다가 있어야 다른 네임 스페이스와 같은 이름을 사용. 스칼라 예제는 정확히 모든 Map클래스가 동일한 인터페이스를 구현하거나 서로의 서브 클래스 인 경우입니다. 이 경우, 모호함 또는 "혼란"은 논란의 여지없이 좋은 것으로 불릴 수 있습니다. 사용자는 클래스 또는 인터페이스의 모든 구현을 인터페이스와 서브 클래스의 요점으로 동일하게 취급 할 수 있기 때문입니다.

— 스프 타크 르
소스