물건을 (내부적으로) 설명하고 공개적으로 식별하기 위해 별도의 물건을 사용해야합니까?

Question

현재 PC에 연결된 장치에서 구성 값을 읽고 설정할 수있는 라이브러리 작업 중입니다. 각 구성 필드는 상수 (public static readonly) 개체로 설명되며이 개체의 이름, 데이터 형식 (값 제한 포함) 및 해당 필드를 읽거나 쓰는 데 필요한 명령 시퀀스가 ​​들어 있습니다.

이 정보는 주로 라이브러리 내부에서만 필요합니다. 그러나 클라이언트 코드는 특정 필드를 읽고 쓸 수 있도록 라이브러리에 알릴 수 있어야하며 필드와 값을 연결하는 사전에서 구성 값 컬렉션을 전달하려고합니다. 이렇게하려면 필드를 식별하는 공개 값을 제공해야합니다.

필드를 내부적으로 설명하고 공개적으로 식별하기 위해 동일한 개체를 사용해도 괜찮습니까? 약간 틀린 느낌이 들지만, 나는 그 이유에 손가락을 대지 못합니다. 나는 당신이 쉬는 것에 대한 나의 의구심을 갖게하거나, 그것이 왜 나쁜 생각인지 또는 무엇을주의해야 하는지를 말해 줄 수 있기를 바랍니다.

업데이트 : 필자는 필드 ID와 필드 액세스 구현에 동일한 개체를 사용했습니다. 이제 몇 달 후, 필자는 왜 이것이 아주 깨끗한 해결책이 아닌지를 강조한 문제에 마주 쳤습니다. 위에서 언급 한 것처럼 필드 객체는 장치의 구성 필드를 나타냅니다. 이러한 필드가 액세스되는 방식과는 별개입니다.

더 일반적인 용어 : 나의 숨겨진 내부 표현 인 은을 설명하지 않습니다.과 반드시 ​​1 : 1 관계가있는 것은 관련이없는 것으로 을 설명합니다.

필드 액세스를 변경하려는 경우 문제가 될 수 있습니다. 예를 들어 이제 "오류시 다시 시도"액세스 동작을 제공하는 Field 데코레이터 클래스를 만들 수 없습니다. 데코레이터를 사용하는 코드는 실제 기본 필드와 관련이없는 자체 필드로 취급합니다.

이 아니라 원래 질문에 대한 대답 인이 아니라 내 가정이 잘못되었음을 알 수 있습니다. 자신의 내면 묘사가 사물 자체와 1 : 1의 관계를 가지고 있다는 것을 정말로 확신한다면,이 문제는 적용되지 않습니다.

Answer 1

이것은 실제로 라이브러리가 작동하는 방식과 클라이언트 코드가 클라이언트 코드와 상호 작용하는 방식에 따라 다릅니다. 내부 표현을 클라이언트에 표시 할 때 발생할 수있는 한 가지 문제점은 잠재적으로 클라이언트 코드를 손상시키지 않으면 서 내부 표현을 변경할 수있는 유연성이 없다는 것입니다. 그러나 내부적으로 다른 표현이 필요한 시점에 새로운 내부 표현을 만들고 공개 API의 일부로 이전 표현을 남길 수 있기 때문에 극복하기가 너무 어렵다고 생각하지 않습니다. .

공개 API의 일부로 내부 표현을 노출하기로 결정한 경우 의도하지 않은 부작용을주의해야합니다. 예를 들어 클라이언트 코드가 객체를 전달한 다음 해당 객체를 내부적으로 저장한다고 가정 해 보겠습니다. C#에서는 개체가 참조로 전달되므로 해당 개체에 대한 수정 사항은 내부적으로 저장되는 개체에도 발생합니다. 물론이 문제가 발생하지 않도록 개체의 복사본을 만들 수 있습니다.

마지막으로, 아직 보지 않았다면 클라이언트 관점에서 공개 API를 고려할 수 있습니다. 아마 일부 단위 테스트에서 그것을 사용 해보십시오. 내부 표현이 클라이언트 관점에서 표현하는 가장 좋은 방법은 아님을 알 수 있습니다.

매우 간단한 API의 경우 내부 구조를 사용하는 것이 좋습니다. 나는 항상 다른 방향을 기대는 경향이 있으며 내부 API와 내부 API를 구분하는 추상화와 격리를 선택합니다.

이것은 모두 상충 관계에 관한 것이고 달성하려는 대상에 따라 달라집니다. 바라기를 이것은 당신의 결정을 조금 도울 것입니다.