커플 링 정도 결정

Question

API가 약 10 가지의 기능으로 노출 된 컴포넌트가 있습니다. 나는 그것을 달성하는 두 가지 방법을 생각할 수 있습니다 :

1. 이 모든 기능을 별도의 기능으로 제공하십시오.

2. XML을 입력으로 사용하는 함수를 하나만 나타냅니다. 지정된 request_Type과 XML에 전달 된 매개 변수에 따라 내부적으로 각각의 함수 중 하나를 호출합니다.

Q1. 두 번째 디자인이 첫 번째 디자인보다 느슨하게 결합됩니까?

필자는 느슨하게 연결되도록 구성 요소를 테스트해야하는 방법에 대해 항상 읽었으며, 실제로 연결을 잃을 정도까지이 정도까지 이동해야합니까?

2. 이들 중 어느 것이 OOP 측면에서 더 좋은 디자인이 될 것이며 그 이유는 무엇입니까?

---

편집 :

나는 다른 사람에 대한 D-버스를 통해이 API 고려는 두 가지 접근 방식을 비교하는, 아직 확인 입력합니다 사용을 노출하고 있다면? 내가 타입 검사가 컴파일 시간에 수행된다는 것을 이해하지만이 함수가 일부 IPC에 노출 된 경우 유형 검사 문제가 발생합니다.

Answer 1

두 가지 대안은 API에서 제공하려는 (분명히 상당히 많은) "기능"에서 다르지 않습니다. 그러나 두 번째는 많은 단점을 가지고있는 것으로 보입니다. 강력한 형식 검사를 잃어 버리면 기능을 문서화하는 것이 훨씬 더 어려워 질 것입니다 (기능을 추가하면 API를 변경할 필요가 없다는 단점이 있습니다.) . 그러나 사용자가 런타임까지 삭제 기능 등의 API 변경 사항을 알아낼 수 없습니다 단점.) 더 많은이 질문과 관련이 무엇

는 싱글 의무 일 원리 (http://en.wikipedia.org/wiki/Single_responsibility_principle)입니다. OOP에 대해 이야기 할 때, 한 클래스 내에서 수십 개의 함수를 노출시키지 말고 하나의 책임으로 각각 다른 클래스로 나누어야합니다. 좋은 "책임"과 역할을 정의하는 것은 약간의 연습이 필요하지만, 몇 가지 기본 지침을 따르면 신속하게 시작할 수 있습니다. 좋은 출발점은 Are there any rules for OOP?을 참조하십시오.

---

질문 편집 나는 D-버스를 사용하지 않은

에 회신, 그래서 이것은 완전히 잘못 될 수 있습니다. 그러나 tutorial에서 간략히 살펴본 결과

각 개체는 하나 이상의 인터페이스를 지원합니다. 인터페이스를 GLib 또는 Qt 또는 Java Java에있는 메소드 및 신호의 명명 된 그룹으로 생각하십시오. 인터페이스는 객체 인스턴스의 유형을 정의합니다.

DBus는 간단한 네임 스페이스로 된 인터페이스 (예 : , org.freedesktop.Introspectable)를 식별합니다. 대부분의 바인딩은 이러한 인터페이스 이름을 적절한 프로그래밍 언어 구조 (예 : Java 인터페이스 또는 C++ 순수 가상 클래스)에 직접 매핑합니다.

내가 아는 한, D-Bus에는 여러 가지 방법으로 구성된 인터페이스를 제공하는 differnt 개체 개념이 있습니다. 이것은 (내게) 위의 대답이 여전히 적용된다는 것을 의미합니다. API를 지정하는 "D-Bus native"방식은 인터페이스를 표시하는 것을 의미 할 것이며 좋은 OOP 디자인 지침이 유효하지 않아야하는 이유는 여기에 표시되지 않습니다. D-Bus가 이들을 심지어 모국어 구조에 매핑하는 것처럼 보이기 때문에 이것은 더욱 가능성이 높습니다.

물론 아무도 자신 만의 API 기술 언어를 XML로 작성하지 못하게합니다. 그러나 기본적인 기술을 악용하는 것과 같은 것이 있습니다. 그런 일을하는 데는 충분한 이유가 있어야합니다.