Bir numarada özel bir “ALL” değerine sahip olmak iyi bir uygulama mı

Bir mikro hizmetler ortamında yeni bir hizmet geliştiriyorum. Bu bir REST hizmetidir. Basit olması için, yolun: / historyBooks olduğunu varsayalım.

Ve bu yol için POST yöntemi yeni bir tarih kitabı oluşturur.

Bir tarih kitabının tarihte bir veya daha fazla dönemi kapsadığını varsayalım.

Kısacası, insanlık tarihinin sadece aşağıdaki dönemlerine sahip olduğumuzu varsayalım:

• Antik
• Post Klasik
• Modern

Kodumda, onları bir enum.

Yöntemin gövdesi (faydalı yük) JSON biçimindedir ve bir alan adı içermelidir eras. Bu alan, erabu kitabın kapsadığı değerlerin bir listesidir .

Vücut şöyle görünebilir:

{
  "name": "From the cave to Einstein - a brief history review",
  "author": "Foo Bar",
  "eras": ["Ancient", "Post Classical", "Modern"]
}

Bu özel hizmette iş mantığı şöyledir:
Girdide herhangi bir dönem belirtilmemişse, bu kitabın tüm dönemleri kapsadığı kabul edilir .

API incelemesinde bir öneride bulunuldu:
Dönemlerin sıralaması ALLiçin tüm dönemlerin açık olduğunu açıkça belirtmek üzere başka bir değer ekleyin .

Bence bazı artıları ve eksileri var.

Artıları:

Açık girdi

Eksileri:

Listede iki öğe varsa, deyin ALLve Ancient- uygulamadan ne alınacaktır? Sanırım bu ALLdiğer değerleri geçersiz kılmalı, ama bu yeni iş mantığı.

Bir sorgu çalıştırırsam, belirli dönemleri kapsayan kitaplar için tüm dönemleri kapsayan kitapları nasıl temsil ederim? Eğer ALL(aynı mantığı kullanarak) çıkışı için kullanılır, o zaman yorumlamak tüketicinin sorumluluğunda ALLolarak ["Ancient", "Post Classical", "Modern"].

Benim sorum

Yeni ALLolana sahip olmanın, hiç sahip olmamaya göre daha fazla karışıklığa neden olduğunu düşünüyorum .

Ne düşünüyorsun? Bu ALLdeğeri ekler misiniz veya API'nızı onsuz tutar mısınız?

Kullanılabilir dönemlerinizin arama uygulaması tarafından kullanılabilir olup olmadığına bağlıdır. Muhtemelen, kullanıcı ilgilendikleri şeyi seçebilmeleri içindir. Bu durumda, bir "TÜM" seçeneği sağlamak bir ön uç sorunudur. Eğer ben olsaydım, "hepsi" seçeneği yerine tüm dönemlerin bir listesini göndermesini isterdi. Değilse, o zaman bir "TÜM" seçeneğe ihtiyacınız var ve o zaman ön uç şeyleri anlamayacağı bir döneme geri almak riskini çalıştırın.

İşaret ettiğiniz gibi, TÜM diğer seçeneklerle çakışan istekler alabileceğiniz anlamına gelir. Bir diğer husus, "TÜMÜ" 'nü geçebilmenizdir, daha sonra diğer tüm numaralandırmalar kapanımlar yerine hariç tutulur, örneğin "TÜMÜ", "Eski", "Eskiler hariç her şey" anlamına gelir. Bu bir tür mantıklıdır, ancak açık bir şekilde UI, sadece aşırı karmaşık olabilecekleri yansıtmalıdır.

TL; DR; Çoğunlukla "TÜM" bir UI nicety olduğunu ve aynı şeyi hiçbir belirsizlik olmadan hizmet düzeyinde elde edebilirsiniz, bu yüzden bunu yapmayın.

Girişte herhangi bir dönem belirtilmemişse, bu kitabın tüm dönemleri kapsadığı kabul edilir.

Bu ve aynı zamanda özel bir 'TÜM' durumunun olması kötü IMHO'dur - API'larınız mümkün olduğunda açık olmalıdır. 'Hiçbir şey aslında her şey anlamına gelmez' gibi özel durumlara sahip olmak, API'nızı tüketen herkesin tüm özel durumlarınızı da bilmesi gerektiği anlamına gelir veya 'TÜMÜ' durumunda olduğu gibi, niyetin ve / veya sonucun belirsiz olduğu taleplere yol açar.

Özel durumlar, hem kullanıcı girişinin geçerli olup olmadığını doğrulama hem de isteği doğru bir şekilde ele alma açısından genellikle daha karmaşık bir koda yol açar.

Kategorik değişkenler için, joker karakteri "all" olarak aynı düzeye koymaktan kaçınırım.

Zaman aralığı için iki düzeyli bir arama ölçütünüz var gibi görünüyor:

1. boolean, is_selective?
2. belirli kategorilerin belirlenmesi, ayrılması

Arayan (yanlış, yoksayılmış) veya (doğru, {'eski', 'modern'}) belirtebilir.

Veya boş kümesi joker karakter olarak yorumlamayı seçebilirsiniz, Seçici Değil anlamına gelir.

Özel durumunuz için, birkaç iyi bilinen değere bağlı olan sürekli bir değişkeniniz, yılınız gibi görünüyor ve gerçekten istediğiniz şey aralık aritmetiği yapmaktır. Böylece sorgularınız bir (başlangıç, bitiş) yıl aralığını kabul eder ve numaralandırmalar bu tür özellikleri uygun bir şekilde sağlayabilir.

tl; dr
Gerçek sorunuz için - uygulamadaki yerel veri yapıları ile ilgili - Sonuç olarak katılıyorum: Tüm dönemlerin özel değerlerinden kaçının çünkü çoğunlukla karmaşıklık ve hata yapma fırsatları ekler. Bununla birlikte, özellikle son kullanıcı arayüzü ve belki de serileştirilmiş taşıma yükü verileri farklı hikayeler olabilir.

Yerel veri yapıları

Buna bir tür sistem perspektifinden bakalım. Temel olarak bir numaralandırma, @JH'nin cevabında belirtildiği gibi, belirli bir kategorileri (numaralandırıcılar) tanımlayan bir türdür . Enum türünün bir değişkeni bu kategorilerden birini içerir. Numaralandırıcı değerlerinin bir koleksiyonunu temsil etmek istiyorsanız, ikinci bir türe ihtiyacınız vardır:

// C++-inspired pseudo-code
enum Era { ancient, post_classical, modern };
using Eras = Collection<Era>;

Bir allnumaralandırıcı hareketsizdir çünkü bu iki türü bir araya getirir. Tek bir kategori değil, tüm olası kategorilerin bir koleksiyonudur.

Her türlü özel değerle uğraşmak kesinlikle pratik bir düzeyde uygulamayı zorlaştırır - ve böylece hata olasılığını artırır - çünkü ya her yerde özel olarak ele almanız veya gerçek anlamıyla eşleşmesi için onu açmanız gerekir. Oh, ve olası tüm numaralandırıcıların açık bir koleksiyonuna ne dersiniz? Bu ne zaman ve nerede özel alldeğere daraltılmalı ? Hiç çökmeli mi?

Tercih ettiğim mimaride koddaki tüm dönemlerin herhangi bir temsili olmamalıdır . Bu allnumaralandırıcıyı içerir , aynı zamanda tüm dönemleri ifade eden boş bir koleksiyon da içerir . Tam olarak aynı özel durum, sadece farklı bir kılık değiştirmiş.

Listede iki öğe varsa, ALL ve Ancient deyin - uygulamadan ne alınır? [...]

API spesifikasyonunda, tüm çağlar işaretleyicisinin her zaman kendi başına görünmesi gerektiğini belirttim, çünkü bunun üzerine bir şey olması mantıklı değil. Sonra bunu bir sözleşme ihlali olarak reddederim. Ancak, tüm çağların hem uygulamayı hem de iş mantığını nasıl karmaşıklaştırdığının güzel bir örneği .

Ana sorun, özel değer ve altında yatan anlam arasında dönüştürme için kurallar belirtmeniz gerektiğidir. Ve sonra siz ve API'yi kullanan herkes bu kuralları doğru bir şekilde uygulamalısınız. İçimde kinik bir sorusu olmadığını söylüyor eğer birisi yanlış alacak, ancak sadece zaman .

Seri Veri (JSON)

Başlangıçta, burada salt okunur sorguları ve "eras"liste için farklı rolleri değiştirmekle ilgili bir bölümüm vardı . Ama sonunda onu sildim çünkü KISS. Numaralandırma / toplama kuralları JSON verileri için mantıksız değildir, bu nedenle işleri tutarlı tutmak en basit çözümdür.

Son kullanıcı için kullanıcı arayüzü

Büyük olasılıkla bir çeşit MVC-ish mimarisine sahip olduğunuz için, kullanıcı arayüzü ve temeldeki veri yapıları arasında bir veri dönüşümü olacağını varsayalım. Bu nedenle, kullanıcı için en uygun ve sezgisel olanı kullanın. Gelen onun cevabını @Markus haftanın günleri için farklı seçim seçenekleri ile büyük bir örnek verdi.

Yeni ALL'ye sahip olmanın, hiç olmamasından daha fazla karışıklığa neden olduğunu düşünüyorum.

Evet.

Bir koleksiyon perspektifinden düşünüyorsanız: bir şey koleksiyonunuz var. Ve bu koleksiyonun yalnızca bir alt kümesini her istediğinizde , bir öğe bu alt kümenin bir öğesi olarak kabul edildiğinde, bir tür filtre koşulu sağlamanız gerekir . Ve ALLhiçbir filtre uygulanmadığında, "ALL filtre koşulu " değil .

Girişte herhangi bir dönem belirtilmemişse, bu kitabın tüm dönemleri kapsadığı kabul edilir.

Baş aşağı çevirirdim: Bu kitap belirli bir dönemi kapsamıyor.

Bu aynı zamanda sorgu açısından da tutarlıdır:

Hiçbir dönem seçilmezse, tüm kitaplar döndürülür (boş bir dönem alanı da dahil olmak üzere); ve bir dönem seçildiğinde, yalnızca seçilen döneme sahip kitaplar iade edilir - özel bir döneme ait tüm kitapları ve genel olanları almak bir şekilde beklenmedik olur.

ALL- kategorisini ekleyeceğim tek nokta, kullanıcının rahatlığı içindir, çünkü "Her şey" yerine "Hiçbir şey" seçilmeden daha rahatsız edici olabilir.

Son zamanlarda temel bir zamanlayıcı uyguladım ve @LoztInSpace'in daha önce de belirtildiği gibi çoğu UI şekeri.

Kullanıcı arabirimi, seçeneklerden birini seçerken kullanıcının ne elde edeceği konusunda kesinlikle net olmalıdır.

Benim durumumda seçeceğim hafta içi günler var. "Tümü" ne ek olarak "Çalışma günleri" ve "Haftasonu" seçeneklerini de ekledim. Her seçeneğin belirlenmesi, daha sonraki bir kullanımda dahil edilecek ve dahil edilmesini istemediğiniz günlerin seçimini el ile kaldırmanız gerekecektir.

Teknik olarak bu, kullanıcı "Hafta içi" seçeneğini seçerse kullanıcı arayüzünde beş onay kutusunun işaretleneceği ve numaralandırmanın "Çalışma günleri" değerini kullanacağı anlamına gelir. Onay kutularından birinin işareti kaldırılırsa, "Çalışma günleri" değeri, geri kalan dört günün düzenlenmiş bir bit eşlemiyle değiştirilir.

Seçeneklerin bir bölümünü her şeyi açıklamak ve aynı zamanda çakışmaları önlemek ve kullanıcı arayüzünün kullanıcıya mantıklı olmasını sağlamak için bir şeyi hariç tutmak için kullanmayın.

Bence iyi bir yönelim kullanıcı ve "Tüm" ne içerir (bir hafta içinde tüm günler) veya oldukça önemsiz (amazon tüm kategorileri arama) kavramını kolayca kavrayabilir eğer ve "Tümü" seçeneğini kullanarak mantıklı olduğunu düşünüyorum

Açıkça TÜM bir numaralandırma taşıma fikrini seviyorum, ama onları bayrak olarak tercih ederim

const enum = {
    ALL: { value: 0 },
    ANCIENT: { name: 'Ancient', value: 1 },
    POST_CLASSICAL: { name: 'Post Classical', value: 2 },
    MODERN: { name: 'Modern', value: 4 }
}

Tüm değerler seçildiğinde flagon gibi bir kitaplığı kullanarak veya bitsel işlemlerle elle oynatırken bunun yerine TÜMÜ'nü kullanırsınız.

Enum'un değerlerinin her zaman öncüllerinin iki katı olması gerektiğini unutmayın. Ve akıl sağlığı kontrolü için bir enum'u asla çıkarmamalısınız, ancak devre dışı bırakabilirsiniz, kodunuzu her zaman engelli olanları ALL'nin bir parçası olarak sayacak şekilde ayarlayın.

Bunun yerine HİÇBİRİ bayrağı olmayacak ve işin daha sonra değişmesi durumunda NONE kullanıldığında ne yapacağına karar vermesine izin vereceğim.

Bu uygulama alınırsa, enun'ları aktarmak yerine, seçilen değerlerin toplamını geçersiniz.