어느 것이 더 낫습니다 : getters 또는 선택 문자열 매개 변수가있는 1 개의 메소드?


15

우리의 지식 영역은 맨발로 압력판을 걷는 사람들과 관련이 있습니다. 센서 데이터에서 사람의 발이 인식되면 '발'클래스의 물체를 만드는 이미지 인식을 수행합니다.

발 데이터에 대해 몇 가지 계산을 수행해야합니다.

이제 어떤 API가 더 좋을까요?

class Foot : public RecognizedObject  { 
  MaxPressureFrame getMaxPressureFrame();
  FootAxis getFootAxis();
  AnatomicalZones getAnatomicalZones();

  // + similar getters for other calculations

  // ...
}

또는:

class Foot : public RecognizedObject {
  virtual CalculationBase getCalculation(QString aName);

  // ...
}

지금, 내가 생각해 낼 수있는 많은 장단점이 있지만, 어느 것이 가장 중요한지를 결정할 수는 없습니다. 이것은 우리가 판매하는 소프트웨어 라이브러리가 아닌 최종 사용자 응용 프로그램입니다.

어떤 충고?

첫 번째 접근 방식의 일부 전문가는 다음과 같습니다.

  • 키스-모든 것이 매우 구체적입니다. API이지만 구현도 마찬가지입니다.
  • 강력한 형식의 반환 값
  • 이 클래스에서 상속하는 것은 바보입니다. 재정의 할 수 없으며 추가 만 할 수 있습니다.
  • API는 매우 닫히고 아무것도 들어 가지 않으며 재정의 할 수 없으므로 잘못 될 수 있습니다.

일부 단점 :

  • 우리가 발명 한 모든 새로운 계산이 목록에 추가됨에 따라 게터의 수가 늘어날 것입니다.
  • API가 변경 될 가능성이 더 높으며 주요 변경 사항이 도입되면 새로운 API 버전 인 Foot2가 필요합니다.
  • 다른 프로젝트에서 클래스를 재사용하는 경우 모든 계산이 필요하지 않을 수 있습니다

두 번째 접근 방식의 일부 전문가 :

  • 더 유연한
  • api는 변경 될 가능성이 적습니다.

일부 단점 :

  • 느슨하게 입력했습니다. 모든 통화에 캐스트가 필요합니다.
  • 문자열 매개 변수-그것에 대해 나쁜 감정을 가지고 있습니다 (문자열 값에서 분기 ...)
  • 추가 유연성을 요구하는 현재 사용 사례 / 요구 사항은 없지만 앞으로있을 수 있습니다.
  • API는 제한 사항을 부과합니다. 모든 계산은 기본 클래스에서 파생되어야합니다. 이 1 가지 방법을 통해 계산을 수행해야하며, 매개 변수를 전달하는 훨씬 더 역동적이고 초 유연한 방법을 고안하지 않으면 추가 매개 변수를 전달하는 것이 불가능합니다.

5
enum값을 만들고 켤 수 있습니다. 그래도 두 번째 옵션은 KISS에서 벗어나기 때문에 악하다고 생각합니다.
Vorac

문자열 매개 변수를 사용하여 트리거하는 경우 특정 계산의 모든 사용법을 찾기가 더 어렵습니다. 100 %가 되기는 어렵습니다.
Konrad Morawski

두 세계를 최대한 활용하고 여러 게터가 불러 들인 파사드를 쓰세요 getCalculation().
nalply

1
열거 형은 문자열보다 확실히 좋습니다! 나는 이것을 생각하지 않았다. API를 제한하고 문자열 매개 변수의 남용을 방지합니다 (토큰의 연결 및 기타 쓰레기와 같은). 문자열 대신 열거 형을 사용하여 옵션 1과 옵션 2를 비교하는 것으로 생각합니다.
Bgie

답변:


6

나는 첫 번째 접근법에서 돈을 지불 할 것이라고 생각합니다. 마술 문자열은 다음과 같은 문제를 일으킬 수 있습니다. 입력 오류, 오용, 사소한 반환 유형 안전, 코드 완성 부족, 불분명 한 코드 (이 버전에 해당 기능이 있습니까? 런타임에 알게 될 것입니다). 열거 형을 사용하면 이러한 문제 중 일부가 해결되지만 제기 한 단점을 살펴 보겠습니다.

  • 우리가 발명 한 모든 새로운 계산이 목록에 추가됨에 따라 게터의 수가 늘어날 것입니다.

사실, 그것은 성가 시게 할 수 있지만, 일을 멋지고 엄격하게 유지하고 최신 IDE에서 프로젝트의 어느 곳에서나 코드 완성을 제공하며 열거 형보다 훨씬 유용한 제목 주석이 있습니다.

  • API가 변경 될 가능성이 더 높으며 주요 변경 사항이 도입되면 새로운 API 버전 인 Foot2가 필요합니다.

사실, 그것은 실제로 거대한 프로입니다.) 부분 API에 대한 인터페이스를 정의 할 수 있으며 최신 API의 영향을받지 않는 종속 클래스를 다시 컴파일 할 필요가 없습니다 (Foot2가 필요 없음). 이를 통해 더 나은 분리가 가능해지며, 종속성은 이제 구현이 아니라 인터페이스에 있습니다. 또한 기존 인터페이스가 변경되면 종속 클래스에서 컴파일 오류가 발생하여 오래된 코드를 방지하는 데 좋습니다.

  • 다른 프로젝트에서 클래스를 재사용하는 경우 모든 계산이 필요하지 않을 수 있습니다

마법의 문자열이나 열거 형을 사용하는 것이 어떻게 도움이되는지 모르겠습니다 ... 올바르게 이해하면 Foot 클래스에 코드를 포함 시키거나 몇 개의 작은 클래스로 나누면 두 옵션 모두에 해당됩니다.


인터페이스가있는 부분 API 아이디어가 마음에 듭니다. 미래 보장됩니다. 나는 그것으로 갈 것이다. 감사합니다. 너무 복잡해지면 (발이 너무 많은 인터페이스를 구현하는 경우) 여러 개의 작은 어댑터 클래스를 사용하는 것이 훨씬 더 유연합니다. 발, humanfoot, dogfoot, humanfootVersion2와 같이 서로 다른 api로 여러 발의 변형이 존재하는 경우 작은 어댑터가있을 수 있습니다 하나의 GUI 위젯이 모든 GUI 위젯과 함께 작동하도록하기 위해 ...
Bgie

명령 선택기를 사용하면 인터페이스와 함께 제공된 정적 도우미 메서드 호출을 이해하지 못하는 명령을 수신하는 구현을 가질 수 있다는 장점이 있습니다. 명령이 범용 접근법을 사용하여 거의 모든 구현으로 수행 할 수 있지만 일부 구현이 더 나은 방법을 통해 수행 할 수있는 것을 나타내는 경우 [예 : 고려 IEnumerable<T>.Count], 이러한 접근법은 코드가 새로운 기능의 성능 이점을 누릴 수있게합니다. 인터페이스 기능은이를 지원하는 구현을 사용하지만 이전 구현과 호환됩니다.
supercat

12

옵션 3을 권장합니다. 계산은 추상화의 본질적인 부분이 Foot아니라 작동합니다. 그런 다음 Foot계산을 다음 과 같이 별도의 클래스로 나눌 수 있습니다 .

class Foot : public RecognizedObject {
public:
    // Rather low-level API to access all characteristics that might be needed by a calculation
};

class MaxPressureFrame {
public:
    MaxPressureFrame(const Foot& aFoot); // Performs the calculation based on the information in aFoot
    //API for accessing the results of the calculation
};

// Similar classes for other calculations

이 방법으로 계산을 강력하게 입력 할 수 있으며에 노출되는 정보의 양에 심각한 오류가없는 한 기존 코드에 영향을주지 않고 새로운 계산을 추가 할 수 있습니다 Foot.


옵션 1과 2보다 확실히 더 좋습니다. 이것은 전략 디자인 패턴을 사용하는 것에서 아주 가까운 단계입니다.
Brian

4
이것은 적절할 수 있습니다. 이것은 과잉 일 수 있습니다. 계산이 얼마나 복잡한 지에 따라 다릅니다. MaxPressureFrameStrategy와 MaxPressureFrameStrategyFactory를 추가 하시겠습니까? 그리고 발을 빈혈로 바꾸는 경향이 있습니다.
user949300

이것이 좋은 대안이지만 의존성을 뒤집는 것은 우리의 경우에는 효과가 없습니다. 발은 또한 매개 변수를 변경하는 등의 이유로 인해 다른 계산이 변경된 경우 일부 계산을 다시 계산해야하므로 일종의 중재자 역할을해야합니다.
Bgie

@Bgie : 계산과 같은 의존성으로, 나는 @ user116462 첫 번째 옵션은 best.` 것을 동의
바트 반 Ingen Schenau
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.