“Info”접미사를 사용하여 클래스 이름을 정하는 아이디어는 무엇입니까 (예 :“SomeClass”및“SomeClassInfo”)?

실제 장치를 다루는 프로젝트에서 일하고 있으며이 프로젝트에서 일부 클래스의 이름을 올바르게 지정하는 방법에 대해 혼란스러워했습니다.

실제 장치 (센서 및 수신기)가 한 가지이며 소프트웨어에서 의 표현 이 다른 것도 고려할 때 "Info"접미사 이름 패턴으로 일부 클래스의 이름을 지정하려고합니다.

예를 들어, a Sensor는 실제 센서를 나타내는 클래스이지만 (실제로 일부 작동 장치에 연결된 경우) SensorInfo해당 센서의 특성 만 나타내는 데 사용됩니다. 예를 들어 파일을 저장할 때을 직렬화하는 SensorInfo대신 파일 헤더에 a를 직렬화하면 Sensor이해할 수 없습니다.

그러나 이제는 하나의 객체를 사용해야하는지 또는 다른 것을 가져 오는 방법을 결정하거나 두 변형을 실제로 하나의 클래스로 축소해야하는지 여부를 결정할 수없는 객체의 수명주기에 대한 중간 근거가 있기 때문에 혼란스러워합니다.

또한 너무 일반적인 예제 Employee클래스는 분명히 실제 사람을 나타내는 것입니다. 그러나 아무도 EmployeeInfo아는 한 클래스 이름을 제안하지 않습니다.

내가 사용하는 언어는 .NET 이며이 명명 패턴은 프레임 워크 전체에서 공통적 인 것으로 보입니다.이 클래스의 예는 다음과 같습니다.

• Directory그리고 DirectoryInfo수업;
• File그리고 FileInfo수업;
• ConnectionInfo클래스 (대응 Connection클래스 가 없음 );
• DeviceInfo클래스 (대응 Device클래스 가 없음 );

그래서 내 질문은 :이 명명 패턴을 사용하는 것에 대한 일반적인 근거가 있습니까? 이름 쌍 ( Thing및 ThingInfo) 을 갖는 것이 합당한 경우와 ThingInfo해당 Thing클래스가없는 클래스 또는 클래스 만 존재하는 다른 경우가 있습니까?

"정보"는 잘못된 것 같습니다. 개체에는 상태와 동작이 있습니다. "info"는 이미 OOP에 구운 "state"의 또 다른 이름입니다.

여기서 실제로 모델링하려고하는 것은 무엇입니까 ? 다른 코드에서 사용할 수 있도록 소프트웨어의 하드웨어를 나타내는 객체가 필요합니다.

말하기는 쉽지만, 알다시피 그 이상이 있습니다. "하드웨어 대표"는 놀라 울 정도로 광범위합니다. 이를 수행하는 객체에는 몇 가지 우려가 있습니다.

• USB 인터페이스, 직렬 포트, TCP / IP 또는 독점 연결과 통신하는 저수준 장치 통신
• 상태 관리. 장치가 켜져 있습니까? 소프트웨어와 대화 할 준비가 되셨습니까? 바쁜?
• 이벤트 처리. 장치가 데이터를 생성했습니다. 이제 관심있는 다른 클래스로 전달할 이벤트를 생성해야합니다.

센서와 같은 특정 장치는 프린터 / 스캐너 / 팩스 다기능 장치보다 걱정이 적습니다. 센서는 비트 스트림을 생성하는 반면 복잡한 장치는 복잡한 프로토콜과 상호 작용을 가질 수 있습니다.

어쨌든 특정 질문으로 돌아가서 특정 요구 사항과 하드웨어 상호 작용의 복잡성에 따라 여러 가지 방법이 있습니다.

다음은 온도 센서의 클래스 계층 구조를 디자인하는 방법의 예입니다.

• ITemperatureSource : 온도 데이터를 생성 할 수있는 모든 것을 나타내는 인터페이스 : 센서, 파일 래퍼 또는 하드 코딩 된 데이터 일 수도 있습니다 (생각 테스트 : 모의 테스트).

• Acme4680Sensor : ACME 모델 4680 센서 (로드 러너가 가까이있을 때 감지하기에 좋습니다). 여러 인터페이스를 구현할 수 있습니다.이 센서는 온도와 습도를 모두 감지합니다. 이 개체에는 "센서가 연결되어 있습니까?"와 같은 프로그램 수준 상태가 포함됩니다. "마지막 독서는 무엇입니까?"

• Acme4680SensorComm는 : 중고 전적으로 물리적 장치와 통신. 많은 상태를 유지하지 않습니다. 메시지를 보내고받는 데 사용됩니다. 하드웨어가 이해하는 각 메시지에 대해 C # 메소드가 있습니다.

• HardwareManager : 장치를 가져 오는 데 사용됩니다. 이것은 기본적으로 인스턴스를 캐시하는 팩토리입니다. 각 하드웨어 장치마다 하나의 장치 개체 인스턴스 만 있어야합니다. 나사산 A가 ACME 온도 센서를 요청하고 나사산 B가 ACME 습도 센서를 요청하는 경우 이들은 실제로 동일한 물체이므로 두 나사산으로 모두 반환해야한다는 것을 알기에 충분히 똑똑해야합니다.

최상위 레벨에는 각 하드웨어 유형에 대한 인터페이스가 있습니다. C # 데이터 형식 (예 : 원시 장치 드라이버가 사용할 수있는 바이트 배열이 아님)을 사용하여 C # 코드가 장치에서 수행하는 작업에 대해 설명합니다.

같은 수준에서 각 하드웨어 유형마다 하나의 인스턴스가있는 열거 클래스가 있습니다. 온도 센서는 한 가지 유형일 수 있고 다른 하나는 습도 센서 일 수 있습니다.

이 수준 아래의 한 수준은 이러한 인터페이스를 구현하는 실제 클래스입니다. 이들은 위에서 설명한 Acme4680Sensor와 유사한 하나의 장치를 나타냅니다. 장치가 여러 기능을 수행 할 수 있으면 특정 클래스가 여러 인터페이스를 구현할 수 있습니다.

각 장치 클래스에는 하드웨어와 통신하는 저수준 작업을 처리하는 자체 개인 통신 (통신) 클래스가 있습니다.

하드웨어 모듈 외부에서 볼 수있는 유일한 계층은 인터페이스 / 열과 HardwareManager입니다. HardwareManager 클래스는 디바이스 클래스의 인스턴스화, 인스턴스 캐싱 ( 실제로 두 개의 디바이스 클래스가 동일한 하드웨어 디바이스와 통신하는 것을 원하지 않음) 등 을 처리하는 팩토리 추상화입니다 . 특정 유형의 센서가 필요한 클래스는 HardwareManager에 가져 오기를 요청합니다. 특정 열거 형의 장치로, 이미 열거되어 있는지 여부와 장치를 만들고 초기화하는 방법이 아닌지 알아냅니다.

여기서 목표는 비즈니스 로직을 낮은 수준의 하드웨어 로직에서 분리하는 것 입니다. 센서 데이터를 화면에 인쇄하는 코드를 작성할 때 해당 코드가 이러한 분리가 있고 하드웨어 인터페이스를 중심으로하는 경우에만 어떤 유형의 센서를 관리하지 않아야합니다 .

참고 : 다이어그램이 화살표 수프로 바뀌 었으므로 HardwareManager와 내가 그리지 않은 각 디바이스 클래스 사이에는 연관이 있습니다.

이러한 클래스는 여러 네임 스페이스에 분산되어 있기 때문에 단일 통합 규칙을 찾는 것이 약간 어려울 수 있습니다.ConnectionInfoCrystalDecisions 및 DeviceInfo에 있는 것 같습니다 System.Reporting.WebForms).

그러나 이러한 예를 보면 접미사를 두 가지 뚜렷하게 사용하는 것 같습니다.

• 정적 메소드를 제공하는 클래스와 인스턴스 메소드를 제공하는 클래스를 구별합니다. 이것은 경우입니다System.IO 같은 자신의 설명에 의해 밑줄 클래스 :

  디렉토리 :

  디렉토리 및 서브 디렉토리를 작성, 이동 및 열거하기위한 정적 메소드를 노출합니다. 이 클래스는 상속 될 수 없습니다.

  디렉토리 정보 :

  디렉토리 및 서브 디렉토리를 작성, 이동 및 열거하기위한 인스턴스 메소드를 노출합니다. 이 클래스는 상속 될 수 없습니다.

  Info 여기에서 약간 이상한 선택처럼 보이지만 차이점을 비교적 명확하게 만듭니다. Directory 클래스는 특정 디렉토리를 합리적으로 나타내거나 상태를 유지하지 않고도 일반적인 디렉토리 관련 도우미 메소드를 제공 DirectoryInfo할 수 있지만 실제로는 전직 일 수 있습니다.

• 클래스가 정보 만 보유하고 행동을 제공하지 않음을 강조 접미사 이름에서 합리적으로 예상되는 을 .

  나는 그 문장의 마지막 부분이 구별이 말을하는 퍼즐의 조각이 될 수 있다는 생각 ConnectionInfo에서 EmployeeInfo. I 클래스라는이 있다면 Connection, 나는 합리적으로 연결이 내가 좋아하는 방법을 찾고있을 것 has- 것을 실제로 기능으로 날을 제공하기 위해 기대 void Open()하지만, 그들의 권리 염두에두고 아무도 기대하지 않을 것이다 등일 그 Employee클래스가 실제로 수 진짜이 일을 Employee하지, 나 같은 방법을 찾아 void DoPaperwork()나 bool TryDiscreetlyBrowseFacebook().

일반적으로 Info객체 는 특정 시점에 객체 상태 에 대한 정보를 캡슐화합니다 . 시스템에 파일을보고 파일 FileInfo크기와 관련된 객체를 제공하도록 요청하면 해당 객체가 요청을 받았을 때 파일의 크기를보고 할 것입니다 (보다 정확하게는 호출 시점과 리턴 시점 사이의 순간에 파일). 요청의 반환 시간과 FileInfo객체 검사 시간 사이에 파일 크기가 변경되면 해당 변경 사항이 객체에 반영 되지 않을 것으로 예상됩니다 FileInfo.

이 동작은 File개체 의 동작과 매우 다릅니다 . 비 독점 모드에서 디스크 파일 열기 요청 File이 Size속성 을 가진 객체를 생성하는 경우 File객체가 단순히 상태를 나타내는 것이 아니기 때문에 디스크 파일의 크기가 변경되면 반환 된 값이 변경 될 것으로 예상합니다. 파일- 파일 자체를 나타냅니다 .

대부분의 경우 서비스에 더 이상 필요하지 않은 경우 리소스에 연결된 개체를 정리해야합니다. 때문에 *Info객체가 자원에 첨부하지 않는, 그들은 정리를 필요로하지 않습니다. 결과적으로 Info객체가 클라이언트의 요구 사항을 충족시키는 경우 기본 리소스를 나타내지 만 해당 리소스에 대한 연결을 정리해야하는 객체를 사용하는 것보다 코드를 사용하는 것이 좋습니다.

실제 장치 (센서 및 수신기)를 고려하는 것은 한 가지이며 소프트웨어에서 표현 이 다른 것도 "Info"접미사 이름 패턴으로 일부 클래스의 이름을 지정하려고합니다.

예를 들어, a Sensor는 실제 센서를 나타내는 클래스이지만 (실제로 일부 작동 장치에 연결된 경우) SensorInfo해당 센서의 특성 만 나타내는 데 사용됩니다. 예를 들어 파일을 저장할 때을 직렬화하는 SensorInfo대신 파일 헤더에 a를 직렬화하면 Sensor이해할 수 없습니다.

나는이 구별이 마음에 들지 않습니다. 모든 객체는 "소프트웨어의 표현"입니다. 그것이 "개체"라는 단어의 의미입니다.

이제 주변 장치에 대한 정보를 주변 장치와 인터페이스하는 실제 코드와 분리하는 것이 좋습니다. 예를 들어 센서에는 센서가 있습니다. 센서 정보에는 하드웨어가 필요없는 일부 메소드와 함께 대부분의 인스턴스 변수가 포함되어 있으며 센서 클래스는 실제 센서와 실제로 상호 작용합니다. 당신은 가지고 있지 않습니다Sensor 컴퓨터에 센서를하지 않는 한,하지만 당신은 그럴듯이-A를 수 있습니다 SensorInfo.

문제는 이런 종류의 디자인을 거의 모든 클래스로 일반화 할 수 있다는 것입니다. 따라서 조심해야합니다. SensorInfoInfo예를 들어 수업 이 없을 것 입니다. 그리고 Sensor변수 가 있다면 , 자신 과 상호 작용하여 Demeter 의 법칙을 위반하는 것을 알 수 있습니다SensorInfo 회원. 물론 이것도 치명적이지는 않지만 API 디자인은 라이브러리 제작자만을위한 것이 아닙니다. 자신의 API를 깨끗하고 단순하게 유지하면 코드를 유지 관리하기가 더 쉬워집니다.

제 생각에 디렉토리와 같은 파일 시스템 리소스는이 가장자리에 매우 가깝습니다. 로컬로 액세스 할 수없고 사실이 아닌 디렉토리를 설명하려는 상황이 있지만, 일반 개발자는 이러한 상황 중 하나에 있지 않을 수 있습니다. 이런 식으로 수업 구조를 복잡하게 만드는 것은 도움이되지 않습니다. 대조적 인 파이썬의 접근 방식 pathlib: "필요한 것"인 단일 클래스와 대부분의 개발자가 안전하게 무시할 수있는 다양한 보조 클래스가 있습니다. 그러나 실제로 필요한 경우 구체적인 방법을 제외하고 거의 동일한 인터페이스를 제공합니다.

우리는 높은 수준의 비즈니스 로직 코드와 낮은 수준의 모델, 아키텍처 구성 요소 등을 가지고 있기 때문에 컨텍스트 / 도메인이 중요하다고 말할 것입니다 ...

'정보', '데이터', '관리자', '객체', '클래스', '모델', '컨트롤러'등은 모든 개체에 정보 또는 데이터가 있기 때문에 특히 낮은 수준에서 냄새가 나는 접미사 일 수 있습니다. 그 정보는 필요하지 않습니다.

비즈니스 도메인의 클래스 이름은 이상하게 들리거나 100 % 정확한 언어가 아니더라도 모든 이해 관계자가 이야기하는 것과 같아야합니다.

데이터 구조의 좋은 접미사는 'List', 'Map'및 힌트 패턴 'Decorator', 'Adapter'(필요한 경우)입니다.

센서 시나리오에서 SensorInfo센서가 무엇인지 저장하지는 않지만 SensorSpec. Infoimho는 FileInfo크기와 같은 것과 같은 파생 정보입니다. 저장하지 않거나 경로와 파일 이름 등으로 작성된 파일 경로 등

다른 요점 :

Computer Science에는 캐시 무효화 및 이름 지정 작업이라는 두 가지 어려운 작업 만 있습니다.

-필 칼튼

그것은 항상 나에게 몇 초 동안 이름에 대해 생각 나게하고 아무것도 찾지 못하면 이상한 이름을 사용하고 'TODO'표시합니다. IDE가 리팩토링 지원을 제공하므로 나중에 언제든지 변경할 수 있습니다. 좋은 회사 슬로건이 아니라 원하는 때마다 변경할 수있는 코드 만 있습니다. 명심하십시오.

ThingInfo는 Thing에 대한 훌륭한 읽기 전용 프록시 역할을 할 수 있습니다.

참조 http://www.dofactory.com/net/proxy-design-pattern를

프록시 : "다른 개체가 액세스를 제어 할 수 있도록 대리 또는 자리 표시자를 제공합니다."

일반적으로 ThingInfo에는 setter가없는 공용 속성이 있습니다. 이러한 클래스와 클래스의 메서드는 사용하기에 안전하며 백업 데이터, 개체 또는 다른 개체에 대한 변경 내용을 커밋하지 않습니다. 상태 변경이나 다른 부작용은 발생하지 않습니다. 보고 및 웹 서비스 또는 개체에 대한 정보가 필요하지만 실제 개체 자체에 대한 액세스를 제한하려는 모든 위치에 사용할 수 있습니다.

가능하면 ThingInfo를 사용하고 실제 Thing 사용을 실제로 Thing 오브젝트를 변경해야하는 시간으로 제한하십시오. 이 패턴을 사용하는 데 익숙해지면 읽기와 디버깅이 훨씬 빨라집니다.

지금까지이 질문에 아무도이 명명 규칙의 실제 이유를 알지 못하는 것 같습니다.

A는 DirectoryInfo아니다 디렉토리. 디렉토리 에 대한 데이터 가 있는 DTO입니다 . 동일한 디렉토리를 설명하는 많은 인스턴스가있을 수 있습니다. 엔티티가 아닙니다. 버리기 가치 객체입니다. A 는 실제 디렉토리를 나타내지 않습니다. 디렉토리의 핸들 또는 컨트롤러로 생각할 수도 있습니다.DirectoryInfo

이라는 클래스와 대조하십시오 Employee. 이것은 ORM 엔티티 오브젝트 일 수 있으며 해당 직원을 설명하는 단일 오브젝트입니다. ID가없는 값 객체 인 경우을 호출해야합니다 EmployeeInfo. 는 Employee참으로 실제 직원을 대표 않습니다. 가치와 같은 DTO 클래스 EmployeeInfo는 직원을 분명히 나타내는 것이 아니라 설명하거나 직원에 대한 데이터를 저장합니다.

BCL에는 실제로 두 클래스가 모두 존재하는 예가 있습니다. A ServiceController는 Windows 서비스를 설명하는 클래스입니다. 각 서비스마다 이러한 컨트롤러가 얼마든지있을 수 있습니다. A ServiceBase(또는 파생 클래스) 는 실제 서비스이며 개별 서비스마다 여러 인스턴스를 갖는 것이 개념적으로 의미가 없습니다.