Java'da sabitleri uygulamanın en iyi yolu nedir? [kapalı]

Bunun gibi örnekler gördüm:

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

ve sabitleri sarmak için bir sabitler sınıfına sahip olabileceğimi varsayalım. Neredeyse hiç Java bilmiyorum ve bunun sabitler oluşturmanın en iyi yolu olup olmadığını merak ediyorum.

Muhtemelen standart bile mükemmel kabul edilebilir.

(public/private) static final TYPE NAME = VALUE;

burada TYPEtür, NAMEboşluklar için alt çizgileri olan tüm büyük harflerin adı VALUEve sabit değerdir;

Sabitlerinizi kendi sınıflarına veya arayüzlerine KOYMAYINIZ.

Bir yan not olarak: Nihai ve değişken olan değişkenler yine de değiştirilebilir; ancak değişken hiçbir zaman farklı bir nesneyi gösteremez.

Örneğin:

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

Bu yasaldır ve ORIGIN(3, 0) 'da bir nokta olacaktır.

Ben tek bir sabit sınıfına karşı şiddetle tavsiye ediyorum. O zaman iyi bir fikir gibi görünebilir, ancak geliştiriciler sabitleri belgelemeyi reddettiğinde ve sınıf, birbiriyle hiç ilgili olmayan (başvurunun tamamen farklı yönleriyle ilişkili) 500 sabitin yukarısını kapsayacak şekilde büyüdüğünde, bu genellikle sabitler dosyası tamamen okunamaz hale gelir. Yerine:

• Java 5+ sürümüne erişiminiz varsa, uygulama alanına özgü sabitlerinizi tanımlamak için enums kullanın. Uygulama alanının tüm bölümleri bu sabitler için sabit değerlere değil numaralandırmalara başvurmalıdır. Bir sınıfı nasıl ilan ettiğinize benzer bir numaralandırma bildirebilirsiniz. Numaralandırmalar, Java 5+ ürününün belki de en kullanışlı (ve tartışmasız) yararlı özelliğidir.
• Yalnızca belirli bir sınıf veya alt sınıflarından biri için geçerli olan sabitleriniz varsa, bunları korumalı veya genel olarak bildirin ve hiyerarşideki en üst sınıfa yerleştirin. Bu şekilde, alt sınıflar bu sabit değerlere erişebilir (ve diğer sınıflar onlara genel olarak erişirse, sabitler yalnızca belirli bir sınıf için geçerli değildir ... yani bu sabiti kullanan dış sınıflar, sabit içeren sınıf)
• Davranış tanımlı bir arabiriminiz varsa, ancak döndürülen değerlerin veya bağımsız değişken değerlerinin özel olması gerekiyorsa, diğer uygulayıcıların bunlara erişebilmesi için bu arabirimdeki sabitleri tanımlamak tamamen kabul edilebilir. Ancak, sadece sabitleri tutmak için bir arayüz oluşturmaktan kaçının: sadece sabitleri tutmak için yaratılmış bir sınıf kadar kötü hale gelebilir.

Sadece sabitleri tutmak için arayüzleri kullanmak kötü bir uygulamadır ( Josh Bloch tarafından sabit arayüz kalıbı olarak adlandırılır ). Josh'un önerileri şunlardır:

Sabitler mevcut bir sınıfa veya arabirime güçlü bir şekilde bağlıysa, bunları sınıfa veya arabirime eklemelisiniz. Örneğin, Tamsayı ve Çift gibi tüm kutulu sayısal ilkel sınıflar MIN_VALUE ve MAX_VALUE sabitlerini dışa aktarır. Sabitler en iyi numaralandırılmış türün üyeleri olarak görüntüleniyorsa, bunları bir enum türüyle dışa aktarmalısınız . Aksi takdirde, sabitleri örneklenemez bir yardımcı sınıfla dışa aktarmalısınız.

Misal:

// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
    private PhysicalConstants() { }  // Prevents instantiation

    public static final double AVOGADROS_NUMBER   = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS      = 9.10938188e-31;
}

Adlandırma kuralı hakkında:

Konvansiyona göre, bu tür alanların alt harflerle ayrılmış sözcüklerle büyük harflerden oluşan isimleri vardır. Bu alanların ya ilkel değerler ya da değişmez nesnelere referanslar içermesi önemlidir.

Etkili Java'da (2. sürüm) sabitler için statik girişler yerine numaralandırmalar kullanmanız önerilir.

Burada Java'da numaralandırmalarda iyi bir yazı var: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Bu makalenin sonunda sorulan sorunun şu olduğuna dikkat edin:

Peki ne zaman numaralandırma kullanmalısınız?

Cevap ile:

Sabit bir sabit kümesine ihtiyacınız olduğunda

Sadece bir arayüz kullanmaktan kaçının:

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

Caziptir, ancak kapsüllemeyi ihlal eder ve sınıf tanımlarının ayrımını bulanıklaştırır.

Aşağıdaki yaklaşımı kullanıyorum:

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

Örneğin, Constants.DB.Connection.URLsabit olmak için kullanıyorum . Bana göre daha "nesne yönelimli" görünüyor.

Ayrı bir sınıfta statik son sabitler oluşturmak başınızı belaya sokabilir. Java derleyicisi bunu gerçekten optimize eder ve sabitin gerçek değerini ona başvuran herhangi bir sınıfa yerleştirir.

Daha sonra 'Sabitler' sınıfını değiştirirseniz ve bu sınıfa başvuran diğer sınıflarda yeniden derleme yapmazsanız, kullanılan eski ve yeni değerlerin bir birleşimi ile tamamlanırsınız.

Bunları sabitler olarak düşünmek yerine, bunları yapılandırma parametreleri olarak düşünün ve bunları yönetmek için bir sınıf oluşturun. Değerlerin kesin olmamasını sağlayın ve hatta alıcıları kullanmayı düşünün. Gelecekte, bu parametrelerin bazılarının gerçekten kullanıcı veya yönetici tarafından yapılandırılabilir olması gerektiğini belirlediğinizde, yapılması çok daha kolay olacaktır.

Yapabileceğiniz bir numaralı hata, Sabitler gibi genel bir adla adlandırılan, genel olarak erişilebilir bir sınıf oluşturmaktır. Bu basitçe çöp ile doludur ve sisteminizin hangi bölümünün bu sabitleri kullandığını bulma yeteneğini kaybedersiniz.

Bunun yerine, sabitler kendilerine "sahip" sınıfa girmelidir. TIMEOUT adlı bir sabitiniz var mı? Muhtemelen Communications () veya Connection () sınıfınıza girmelidir. MAX_BAD_LOGINS_PER_HOUR? Kullanıcıya () gider. Ve bu böyle devam eder.

Diğer sabit kullanım, "sabitler" çalışma zamanında tanımlanabildiği ancak kullanıcı tarafından kolayca değiştirilemediği zaman Java .properties dosyalarıdır. Bunları .jar'larınızda paketleyebilir ve Class resourceLoader ile başvuruda bulunabilirsiniz.

Doğru yol bu.

Genellikle sabitleri vardır değil onlar keşfedilebilir değil, çünkü sınıfların ayrı bir "Sabitleri" tutulduğunu. Sabit, geçerli sınıfla ilgiliyse, bunları orada tutmak bir sonraki geliştiriciye yardımcı olur.

Numaralandırma ne olacak?

Sabitler yerine getters kullanmayı tercih ederim. Bu alıcılar sabit değerler döndürebilir, ör.public int getMaxConnections() {return 10;} , sabite ihtiyaç duyan her şey alıcıdan geçer.

Bunun bir avantajı, programınız sabiti aşarsa - yapılandırılabilir olması gerektiğini bulursanız - alıcının sabiti nasıl döndüreceğini değiştirebilirsiniz.

Diğer faydası, sabiti değiştirmek için onu kullanan her şeyi yeniden derlemeniz gerekmemesidir. Statik bir son alana başvurduğunuzda, bu sabitin değeri, ona başvuran herhangi bir bayt kodunda derlenir.

Arayüz kullanmanın bir yol olmadığını kabul ediyorum. Bu modelden kaçınmanın Bloch'un Etkili Java'sında kendi öğesi (# 18) bile var .

Bloch'un sabit arayüz modeline karşı yaptığı bir argüman, sabitlerin kullanımının bir uygulama detayı olduğudur, ancak bunları kullanmak için bir arayüz uygulamak dışa aktarılan API'nizdeki uygulama detayını ortaya çıkarır.

public|private static final TYPE NAME = VALUE;Desen Sabit bildirme iyi bir yoldur. Şahsen, tüm sabitlerinizi barındırmak için ayrı bir sınıf yapmaktan kaçınmanın daha iyi olduğunu düşünüyorum, ancak kişisel tercih ve stil dışında bunu yapmamak için hiçbir neden görmedim.

Sabitleriniz bir numaralandırma olarak iyi modellenebiliyorsa , 1.5 veya sonraki sürümlerde bulunan numaralandırma yapısını düşünün .

1.5'ten önceki bir sürümü kullanıyorsanız, normal Java sınıflarını kullanarak yine de tipik güvenli numaralandırmaları kaldırabilirsiniz. ( Bununla ilgili daha fazla bilgi için bu siteye bakın ).

Yukarıdaki yorumlara dayanarak, bunun eski moda küresel sabit sınıfı (genel statik son değişkenlere sahip) enum benzeri eşdeğeri aşağıdaki gibi değiştirmek için iyi bir yaklaşım olduğunu düşünüyorum:

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

O zaman onları sevmeye sevk edebilirim:

Constants.StringConstant.DB_HOST

İyi bir nesne yönelimli tasarımın halka açık pek çok sabit içermesi gerekmez. Çoğu sabit, işini yapması gereken sınıfta kapsüllenmelidir.

Buna cevap vermek için belirli bir görüş var. Başlangıç ​​olarak, java sabitleri genel, statik ve son olarak bildirilir. Sebepleri aşağıdadır:

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

Yalnızca arabirimlerin genellikle uygulanması beklenen bir CONSTANTS erişimci / nesne için asla bir arabirim kullanmaz. Bu komik olmaz mıydı:

String myConstant = IMyInterface.CONSTANTX;

Bunun yerine, bazı küçük değiş tokuşlara dayanarak birkaç farklı yoldan birini seçerdim ve bu da neye ihtiyacınız olduğuna bağlıdır:

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe

Java'da sabitleri uygulamanın en iyi yolu nedir?

Gerçekten kaçınmamız gereken bir yaklaşım : sabitleri tanımlamak için arabirimler kullanmak.

Özellikle sabitleri bildirmek için bir arayüz oluşturmak gerçekten en kötü şeydir: arayüzlerin tasarlanma nedenini yener: yöntem (ler) sözleşmesinin tanımlanması.

Belirli bir ihtiyaca yönelik bir arabirim zaten mevcut olsa bile, sabitlerin API'lerin ve istemci sınıflarına sağlanan sözleşmenin bir parçası olmaması gerektiği için, bunların sabitlerinin bildirilmesi gerçekten anlamlı değildir.

Basitleştirmek için genel olarak 4 geçerli yaklaşımımız var .

İle static final String/IntegerKime:

• 1) içeride sabitleri bildiren bir sınıf kullanmak, sadece içeride değil.
• 1 varyant) yalnızca sabitleri bildirmeye adanmış bir sınıf oluşturmak.

İle Java 5 enum:

• 2) sayımı ilgili bir amaç sınıfında (iç içe bir sınıf gibi) bildirmek.
• 2 varyant) enum'u bağımsız bir sınıf olarak oluşturmak (kendi sınıf dosyasında tanımlanmıştır).

TLDR: En iyi yol hangisidir ve sabitleri nerede bulur?

Vakaların çoğunda, enum yolu daha muhtemelen daha ince olan static final String/Integeryolu ve şahsen düşünüyorum static final String/Integeryolu biz Çeteleler kullanmayın için iyi nedenlerimiz var yalnızca kullanılmalıdır.
Ve sabit değerleri nerede bildirmemiz gerektiği hakkında , fikir, sabit değerlerle belirli ve güçlü bir işlevsel kaynağa sahip tek bir mevcut sınıfın olup olmadığını araştırmaktır. Eğer böyle bir sınıf bulursak, onu sabitler olarak kullanmalıyız . Aksi takdirde, sabit belirli bir sınıfla ilişkilendirilmemelidir.

static final String/ static final Integerkarşıenum

Numaralandırma kullanımı gerçekten dikkate alınması gereken bir yoldur.
Numaralamalar üzerinde büyük bir avantajı var Stringya Integersabit alanı.
Daha güçlü bir derleme kısıtı koydular. Enum'u parametre olarak alan bir yöntem tanımlarsanız, yalnızca enum sınıfında (veya null) tanımlanan bir enum değerini iletebilirsiniz.
String ve Integer ile bunları uyumlu türdeki herhangi bir değerle değiştirebilirsiniz ve değer static final String/ static final Integeralanlarında tanımlanmış bir sabit olmasa bile derleme iyi olur .

Örneğin, bir sınıfta static final Stringalanlar olarak tanımlanan iki sabitin altında :

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

Burada parametre olarak bu sabitlerden birine sahip olmayı bekleyen bir yöntem:

public void process(String constantExpected){
    ...    
}

Bu şekilde başlatabilirsiniz:

process(MyClass.ONE_CONSTANT);

veya

process(MyClass.ANOTHER_CONSTANT);

Ancak hiçbir derleme kısıtlaması bu şekilde çağırmanızı engellemez:

process("a not defined constant value");

Hatayı yalnızca çalışma zamanında ve yalnızca bir defada iletilen değerin kontrolünü yaparsanız alırsınız.

Enum ile, istemciler yalnızca bir enum parametresinde bir enum değerini geçirebildiğinden denetimlere gerek yoktur.

Örneğin, burada bir enum sınıfında tanımlanan iki değer (kutudan çok sabit):

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

Burada parametre olarak bu numaralandırma değerlerinden birine sahip olmayı bekleyen bir yöntem:

public void process(MyEnum myEnum){
    ...    
}

Bu şekilde başlatabilirsiniz:

process(MyEnum.ONE_CONSTANT);

veya

process(MyEnum.ANOTHER_CONSTANT);

Ancak derleme, onu bu şekilde çağırmanıza asla izin vermeyecektir:

process("a not defined constant value");

Sabitleri nerede bildirmeliyiz?

Uygulamanız, sabit değerlerle belirli ve güçlü bir işlevsel bütünlüğe sahip tek bir sınıf içeriyorsa, 1) ve 2) daha sezgisel görünür.
Genel olarak, bunlar onları manipüle eden ana sınıfta beyan edilirse veya içeride bulacağımızı tahmin etmek çok doğal bir adı olan sabitler kullanımını kolaylaştırır.

Örneğin, JDK kitaplığında, üstel ve pi sabit değerleri, yalnızca sabit bildirimler ( java.lang.Math) bildirmeyen bir sınıfta bildirilir .

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

Matematik işlevlerini kullanan istemciler sık ​​sık Mathsınıfa dayanır . Böylece, sabitleri yeterince kolayca bulabilirler ve nerede Eve PItanımlandıklarını da çok doğal bir şekilde hatırlayabilirler .

Uygulamanız, sabit değerlerle çok spesifik ve güçlü bir işlevsel bütünlüğü olan mevcut bir sınıf içermiyorsa, 1 varyant) ve 2 varyant) yolları daha sezgisel görünür.
Genellikle, bunları manipüle eden bir sınıfta ilan edilirken sabitleri kullanmayı kolaylaştırmaz, aynı zamanda onları da manipüle eden 3 veya 4 sınıfımız var ve bu sınıflardan hiç kimse diğerlerinden daha doğal görünmüyor konak sabit değerleri.
Burada, yalnızca sabit değerleri tutmak için özel bir sınıf tanımlamak mantıklıdır.
Örneğin, JDK kitaplığında, java.util.concurrent.TimeUnitenum belirli bir sınıfta bildirilmez, çünkü gerçekte tutması en sezgisel olarak görünen yalnızca bir ve yalnızca bir JDK'ya özgü sınıf yoktur:

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}      

Birçok sınıflar ilan java.util.concurrent: Onları kullanım BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService, ... ve gerçekten onlardan kimse enum tutmak için daha uygun görünüyor.

Herhangi bir türdeki bir Sabit, bir sınıf içinde ( finaldeğiştiriciye üye bir değişken olan ) değişmez bir özellik yaratılarak bildirilebilir . Tipik olarak staticve publicdeğiştiriciler de sağlanır.

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

Bir sabitin değerinin, bir n-demetinden (örn. Numaralandırma ) bir seçime işaret ettiği çok sayıda uygulama vardır . Örneğimizde, atanan olası değerleri kısıtlayacak bir numaralandırılmış Tip tanımlamayı seçebiliriz (örn. tip güvenliği ):

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}

Tek bir genel sabitler sınıfı kötü bir fikirdir. Sabitler, en mantıksal olarak ilişkili oldukları sınıfla birlikte gruplandırılmalıdır.

Herhangi bir değişken (özellikle numaralandırmalar) kullanmak yerine, yöntemleri kullanmanızı öneririm. Değişkenle aynı ada sahip bir yöntem oluşturun ve değişkene atadığınız değeri döndürmesini sağlayın. Şimdi değişkeni silin ve yeni oluşturduğunuz yönteme yapılan çağrılarla tüm referanslarını değiştirin. Sabitin, yalnızca kullanmak için sınıfın bir örneğini oluşturmanız gerekmeyecek kadar genel olduğunu düşünüyorsanız, sabit yöntemi bir sınıf yöntemi yapın.

FWIW, saniye cinsinden zaman aşımı değeri büyük olasılıkla bir sabitleme değil, bir yapılandırma ayarı (özellikler dosyasından veya Enjeksiyon yoluyla okutularak okunmalıdır) olmalıdır.

Fark ne

1.

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

2.

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

ve MyGlobalConstants.TIMEOUT_IN_SECSbu sabite ihtiyacımız olan her yerde kullanmak . Bence ikisi de aynı.

Sınıfı sabitle (kasa dışında) aynı şekilde çağırmazdım ... Tüm sabitlerin yaşayacağı en az bir "Ayarlar" veya "Değerler" veya "Sabitler" sınıfına sahip olurdum. Çok sayıda varsa, bunları mantıksal sabit sınıflarda gruplandırırdım (UserSettings, AppSettings, vb.)

Bir adım daha ileri gitmek için, global olarak kullanılan sabitleri bir arayüze yerleştirerek sistem çapında kullanılabilir. Örneğin

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

Ama o zaman bunu uygulamayın. Sadece tam nitelikli sınıf adı ile doğrudan kod içinde onlara bakın.

Sabitler için Enum daha iyi bir seçim IMHO'dur. İşte bir örnek

genel sınıf myClass {

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}

Bunu yapmanın yollarından biri, sabit değerlere sahip bir 'Global' sınıf oluşturmak ve sabite erişmesi gereken sınıflarda statik bir içe aktarma yapmaktır.

static finalbenim tercihimdir, ben sadece bir enummadde gerçekten numaralandırılabilir olsaydı kullanırım .

kullanırım static final sabitleri beyan ve notasyonu adlandırma ALL_CAPS ile gitmek. Tüm sabitlerin bir arayüzde bir araya getirildiği birkaç gerçek yaşam örneği gördüm. Birkaç yazı haklı olarak kötü bir uygulama olarak adlandırdı, çünkü öncelikle bir arayüzün amacı bu değil. Bir arabirim bir sözleşmeyi zorunlu kılmalı ve ilgisiz sabitleri yerleştirilecek bir yer olmamalıdır. Sabit semantikler belirli bir sınıfa ait değilse (bir özel kurucu aracılığıyla) somutlaştırılamayan bir sınıfa bir araya getirmek de iyidir ( es). Sınıfta her zaman en çok ilgili olan bir sabit koydum, çünkü bu mantıklı ve aynı zamanda kolayca bakım yapılabilir.

Numaralandırmalar bir dizi değeri temsil etmek için iyi bir seçimdir, ancak mutlak değere vurgu yapan bağımsız sabitleri (örneğin, TIMEOUT = 100 ms) saklıyorsanız, static finalyaklaşıma gidebilirsiniz .

En çok söylediklerine katılıyorum, sabitlerin bir koleksiyonuyla uğraşırken enums kullanmak en iyisidir. Ancak, Android'de programlıyorsanız daha iyi bir çözüm var: IntDef Ek Açıklama .

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

IntDef ek açıklaması, basit bir şekilde numaralandırmalardan daha üstündür, sadece derleme zamanı işareti olduğundan önemli ölçüde daha az yer kaplar. Bu bir sınıf değildir ve otomatik dize dönüştürme özelliğine de sahip değildir.

Öyle KÖTÜ alışkanlık ve korkunç SATAŞMAK uygulama temel zemin sıfır fundamantalizmini anlamadan Joshua Bloch alıntı.

Joshua Bloch hakkında hiçbir şey okumadım.

• o korkunç bir programcı
• ya da şimdiye kadar onu alıntıladığımı bulduğum insanlar (Yeşu benim tahmin ettiğim bir çocuğun adıdır), sadece yazılımlarını dini hoşgörülerini haklı çıkarmak için materyalini dini senaryolar olarak kullanıyorlar.

İncil köktenciliğinde olduğu gibi, tüm İncil yasaları şu şekilde özetlenebilir:

• Temel Kimliği tüm kalbinizle ve tüm zihninizle sevin
• Komşunu kendin gibi sev

ve benzer şekilde yazılım mühendisliği köktenciliği

• Kendinizi tüm programlama gücünüz ve zihninizle sıfır noktası temeline adamak
• ve programcı arkadaşlarınızın mükemmeliyetine kendiniz için olduğu gibi ayırın.

Ayrıca, İncil'deki köktendinci çevreler arasında güçlü ve makul bir sonuç ortaya çıkar

• İlk önce kendini sev. Çünkü kendinizi çok sevmiyorsanız, o zaman "komşunuzu kendiniz gibi sevin" kavramı fazla ağırlık taşımamaktadır, çünkü "kendinizi ne kadar çok seversiniz", yukarıda başkalarını seveceğiniz veri hattıdır.

Benzer şekilde, kendinize bir programcı olarak saygı duymuyorsanız ve sadece temelleri sorgulamadan bazı programlama gurusunun duyurularını ve kehanetlerini kabul ederseniz, teklifleriniz ve Joshua Bloch'a (ve benzerlerine) olan güveniniz anlamsızdır. Ve bu nedenle, aslında programcılarınıza saygı duymazsınız.

Yazılım programlamanın temel yasaları

• tembellik iyi bir programcının erdemidir
• programlama hayatınızı kolay, tembel ve dolayısıyla mümkün olduğunca etkili hale getirmelisiniz
• programlamanızın sonuçlarını ve bağırsaklarını sizinle çalışan ve programlama bağırsaklarınızı alan komşu programcılarınız için olabildiğince kolay, tembel ve dolayısıyla mümkün olduğunca etkili hale getirmelisiniz.

Arayüz-desen sabitleri kötü bir alışkanlıktır ???

Hangi dini temelde etkili ve sorumlu programlama yasalarına göre bu dini ferman kabul edilir?

Arayüz kalıbı sabitleri ( https://en.wikipedia.org/wiki/Constant_interface ) hakkındaki wikipedia makalesini okuyun ve arayüz kalıbı sabitlerine karşı belirttiği saçma bahaneler.

• Whatif-IDE yok mu? Bir yazılım programcısı olarak yeryüzünde kimler IDE kullanmaz? Birçoğumuz, bir IDE kullanımından kaçınarak, maço estetik sağkalımcılık olduğunu kanıtlamak zorunda kalmayı tercih etmeyen programcılarız.

  • Ayrıca - IDE'ye ihtiyaç duymamanın bir aracı olarak mikro fonksiyonel programlamanın ikinci taraflarını bekleyin. Veri modeli normalizasyonu hakkındaki açıklamamı okuyana kadar bekleyin.

• Ad alanını geçerli kapsamda kullanılmayan değişkenlerle kirletir mi? Bu görüşün savunucuları olabilir

  • veri modeli normalleşmesinin farkında değil ve buna ihtiyaç duyuluyorsa

• Sabitleri uygulamak için arabirimlerin kullanılması arabirimlerin kötüye kullanılmasıdır. Böyle savunucuların kötü alışkanlıkları var

  • "sabitler" in sözleşme olarak ele alınması gerektiğini görmemek. Ve arayüzler bir sözleşmeye uyumu zorunlu kılmak veya yansıtmak için kullanılır.

• Gelecekte arayüzleri uygulamalı sınıflara dönüştürmek imkansız değilse bile zordur. Hah .... hmmm ... ???

  • Neden kalıcı geçim kaynağınız gibi bir programlama modeliyle uğraşmak istersiniz? IOW, neden kendinizi böyle bir AMBIVALENT ve kötü programlama alışkanlığına adadınız?

Mazeretler ne olursa olsun, arayüz sabitlerinin kullanımını yetkilendirmek veya genel olarak caydırmak için TEMEL ETKİLİ yazılım mühendisliği söz konusu olduğunda GEÇERLİ ÖZEL DURUM YOKTUR.

Amerika Birleşik Devletleri Anayasası'nı kuran kurucu babaların orijinal niyetlerinin ve zihinsel durumlarının ne olduğu önemli değil. Kurucu babaların asıl niyetlerini tartışabiliriz, ama tek umduğum ABD Anayasası'nın yazılı açıklamaları. Ve ABD Anayasası'nın yazılı olmayan kurucu niyetlerinden değil, yazılı edebi-köktenciliğin kullanılması her ABD vatandaşının sorumluluğundadır.

Benzer şekilde, Java platformunun ve programlama dilinin kurucularının arayüz için "orijinal" niyetlerinin ne olduğu umurumda değil. İlgilendiğim, Java spesifikasyonunun sağladığı etkili özellikler ve sorumlu yazılım programlamanın temel yasalarını yerine getirmeme yardımcı olmak için bu özelliklerden sonuna kadar yararlanmayı planlıyorum. "Arayüzlerin niyetini ihlal ettiği" algılanıp algılanmamam umrumda değil. Gosling veya Bloch'un "Java'yı kullanmanın uygun yolu" hakkında ne söylediğini umursamıyorum, söyledikleri ETKİLİ tatmin edici temelleri benim ihtiyacımı ihlal etmedikçe.

Temel Veri-Model Normalizasyonu

Veri modelinizin nasıl barındırıldığı veya iletildiği önemli değildir. Arayüzler veya numaralandırmalar veya ne olursa olsun, ilişkisel veya SQL olmayan, veri modeli normalizasyonunun gerekliliğini ve sürecini anlamıyorsanız.

Öncelikle bir dizi sürecin veri modelini tanımlamalı ve normalleştirmeliyiz. Tutarlı bir veri modelimiz olduğunda, SADECE bileşenlerinin süreç akışını işlevsel davranışı tanımlamak ve bir alan veya uygulama alanını işlemek için kullanabiliriz. Ve ancak o zaman her fonksiyonel sürecin API'sını tanımlayabiliriz.

EF Codd'un önerdiği gibi veri normalleştirmenin yönleri bile şimdi ciddi şekilde zorlanıyor ve ciddi şekilde zorlanıyor. Örneğin, 1NF ile ilgili ifadesi, özellikle modern veri hizmetleri, repo-teknoloji ve aktarımın ortaya çıkışındaki ifadelerinin geri kalanı gibi belirsiz, yanlış hizalanmış ve aşırı basitleştirilmiş olarak eleştirilmiştir. IMO, EF Codd ifadeleri tamamen terk edilmeli ve yeni matematiksel olarak daha makul ifadeler dizisi tasarlanmalıdır.

EF Codd'ların göze çarpan bir kusuru ve etkili insan kavrayışındaki yanlış hizalanmasının nedeni, insanca algılanabilen çok boyutlu, değişken boyutlu verilerin bir dizi parçalı 2 boyutlu haritalamada etkili bir şekilde algılanabileceğine olan inancıdır.

Veri Normalleştirmenin Temelleri

EF Codd'un ifade edemediği şeyler.

Her bir tutarlı veri modeli içinde, bunlar elde edilecek veri modeli tutarlılığının ardışık dereceli sırasıdır.

1. Veri örneklerinin Birliği ve Kimliği.
   • her veri bileşeninin tanecikliliğini tasarlar, böylece tanecikler bir bileşenin her bir örneğinin benzersiz bir şekilde tanımlanabildiği ve alınabildiği bir seviyede olur.
   • örnek örtüşme yokluğu. yani, bir kimliğin bir bileşenin birden fazla örneğini ürettiği hiçbir araç mevcut değildir.
2. Örnek karışma yokluğu. Bir bileşenin bir örneğinin tanımlanmasına katkıda bulunmak için bir bileşenin bir veya daha fazla başka örneğini kullanma zorunluluğu yoktur.
3. Veri bileşenlerinin / boyutlarının birliği ve kimliği.
   • Bileşen yumuşatmanın varlığı. Bir bileşenin / boyutun benzersiz bir şekilde tanımlanabileceği bir tanım olmalıdır. Bir bileşenin birincil tanımı olan;
   • birincil tanım, amaçlanan bir bileşenin parçası olmayan alt boyutların veya üye bileşenlerin gösterilmesiyle sonuçlanmaz;
4. Bileşenlerden kurtulmanın benzersiz yolları. Bir bileşen için yalnızca bir tane, böyle bir bileşen yumuşatma tanımı bulunmalıdır.
5. Bileşenlerin hiyerarşik ilişkisinde bir üst bileşeni tanımlamak için bir ve yalnızca bir tanım arabirimi veya sözleşmesi vardır.
6. Bileşen karışma yokluğu. Bir bileşenin kesin tanımlamasına katkıda bulunmak için başka bir bileşenin bir üyesini kullanma zorunluluğu yoktur.
   • Böyle bir ebeveyn-çocuk ilişkisinde, bir ebeveynin tanımlayıcı tanımı, bir çocuğun üye bileşenleri kümesinin bir kısmına bağlı olmamalıdır. Ebeveyn kimliğinin bir üye bileşeni, bir çocuğun çocuklarından herhangi birine veya tümüne başvuruda bulunmadan tam çocuk kimliği olmalıdır.
7. Bir veri modelinin iki modlu veya çok modlu görünümlerini önleyin.
   • Bir bileşenin iki aday tanımı olduğunda, iki farklı veri modelinin bir olarak karıştırıldığının açık bir işaretidir. Bu, veri modeli düzeyinde veya alan düzeyinde tutarsızlık olduğu anlamına gelir.
   • Bir uygulama alanı tutarlı bir şekilde bir ve sadece bir veri modeli kullanmalıdır.
8. Bileşen mutasyonunu tespit edin ve tanımlayın. Büyük verilerin istatistiksel bileşen analizini yapmadıysanız, bileşen mutasyonunu muhtemelen görmez veya tedavi etme gereğini görmezsiniz.
   • Bir veri modeli, bileşenlerinden bazılarının döngüsel veya kademeli olarak değişmesine neden olabilir.
   • Mod, eleman döndürme veya aktarma döndürme olabilir.
   • Üye-rotasyon mutasyonu, alt bileşenlerin bileşenler arasında belirgin şekilde değiştirilmesi olabilir. Veya tamamen yeni bileşenlerin tanımlanması gereken yer.
   • Transpozisyonel mutasyon, bir niteliğe mutasyona uğrayan boyutsal bir üye olarak tezahür eder, bunun tersi de geçerlidir.
   • Her mutasyon döngüsü, ayrı bir veri yöntemi olarak tanımlanmalıdır.
9. Her mutasyonu güncelleyin. Veri modelinin 8 yıllık bir mutasyonunu tedavi etme ihtiyacı ortaya çıktığında, veri modelinin önceki bir versiyonunu çıkarabilirsiniz.

Servisler arası bileşen uygulamaları alanında veya ızgarasında, bir ve yalnızca bir tutarlı veri modeli olmalı veya bir veri modeli / sürümünün kendisini tanımlaması için bir araç olmalıdır.

Hala Arayüz Sabitlerini kullanıp kullanamayacağımızı soruyor muyuz? Gerçekten mi ?

Söz konusu sıradan sorudan daha fazla sonuçta veri normalleştirme sorunları söz konusudur. Bu sorunları çözmezseniz, arayüz sabitlerinin neden olduğunu düşündüğünüz karışıklık nispeten hiçbir şey değildir. Sıfır.

Veri modeli normalleştirmesinden sonra bileşenleri değişken olarak, özellikler olarak, sözleşme arabirimi sabitleri olarak belirlersiniz.

Ardından hangisinin değer enjeksiyonu, özellik yapılandırması yer tutuşu, arayüzler, son dizeler vb.

Arabirim sabitlerine karşı dikte etmek için daha kolay bir bileşen bulmaya ihtiyaç duymanın mazeretini kullanmak zorundaysanız, veri modeli normalleştirmesi yapmamanın kötü alışkanlığınız olduğu anlamına gelir.

Belki de veri modelini bir vcs sürümüne derlemek istersiniz. Bir veri modelinin belirgin bir şekilde tanımlanabilir bir versiyonunu çıkarabilirsiniz.

Arayüzlerde tanımlanan değerlerin tamamen değiştirilemez olduğundan emin olunur. Ve paylaşılabilir. İhtiyacınız olan tek şey bu sabitler dizisi olduğunda neden sınıfınıza başka bir sınıftan bir dizi son dizgi yüklemek?

Peki bu neden bir veri modeli sözleşmesi yayınlamıyor? Yani eğer tutarlı bir şekilde yönetebilir ve normalleştirebilirseniz, neden olmasın? ...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

Artık uygulamalarımın sözleşmeli etiketlerine şu şekilde başvurabilirim:

CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

Bu jar dosyasının içeriğini karıştırıyor mu? Bir Java programcısı olarak kavanozun yapısını önemsemiyorum.

Bu, osgi motivasyonlu çalışma zamanı değiş tokuşuna karmaşıklık getiriyor mu? Osgi, programcıların kötü alışkanlıklarına devam etmelerini sağlamak için son derece verimli bir araçtır. Osgi'den daha iyi alternatifler var.

Ya da neden olmasın? Özel Sabitler'in yayınlanan sözleşmeye sızması söz konusu değildir. Tüm özel sabitler "Sabitler" adlı özel bir arayüzde gruplandırılmalıdır, çünkü sabitleri aramak istemiyorum ve tekrar tekrar "private final String" yazmak için çok tembelim.

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Belki de bu:

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Arayüz sabitleriyle ilgili dikkate alınması gereken tek sorun arayüzün ne zaman uygulandığıdır.

Bu arayüzlerin “orijinal niyeti” değil mi? Sanki Yüksek Mahkemenin ABD Anayasası'nın yazılı mektuplarını nasıl yorumlayacağından ziyade, kurucu babaların ABD Anayasası'nın hazırlanmasındaki "asıl niyeti" umurumda mı?

Sonuçta, özgür, vahşi ve cesur ülkesinde yaşıyorum. Cesur olun, özgür olun, vahşi olun - arayüzü kullanın. Program arkadaşlarım verimli ve tembel programlama araçlarını kullanmayı reddederse, altın kuralına göre programlama verimliliğimi onlarınkiyle aynı hizada azaltmak zorunda mıyım? Belki de söylemeliyim, ama bu ideal bir durum değil.