Hangisi daha iyi: bir dizi alıcı veya seçim dizesi parametresi ile 1 yöntem?

Bilgi alanımız, çıplak ayaklarıyla bir baskı plakası üzerinde yürüyen insanları içerir. Sensör verilerinde bir insan ayağı tanınırsa, 'Foot' sınıfı nesnelerle sonuçlanan görüntü tanıma yaparız.

Ayağın verilerinde yapılması gereken birkaç hesaplama vardır.

Şimdi, hangi API daha iyi olurdu:

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

  // + similar getters for other calculations

  // ...
}

Veya:

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

  // ...
}

Şimdi, gelebileceğim birçok profesyonel ve con var, ama hangisinin en önemli olduğuna gerçekten karar veremiyorum. Bu sattığımız bir yazılım kütüphanesi değil, bir son kullanıcı uygulamasıdır.

Herhangi bir tavsiye?

İlk yaklaşım için bazı profesyoneller şunlar olabilir:

• ÖPÜCÜK - her şey çok somut. API, ancak uygulama.
• güçlü yazılan dönüş değerleri.
• bu sınıftan miras kalmayacak bir şey yoktur. Hiçbir şey geçersiz kılınamaz, sadece eklenebilir.
• API çok kapalı, hiçbir şey girmiyor, hiçbir şey geçersiz kılınamıyor, bu yüzden daha az yanlış gidebilir.

Bazı con's:

• Her yeni hesaplama listeye eklendiğinde, alıcı sayısı artacaktır
• API'nın değişme olasılığı daha yüksektir ve son değişikliklerin getirilmesi durumunda yeni bir API sürümüne, Foot2'ye ihtiyacımız vardır.
• sınıfın başka projelerde tekrar kullanılması durumunda her hesaplamaya ihtiyacımız olmayabilir

İkinci yaklaşım için bazı profesyoneller:

• daha esnek
• API'nin değişme olasılığı daha düşüktür (soyutlamayı doğru yaptığımızı varsayarsak, değiştirmenin maliyeti daha yüksektir)

Bazı con's:

• gevşek yazmış. Her çağrıda alınıyor.
• dize parametresi - Bu konuda kötü duygular var (dize değerlerinde dallanma ...)
• Ekstra esnekliği zorunlu kılan mevcut kullanım durumu / gereksinimi yoktur, ancak gelecekte olabilir.
• API kısıtlamalar getirir: her hesaplamanın bir temel sınıftan türetilmesi gerekir. Bu 1 yöntemle bir hesaplama yapmak zorlanacak ve karmaşıklığı daha da artıran parametreleri daha dinamik, süper esnek bir şekilde tasarlamadığımız sürece ekstra parametrelerin geçirilmesi imkansız olacaktır.

İlk yaklaşımda işe yarayacağını düşünüyorum. Sihirli dizeler aşağıdaki sorunları oluşturabilir: Yazma hataları, yanlış kullanım, önemsiz olmayan dönüş tipi güvenlik, kod tamamlanma eksikliği, net olmayan kod (bu sürümde bu özellik var mıydı? Sanırım çalışma zamanında bulacağız). Numaralandırma kullanmak bu sorunlardan bazılarını çözecektir, ancak ortaya koyduğunuz eksileri inceleyelim:

• Her yeni hesaplama listeye eklendiğinde, alıcı sayısı artacaktır

Doğru, bu can sıkıcı olabilir, ancak işleri güzel ve sıkı tutar ve herhangi bir modern IDE'de projenizin herhangi bir yerinde kod tamamlama sağlar, numaralandırmalardan çok daha yararlı olan iyi başlık yorumlarıyla.

• API'nın değişme olasılığı daha yüksektir ve son değişikliklerin getirilmesi durumunda yeni bir API sürümüne, Foot2'ye ihtiyacımız vardır.

Doğru, ama bu aslında büyük bir profesyonel;) kısmi API'ler için arayüzler tanımlayabilirsiniz ve daha sonra yeni API'lardan etkilenmeyen bağımlı sınıfı yeniden derlemenize gerek yoktur (Yani Foot2'ye gerek yoktur). Bu daha iyi ayrıştırmaya izin verir, bağımlılık artık uygulama değil arayüzdür. Dahası, mevcut bir arayüz değişirse, bağımlı sınıflarda derleme hatası alırsınız;

• sınıfın başka projelerde tekrar kullanılması durumunda her hesaplamaya ihtiyacımız olmayabilir

Sihirli dizeleri veya numaralandırmaları kullanmanın bu konuda nasıl yardımcı olacağını görmüyorum ... Doğru anlarsam, ya Foot sınıfına kodu eklersiniz ya da birkaç küçük sınıfa ayırırsınız ve bu her iki seçenek için de geçerlidir

Seçenek 3'ü tavsiye ederim: Hesaplamaların a'nın soyutlamasının gerçek bir parçası olmadığını Foot, ancak üzerinde çalıştığını açıkça belirtin . Ardından Footve hesaplamaları şu gibi ayrı sınıflara ayırabilirsiniz:

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

Bu şekilde, hesaplamanıza hala güçlü bir şekilde yazabilirsiniz ve mevcut kodu etkilemeden yenilerini ekleyebilirsiniz (maruz kalan miktar bilgisinde ciddi bir hata yapmadıysanız Foot).