다른 라이브러리에 종속 된 인터페이스를 정의하는 라이브러리를 작성하는 것은 나쁜 습관입니까?.NET 네임 스페이스를 사용하는 라이브러리를 만드는 데 유용한 모범 사례
꽉 끼는 커플 링이 좋지 않지만 .NET 클래스를 사용할 때 여전히 적용 되는가?
예를 들어, .NET에서 Color 개체를 반환하는 라이브러리가 있으면 내 라이브러리를 사용하는 모든 시스템에서 System.Drawing에 대한 종속성이 강요됩니다. 내 라이브러리에 내 자신의 Color-type 클래스를 만드는 것이 더 낫지 않습니까?
나는 Volatile 및 안정 종속성 구분합니다.
일반적으로 Color는 BCL에 이미 있기 때문에 Stable Dependency처럼 보이며 본질적으로 결정적이며 리소스 집약적 인 Out-of Process 통신을 포함하지 않으며 특정 설정에 의존하지 않습니다 그 런타임 환경의.
유일한 고려 사항은 Color와 관련하여 BCL에 두 개 이상의 클래스가 있으므로 WPF에 자체 정의가 있으므로 Windows Forms 응용 프로그램 만 API로 지정한다는 것입니다. 색깔.
특정 색상으로 UI의 일부분을 페인트하는 데 Color가 필요한 경우 기본 제공 Color 클래스가 좋을 수도 있지만 Color가 도메인 모델의 주요 개념이고 다른 색상으로 타겟팅해야하는 경우 UI (WPF, Windows Forms, Web)를 사용하면 자신 만의 추상화를 정의하는 것이 좋습니다.
그런 고급형의 경우, 추상화를 중심으로 어댑터와 매퍼를 만들어 추상화 클래스와 구체적인 Color 클래스 사이의 간격을 좁힐 수 있습니다.
휘발성 의존성에 대한 우수한 링크 및 일반적으로 훌륭한 대답. +1! – Randolpho
이 정보를 주셔서 감사합니다. 고려하지 않은 문제에 대한 조언이 가득 찼습니다. 나는 어느 시점에서 WinForms에서 벗어나고 싶다. – DanDan
나는이 충고를 좋아한다. 내 수업에서 의존성을 배제하고 Gus (Gus Principle)의 게시물과 결합하여 일반적인 충고는 "내 자신을 굴려 라."라고 생각한다. 이 과정은 Color 클래스가 사소하기 때문에 가장 효과적입니다. Randolpho가 언급 한 것처럼 타사 종속성이있는 더 복잡한 상황에서이 원칙은 구부러 지거나 디자인이 어떻게 든 다시 생각해야 할 수도 있습니다. 귀하의 게시물 주셔서 감사합니다! – DanDan
표준 .NET 라이브러리라면 걱정하지 않아도됩니다. 한 클래스에서 다른 클래스로 매핑 할 이유가 없습니다. 다음 .NET 릴리스에서 System.Color가 변경되면 어떻게 될까요? 매핑 코드도 변경해야하며 버전 및지도를 적절히 감지해야합니다. 그것은 진짜 고통입니다.
BCL 코드는 버전간에 변경되지 않는 경향이 있지만 다른 한편으로는 새로운 Color 유형이 나타날 수 있습니다. System.Drawing.Color에 의존하면 WPF에서 API를 사용하지 못하게됩니다. –
조언 주셔서 감사합니다. – DanDan
내 모든 라이브러리에서 라이브러리의 내용에만 의존하는 객체를 반환합니다.
암묵적이지 않은 다른 네임 스페이스에 의존하는 라이브러리를 작성한 이유는 스스로에게 묻습니다. 그것은 전체 "캡슐화"개념에 어긋나는 것으로 보인다.
그래서 OOP에 대한 내 자신의 추론과 지식을 통해 자신의 비 종속적 인 객체를 반환하는 것이 올바른 방향이라고 말할 수 있습니다.
mscorlib에서 네임 스페이스를 사용하는 것이 허용됩니다. 그 외에는 원리가 건전합니다. –
나는 당신의 원칙도 좋아합니다. 나는 그것을 따라갈 것입니다. – DanDan
당신은 훌륭한 질문을 던집니다. 대답은 다릅니다. 항상 사용할 수있는 표준 라이브러리의 경우에는 괜찮습니다. 코어 라이브러리는 항상 다른 .DLL을 참조합니다.
제 3 자 라이브러리의 경우 문제가 발생합니다. 원하는 것이 무엇이든 다른 것이 있으면 사용자를 굴리는 것이 항상 좋은 생각은 아니지만 다른 라이브러리에 의존하는 것은 사용자에게 물적 문제입니다.
여기에 맞는 대답은 없습니다. 프로젝트에 가장 적합한 것을 선택해야합니다. 가능한 한 감 결합을 시도하십시오. 그렇지만 때로는 꼭 포옹을하고 일을 끝내야합니다.
Hehe, 나는 "너는 단지 껴안고 일을 끝내야한다"라는 말을 좋아한다. 나는이 경우 Color 클래스의 상대적인 사소함 때문에 내 자신을 굴리는 것이 더 나을 것이라고 생각한다. 더 복잡한 경우에는 두통이 생길 것입니다. – DanDan
클래스 사용에 따라 다릅니다.
Color 클래스의 인스턴스에서 시스템 Color 인스턴스를 가져와야하는 경우 (예 : Windows 양식을 그리는 경우) System 클래스를 사용하는 것이 좋습니다. Color 클래스의 모든 "Features"(예 : "Red", "Black", "Green"등의 상수)를 무료로 사용할 수있는 이점을 제공합니다. ..
한편 과학적 계산을 위해 임의의 RGB 값으로 작업하는 경우 결코이 System.Color의 인스턴스로 변환해야하는 경우 자신의 클래스를 만드는 것이 좋습니다
당신은 System.Color 클래스를 사용하는 것이 더 낫습니다. 예 캡슐화와 모든 것이 좋은 생각이지만, 막대한 시간을 절약 할 필요는 없습니다!
나는 내장 상수가 필요 없을 것이라고 99 % 확신한다. 그래서이 경우에 나는 내 자신을 굴리는 것이 낫다. 귀하의 조언에 감사드립니다. – DanDan
.NET 코어 라이브러리에서 아무 것도 사용하지 않아도됩니다. 그것없이 DLL을 작성하는 것은 그리 멀지 않을 것입니다. 주위에 조심해야 할 유일한 곳은 System.Web 네임 스페이스입니다. .NET 4에는 클라이언트 프로파일 설치 프로그램이 있습니다. 기본적으로이 설치 프로그램을 사용하면 클라이언트에서 사용할 것으로 예상되는 프로그램 만 설치됩니다. 저는 개인적으로 마이크로 소프트 사의 부분에 대해 나쁜 생각이라고 생각합니다. 소량의 다운로드 시간을 절약하기 위해 불필요한 복잡성을 추가하기 때문입니다.
경고를 보내 주셔서 감사합니다. – DanDan
좋은 질문입니다. . –