Ik heb voorbeelden als deze gezien:
public class MaxSeconds {
public static final int MAX_SECONDS = 25;
}
en veronderstelde dat ik een Constants-klasse zou kunnen hebben om constanten in te verpakken en ze statisch definitief te verklaren. Ik ken praktisch geen Java en vraag me af of dit de beste manier is om constanten te creëren.
Antwoord 1, autoriteit 100%
Dat is volkomen acceptabel, waarschijnlijk zelfs de standaard.
(public/private) static final TYPE NAME = VALUE;
waar TYPEhet type is, NAMEde naam is in hoofdletters met underscores voor spaties, en VALUEde constante waarde is;
Ik raad ten zeerste aan om je constanten NIET in hun eigen klassen of interfaces te plaatsen.
Als een kanttekening: variabelen die definitief zijn verklaard en veranderlijk zijn, kunnen nog steeds worden gewijzigd; de variabele kan echter nooit naar een ander object wijzen.
Bijvoorbeeld:
public static final Point ORIGIN = new Point(0,0);
public static void main(String[] args){
ORIGIN.x = 3;
}
Dat is legaal en ORIGINzou dan een punt op (3, 0) zijn.
Antwoord 2, autoriteit 58%
Ik zou het ten zeerste afraden om een enkele constantenklasse te hebben. Het lijkt op dat moment misschien een goed idee, maar wanneer ontwikkelaars weigeren constanten te documenteren en de klasse groeit tot meer dan 500 constanten die allemaal helemaal geen verband houden met elkaar (gerelateerd aan totaal verschillende aspecten van de toepassing), dit verandert over het algemeen in het constantenbestand dat volledig onleesbaar is. In plaats daarvan:
- Als je toegang hebt tot Java 5+, gebruik dan enums om je specifieke constanten voor een toepassingsgebied te definiëren. Alle delen van het toepassingsgebied moeten voor deze constanten verwijzen naar enums, niet naar constante waarden. U kunt een enum declareren vergelijkbaar met hoe u een klasse declareert. Enums zijn misschien wel de meest (en misschien wel enige) handige functie van Java 5+.
- Als je constanten hebt die alleen geldig zijn voor een bepaalde klasse of een van zijn subklassen, declareer ze dan als beschermd of openbaar en plaats ze in de hoogste klasse in de hiërarchie. Op deze manier hebben de subklassen toegang tot deze constante waarden (en als andere klassen ze via public benaderen, zijn de constanten niet alleen geldig voor een bepaalde klasse… wat betekent dat de externe klassen die deze constante gebruiken mogelijk te nauw gekoppeld zijn aan de klasse die de constante bevat)
- Als je een interface hebt met een gedefinieerd gedrag, maar de geretourneerde waarden of argumentwaarden moeten specifiek zijn, dan is het volkomen acceptabel om constanten op die interface te definiëren, zodat andere uitvoerders er toegang toe hebben. Vermijd echter het maken van een interface om alleen constanten vast te houden: het kan net zo slecht worden als een klasse die alleen is gemaakt om constanten vast te houden.
Antwoord 3, autoriteit 30%
Het is SLECHTE PRAKTIJKom interfaces te gebruiken om alleen constanten vast te houden (met de naam constant interfacepatroondoor Josh Bloch). Dit is wat Josh adviseert:
Als de constanten sterk verbonden zijn met
een bestaande klasse of interface, jij
moet ze aan de klas toevoegen of
koppel. Bijvoorbeeld alle
in dozen gedane numerieke primitieve klassen,
zoals Integer en Double, export
MIN_VALUE en MAX_VALUE constanten. Indien
de constanten kunnen het best worden bekeken als
leden van een opgesomd type, jij
moet ze exporteren met een enum
type. Anders moet u de
constanten met een niet-instantiële
nutsklasse.
Voorbeeld:
// 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;
}
Over de naamgevingsconventie:
Volgens afspraak hebben dergelijke velden namen
bestaande uit hoofdletters, met
woorden gescheiden door onderstrepingstekens. Het is
essentieel dat deze velden bevatten
ofwel primitieve waarden of referenties
naar onveranderlijke objecten.
Antwoord 4, autoriteit 9%
In Effective Java (2e editie) wordt aanbevolen om enums te gebruiken in plaats van statische ints voor constanten.
Er is hier een goede beschrijving van opsommingen in Java:
http://java.sun.com/j2se/1.5 .0/docs/guide/language/enums.html
Merk op dat aan het einde van dat artikel de gestelde vraag luidt:
Dus wanneer moet je opsommingen gebruiken?
Met een antwoord van:
Elke keer dat u een vaste set constanten nodig heeft
Antwoord 5, autoriteit 5%
Vermijd het gebruik van een interface:
public interface MyConstants {
String CONSTANT_ONE = "foo";
}
public class NeddsConstant implements MyConstants {
}
Het is verleidelijk, maar schendt de inkapseling en vervaagt het onderscheid tussen klassedefinities.
Antwoord 6, autoriteit 5%
Ik gebruik de volgende aanpak:
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() {}
}
Dan gebruik ik bijvoorbeeld Constants.DB.Connection.URLom constant te worden.
Het ziet er voor mij meer “object-georiënteerd” uit.
Antwoord 7, autoriteit 4%
Als u statische eindconstanten in een aparte klasse maakt, kunt u in de problemen komen. De Java-compiler zal dit daadwerkelijk optimaliseren en de werkelijke waarde van de constante in elke klasse plaatsen die ernaar verwijst.
Als je later de klasse ‘Constanten’ wijzigt en je geen harde hercompilatie uitvoert op andere klassen die naar die klasse verwijzen, zul je eindigen met een combinatie van oude en nieuwe waarden die worden gebruikt.
In plaats van deze als constanten te beschouwen, beschouw ze als configuratieparameters en maak een klasse om ze te beheren. Zorg ervoor dat de waarden niet-definitief zijn en overweeg zelfs om getters te gebruiken. Als u in de toekomst vaststelt dat sommige van deze parameters eigenlijk door de gebruiker of beheerder moeten worden geconfigureerd, zal het veel gemakkelijker zijn om dit te doen.
8
Dat is de juiste manier om te gaan.
Over het algemeen constanten zijn niet gehouden in afzonderlijke “constanten” -klassen omdat ze niet ontdekken. Als de constante relevant is voor de huidige klas, helpt u daarbij de volgende ontwikkelaar.
9
Hoe zit het met een opsomming?
10
Ik geef de voorkeur om Getters te gebruiken in plaats van constanten. Die Getters kunnen constante waarden retourneren, b.v. public int getMaxConnections() {return 10;}, maar alles wat de constante nodig heeft, zal door een getter gaan.
Eén voordeel is dat als uw programma de constante uitgegroeid is – u vindt dat het moet worden geconfigureerd – u kunt gewoon wijzigen hoe de Getter de constante retourneert.
Het andere voordeel is dat om de constante te wijzigen die u niet hoeft te hercompileren alles wat het gebruikt. Wanneer u een statisch definitief veld verwijzen, wordt de waarde van die constante samengesteld in elke bypecode die deze verwijst.
11
Ik ben het ermee eens dat het gebruik van een interface niet de manier is om te gaan. Het vermijden van dit patroon heeft zelfs een eigen item (# 18) in Bloch’s effectieve Java .
Een argument dat Bloch aanvoert tegen het constante interfacepatroon is dat het gebruik van constanten een implementatiedetail is, maar door een interface te implementeren om ze te gebruiken, wordt dat implementatiedetail zichtbaar in uw geëxporteerde API.
Het public|private static final TYPE NAME = VALUE;is een goede manier om een constante te declareren. Persoonlijk denk ik dat het beter is om geen aparte klasse te maken voor al je constanten, maar ik heb nooit een reden gezien om dit niet te doen, behalve persoonlijke voorkeur en stijl.
Als je constanten goed kunnen worden gemodelleerd als een opsomming, overweeg dan de enumstructuur beschikbaar in 1.5 of later.
Als u een eerdere versie dan 1.5 gebruikt, kunt u nog steeds typesafe-opsommingen uitvoeren door normale Java-klassen te gebruiken. (Zie deze sitevoor meer informatie).
Antwoord 12
Op basis van de bovenstaande opmerkingen denk ik dat dit een goede benadering is om de ouderwetse globale constante klasse (met openbare statische eindvariabelen) te veranderen in zijn enum-achtige equivalent op een manier als deze:
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;
}
}
Dus dan kan ik ze doorverwijzen naar:
Constants.StringConstant.DB_HOST
13
Een goed object georiënteerd ontwerp mag niet veel publiekelijk beschikbare constanten nodig hebben. De meeste constanten moeten worden ingekapseld in de klas die hen nodig heeft om zijn werk te doen.
14
Er is een zekere mate van mening om dit te beantwoorden. Om te beginnen worden constanten in Java over het algemeen uitgeroepen tot openbaar, statisch en definitief. Hieronder staan de redenen:
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
Ik zou nooit een interface gebruiken voor een Constanten Accessor / -object, simpelweg omdat interfaces in het algemeen naar verwachting worden geïmplementeerd. Zou dit niet grappig uitzien:
String myConstant = IMyInterface.CONSTANTX;
In plaats daarvan zou ik kiezen uit een paar verschillende manieren, op basis van enkele kleine afwegingen, en dus hangt het af van wat je nodig hebt:
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
Antwoord 15
Wat is de beste manier om constanten in Java te implementeren?
Eén benadering die we echt moeten vermijden: interfaces gebruiken om constanten te definiëren.
Het creëren van een interface speciaal om constanten te declareren is echt het ergste: het verslaat de reden waarom interfaces zijn ontworpen: het definiëren van methode(s) contract.
Zelfs als er al een interface bestaat om aan een specifieke behoefte te voldoen, heeft het geen zin om de constanten daarin te declareren, aangezien constanten geen onderdeel zouden moeten uitmaken van de API en het contract dat aan klantklassen wordt verstrekt.
Om te vereenvoudigen, hebben we grofweg vier geldige benaderingen.
Met static final String/Integerveld :
- 1) met behulp van een klasse die constanten binnenin declareert, maar niet alleen.
- 1 variant) het creëren van een klasse die is bedoeld om alleen constanten te declareren.
Met Java 5 enum:
- 2) het declareren van de enum in een verwante doelklasse (dus als een geneste klasse).
- 2-variant) waarbij de enum wordt gemaakt als een op zichzelf staande klasse (dus gedefinieerd in zijn eigen klassenbestand).
TLDR: wat is de beste manier en waar vind je de constanten?
In de meeste gevallen is de enum-manier waarschijnlijk fijner dan de static final String/Integer-manieren persoonlijk denk ik dat de static final String/Integer-manier mag alleen worden gebruikt als we goede redenen hebben om geen opsommingen te gebruiken.
En over waar we de constante waarden moeten declareren, het idee is om te zoeken of er een enkele bestaande klasse is die een specifieke en sterke functionele cohesie bezit met constante waarden. Als we zo’n klasse vinden, moeten we deze gebruiken als houder van de constanten. Anders zou de constante niet aan een bepaalde klasse moeten worden gekoppeld.
static final String/ static final Integerversus enum
Enums-gebruik is echt een manier om goed over na te denken.
Enums hebben een groot voordeel ten opzichte van Stringof Integerconstant veld.
Ze stellen een sterkere compilatiebeperking.
Als u een methode definieert die de enum als parameter neemt, kunt u alleen een enum-waarde doorgeven die is gedefinieerd in de enum-klasse (of null).
Met String en Integer kun je ze vervangen door alle waarden van een compatibel type en de compilatie zal in orde zijn, zelfs als de waarde geen gedefinieerde constante is in de static final String/ static final Integervelden.
Bijvoorbeeld, hieronder twee constanten die in een klasse zijn gedefinieerd als static final Stringvelden:
public class MyClass{
public static final String ONE_CONSTANT = "value";
public static final String ANOTHER_CONSTANT = "other value";
. . .
}
Hier een methode die een van deze constanten als parameter verwacht:
public void process(String constantExpected){
...
}
Je kunt het op deze manier aanroepen:
process(MyClass.ONE_CONSTANT);
of
process(MyClass.ANOTHER_CONSTANT);
Maar geen enkele compilatiebeperking verhindert u om het op deze manier aan te roepen:
process("a not defined constant value");
U zou de fout alleen tijdens runtime hebben en alleen als u tegelijkertijd de verzonden waarde controleert.
Met enum zijn controles niet vereist omdat de client alleen een enum-waarde in een enum-parameter kan doorgeven.
Hier bijvoorbeeld twee waarden gedefinieerd in een enum-klasse (dus direct out-of-the-box constant):
public enum MyEnum {
ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");
private String value;
MyEnum(String value) {
this.value = value;
}
...
}
Hier een methode die verwacht een van deze enum-waarden als parameter te hebben:
public void process(MyEnum myEnum){
...
}
Je kunt het op deze manier aanroepen:
process(MyEnum.ONE_CONSTANT);
of
process(MyEnum.ANOTHER_CONSTANT);
Maar de compilatie zal je nooit toestaan om het op deze manier aan te roepen:
process("a not defined constant value");
Waar moeten we de constanten declareren?
Als uw toepassing een enkele bestaande klasse bevat die een specifieke en sterke functionele samenhang heeft met de constante waarden, lijken de 1) en de 2) intuïtiever.
Over het algemeen vergemakkelijkt het het gebruik van constanten als deze worden gedeclareerd in de hoofdklasse die ze manipuleert of die een naam heeft die heel natuurlijk is om te raden dat we deze binnenin zullen vinden.
Bijvoorbeeld in de JDK-bibliotheek worden de exponentiële en pi constante waarden gedeclareerd in een klasse die niet alleen constante declaraties declareert (java.lang.Math).
public final class Math {
...
public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;
...
}
De klanten die wiskundige functies gebruiken, vertrouwen vaak op de klasse Math.
Ze kunnen dus gemakkelijk genoeg constanten vinden en kunnen ook onthouden waar Een PIop een heel natuurlijke manier zijn gedefinieerd.
Als uw toepassing geen bestaande klasse bevat die een zeer specifieke en sterke functionele samenhang heeft met de constante waarden, lijken de 1 variant) en de 2 variant) manieren intuïtiever.
Over het algemeen vergemakkelijkt het het gebruik van de constanten niet als deze worden gedeclareerd in één klasse die ze manipuleert, terwijl we ook 3 of 4 andere klassen hebben die ze zoveel manipuleren als en geen van deze klassen lijkt natuurlijker dan andere om host constante waarden.
Hier is het zinvol om een aangepaste klasse te definiëren die alleen constante waarden bevat.
In de JDK-bibliotheek wordt de java.util.concurrent.TimeUnit-enum bijvoorbeeld niet gedeclareerd in een specifieke klasse, omdat er niet echt één en slechts één JDK-specifieke klasse is die het meest intuïtief lijkt om vast te houden het :
public enum TimeUnit {
NANOSECONDS {
.....
},
MICROSECONDS {
.....
},
MILLISECONDS {
.....
},
SECONDS {
.....
},
.....
}
Veel klassen gedeclareerd in java.util.concurrentgebruiken ze:
BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService, … en echt geen van hen lijkt meer geschikt om de opsomming vast te houden.
Antwoord 16
Een constante, van elk type, kan worden gedeclareerd door een onveranderlijke eigenschap binnen een klasse te maken (dat is een lidvariabele met de final-modifier). Meestal worden ook de modifiers staticen publicgegeven.
public class OfficePrinter {
public static final String STATE = "Ready";
}
Er zijn talloze toepassingen waarbij de waarde van een constante een selectie aangeeft uit een n-tupel (bijv. opsomming) van keuzes. In ons voorbeeld kunnen we ervoor kiezen een opgesomd type te definiëren dat de mogelijke toegewezen waarden beperkt (d.w.z. verbeterde type-veiligheid):
public class OfficePrinter {
public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
public static final PrinterState STATE = PrinterState.Ready;
}
Antwoord 17
Een enkele, generieke constantenklasse is een slecht idee. Constanten moeten worden gegroepeerd met de klasse waaraan ze het meest logisch gerelateerd zijn.
In plaats van allerlei soorten variabelen (vooral opsommingen) te gebruiken, raad ik je aan om methoden te gebruiken. Maak een methode met dezelfde naam als de variabele en laat deze de waarde retourneren die u aan de variabele hebt toegewezen. Verwijder nu de variabele en vervang alle verwijzingen ernaar door aanroepen naar de methode die u zojuist hebt gemaakt. Als je denkt dat de constante generiek genoeg is zodat je geen instantie van de klasse hoeft te maken om hem te gebruiken, maak dan van de constante methode een klassemethode.
Antwoord 18
FWIW, een time-out in seconden zou waarschijnlijk een configuratie-instelling moeten zijn (inlezen vanuit een eigenschappenbestand of via injectie zoals in Spring) en geen constante.
Antwoord 19
Wat is het verschil
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;
}
en gebruiken
MyGlobalConstants.TIMEOUT_IN_SECSwaar we deze constante nodig hebben. Ik denk dat beide hetzelfde zijn.
Antwoord 20
Ik zou de klasse niet hetzelfde noemen (afgezien van het hoofdlettergebruik) als de constante … Ik zou minimaal één klasse “Instellingen”, of “Waarden” of “Constanten” hebben, waarin alle constanten zou leven. Als ik er een groot aantal heb, zou ik ze groeperen in logische constante klassen (UserSettings, AppSettings, enz.)
Antwoord 21
Om nog een stap verder te gaan, kunt u wereldwijd gebruikte constanten in een interface plaatsen, zodat ze systeembreed kunnen worden gebruikt. Bijv.
public interface MyGlobalConstants {
public static final int TIMEOUT_IN_SECS = 25;
}
Maar implementeer het dan niet. Verwijs er gewoon rechtstreeks naar in code via de volledig gekwalificeerde klassenaam.
Antwoord 22
Voor Constants is Enum een betere keuze IMHO. Hier is een voorbeeld
openbare klas 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 }
}
Antwoord 23
Een van de manieren waarop ik dit doe is door een ‘Globale’ klasse te maken met de constante waarden en een statische import uit te voeren in de klassen die toegang tot de constante nodig hebben.
Antwoord 24
static finalheeft mijn voorkeur, ik zou alleen een enumgebruiken als het item inderdaad opsombaar was.
Antwoord 25
Ik gebruik static finalom constanten te declareren en gebruik de ALL_CAPS naamgevingsnotatie. Ik heb nogal wat voorbeelden uit het echte leven gezien waarin alle constanten zijn samengevoegd tot een interface. Een paar berichten hebben dat terecht een slechte gewoonte genoemd, vooral omdat daar een interface niet voor is. Een interface moet een contract afdwingen en mag geen plaats zijn om niet-gerelateerde constanten in te plaatsen. Het samenvoegen in een klasse die niet kan worden geïnstantieerd (via een privéconstructor) is ook prima als de constante semantiek niet tot een specifieke klasse behoort ( en). Ik plaats altijd een constante in de klas waar deze het meest mee te maken heeft, omdat dat logisch is en ook gemakkelijk te onderhouden is.
Enums zijn een goede keuze om een reeks waarden weer te geven, maar als u stand-alone constanten opslaat met de nadruk op de absolute waarde (bijv. TIMEOUT = 100 ms), kunt u gewoon gaan voor de static finalbenadering.
Antwoord 26
Ik ben het eens met wat de meesten zeggen, het is het beste om opsommingen te gebruiken als je te maken hebt met een verzameling constanten. Als u echter in Android programmeert, is er een betere oplossing: IntDef Annotation.
@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-annotatie is op één eenvoudige manier superieur aan enums, het neemt aanzienlijk minder ruimte in beslag omdat het gewoon een markering voor het compileren is. Het is geen klasse en heeft ook geen automatische string-conversie-eigenschap.
Antwoord 27
Het is SLECHTE gewoonte en vreselijk
VERRASSENDE praktijkom Joshua Bloch te citeren zonder het fundamentele grond-nul-fundamentalisme te begrijpen.
Ik heb niets van Joshua Bloch gelezen, dus ook niet
- hij is een verschrikkelijke programmeur
- of de mensen die ik tot nu toe vind die hem citeren (Jozua is de naam van een jongen, neem ik aan) gebruiken zijn materiaal gewoon als religieuze scripts om hun softwarematige religieuze uitspattingen te rechtvaardigen.
Net als in het bijbelfundamentalisme kunnen alle bijbelse wetten worden samengevat door
- Houd van de Fundamentele Identiteit met heel je hart en heel je verstand
- Heb je naaste lief als jezelf
en zo kan het fundamentalisme van software-engineering worden samengevat door
- wijd jezelf met al je programmeerkracht en verstand aan de grond-nul-grondbeginselen
- en wijdt u aan de uitmuntendheid van uw mede-programmeurs zoals u dat voor uzelf zou doen.
Ook onder bijbelse fundamentalistische kringen wordt een sterk en redelijk gevolg getrokken
- Houd eerst van jezelf. Want als je niet veel van jezelf houdt, dan weegt het concept “heb je naaste lief als jezelf” niet veel gewicht, aangezien “hoeveel je van jezelf houdt” de referentielijn is waarboven je anderen zou liefhebben.
Evenzo, als u uzelf niet respecteert als een programmeur en gewoon de uitspraken en profetieën van sommige programmeergoeroe-NATH accepteert zonder de fundamenten te betwijfelen, zijn uw offertes en vertrouwen op Joshua Bloch (en dergelijke) zinloos. En daarom zou u eigenlijk geen respect hebben voor uw collega-programmeurs.
De fundamentele wetten van softwareprogrammering
- Luiheid is de deugd van een goede programmeur
- Je bent om je programmeerleven zo eenvoudig, zo lui en daarom zo effectief mogelijk te maken
- U bent om de consequenties en ingewanden van uw programmering zo eenvoudig, zo lui en daarom zo effectief mogelijk voor uw Neigbour-programmeurs die met u samenwerken en uw programmeergerelementen ophalen.
Interface-patroonconstanten is een slechte gewoonte ???
Onder welke wetten van fundamenteel effectieve en verantwoordelijke programmering daalt dit religieuze edict?
Lees gewoon het Wikipedia-artikel over Confacepatroon Constanten (https://en.wikipedia.org/ WIKI / CONSTANT_INTERFACE ), en de dwaze excuses die staten tegen de constanten van de interface-patroon.
-
WhatIb-No IDE? Wie op aarde als softwareprogramma zou geen IDE gebruiken? De meesten van ons zijn programmeurs die liever niet moeten blijken te hebben dat ze macho-aescetische survivalisme thro te vermijden om het gebruik van een IDE te vermijden.
- Wacht ook een tweede voorstanders van micro-functionele programmering als een middel om geen IDE te hebben. Wacht tot je mijn uitleg leest op de normalisatie van het gegevensmodel.
-
Verontreinigen de naamruimte met variabelen die niet binnen de huidige reikwijdte worden gebruikt? Het kan voorstanders zijn van deze mening
- zijn niet op de hoogte van, en de noodzaak van de data-model-normalisatie
-
Het gebruik van interfaces voor handhaving van constanten is een misbruik van interfaces. Voorstanders van zo’n slechte gewoonte van
- niet zien dat “constanten” moeten worden behandeld als contract. En interfaces worden gebruikt voor het afdwingen of projecteren van naleving van een contract.
-
Het is moeilijk, zo niet onmogelijk om interfaces in geïmplementeerde klassen in de toekomst te converteren. Hah …. hmmm … ???
- Waarom zou je een dergelijk patroon van programmeren willen doen als je persistente levensonderhoud? Wacht je jezelf aan zo’n ambivalente en slechte programmeringsgewoonte?
Wat de excuses ook is, er is geen geldig excuus als het gaat om fundamenteel effectieve software-engineering om het gebruik van interface-constanten te delegitimeren of over het algemeen te ontmoedigen.
Het maakt niet uit wat de oorspronkelijke intentie en mentale toestanden van de oprichtingsvaders die de grondwet van de Verenigde Staten vervaardigd waren. We zouden de oorspronkelijke intenties van de grondvaders kunnen debatteren, maar alles wat ik geef de schriftelijke verklaringen van de Amerikaanse grondwet. En het is de verantwoordelijkheid van elke Amerikaanse burger om het schriftelijke literaire fundamentalisme te exploiteren, niet de ongeschreven oprichtingen, van de Amerikaanse grondwet.
Evenzo maakt het me niet om wat de “originele” van de oprichters van het Java-platform en de programmeringstaal voor de interface hadden. Wat ik geef zijn de effectieve kenmerken die de Java-specificatie biedt, en ik ben van plan om die kenmerken ten volle te benutten om me te helpen de fundamentele wetten van verantwoordelijke softwareprogrammering te vervullen. Het kan me niet schelen of ik ‘de intentie voor interfaces’ schendden ‘. Het kan me niet schelen welke gansling of iemand Bloch zegt over de ‘juiste manier om Java’ te gebruiken “, tenzij ze zeggen dat ze niet overtreden mijn behoefte aan doeltreffende fundamentals.
Het fundamentele is data-model normalisatie
Het maakt niet uit hoe uw datamodel wordt gehost of verzonden. Of u nu interfaces of opsommingen of wat dan ook gebruikt, relationeel of niet-SQL, als u de noodzaak en het proces van normalisatie van gegevensmodellen niet begrijpt.
We moeten eerst het datamodel van een reeks processen definiëren en normaliseren. En als we een coherent datamodel hebben, ALLEEN dan kunnen we de processtroom van zijn componenten gebruiken om het functionele gedrag te definiëren en procesblokken een veld of domein van toepassingen te blokkeren. En alleen dan kunnen we de API van elk functioneel proces definiëren.
Zelfs de facetten van gegevensnormalisatie, zoals voorgesteld door EF Codd, worden nu ernstig uitgedaagd en ernstig uitgedaagd. bijv. zijn verklaring over 1NF is bekritiseerd als dubbelzinnig, verkeerd uitgelijnd en te vereenvoudigd, net als de rest van zijn verklaringen, vooral in de komst van moderne datadiensten, repo-technologie en transmissie. IMO, de EF Codd-statements moeten volledig worden gedumpt en er moet een nieuwe reeks meer wiskundig plausibele uitspraken worden ontworpen.
Een flagrante tekortkoming van EF Codd en de oorzaak van de verkeerde afstemming op effectief menselijk begrip, is zijn overtuiging dat menselijk waarneembare multidimensionale, veranderlijke dimensiegegevens efficiënt kunnen worden waargenomen via een reeks fragmentarische 2-dimensionale afbeeldingen.
>
De grondbeginselen van gegevensnormalisatie
Wat EF Codd niet heeft gezegd.
Binnen elk coherent datamodel zijn dit de sequentiële graduele volgorde van datamodelcoherentie die moet worden bereikt.
- De eenheid en identiteit van gegevensinstanties.
- ontwerp de granulariteit van elke gegevenscomponent, waarbij hun granulariteit zich op een niveau bevindt waarop elke instantie van een component uniek kan worden geïdentificeerd en opgehaald.
- afwezigheid van instantie-aliasing. d.w.z. er bestaat geen middel waardoor een identificatie meer dan één instantie van een component produceert.
- Afwezigheid van instantieoverspraak. Het is niet nodig om een of meer andere instanties van een component te gebruiken om bij te dragen aan het identificeren van een instantie van een component.
- De eenheid en identiteit van datacomponenten/dimensies.
- Aanwezigheid van de-aliasing van componenten. Er moet één definitie bestaan waarmee een component/dimensie uniek kan worden geïdentificeerd. Wat is de primaire definitie van een component;
- waar de primaire definitie niet zal resulteren in het blootleggen van subdimensies of lidcomponenten die geen deel uitmaken van een beoogde component;
- Unieke manier van dealiasing van componenten. Er moet één, en slechts één, zo’n componentde-aliasingdefinitie voor een component bestaan.
- Er bestaat één en slechts één definitie-interface of contract om een bovenliggende component te identificeren in een hiërarchische relatie van componenten.
- Afwezigheid van overspraak van componenten. Er bestaat geen noodzaak om een lid van een ander onderdeel te gebruiken om bij te dragen aan de definitieve identificatie van een onderdeel.
- In een dergelijke ouder-kindrelatie mag de identificerende definitie van een ouder niet afhangen van een deel van de set lidcomponenten van een kind. Een lidonderdeel van de identiteit van een ouder moet de volledige identiteit van het kind zijn zonder toevlucht te nemen tot verwijzingen naar een of alle kinderen van een kind.
- Voorkom bimodale of multimodale verschijningen van een datamodel.
- Als er twee mogelijke definities van een component bestaan, is het een duidelijk teken dat er twee verschillende datamodellen zijn die als één worden verwisseld. Dat betekent dat er incoherentie is op datamodelniveau, of op veldniveau.
- Een toepassingsgebied moet op coherente wijze één en slechts één datamodel gebruiken.
- Detecteer en identificeer componentmutatie. Tenzij u een statistische componentanalyse van enorme gegevens hebt uitgevoerd, ziet u waarschijnlijk geen componentmutatie of ziet u de noodzaak om deze te behandelen.
- Het kan zijn dat sommige componenten van een datamodel cyclisch of geleidelijk muteren.
- De modus kan lidrotatie of transpositie-rotatie zijn.
- Lid-rotatie-mutatie kan duidelijk wisselen van onderliggende componenten tussen componenten zijn. Of waar volledig nieuwe componenten zouden moeten worden gedefinieerd.
- Transpositionele mutatie zou zich manifesteren als een dimensionaal lid dat muteert in een attribuut, vice versa.
- Elke mutatiecyclus moet worden geïdentificeerd als een afzonderlijke datamodaliteit.
- Versioniseer elke mutatie. Zodanig dat je een eerdere versie van het datamodel tevoorschijn kunt halen, wanneer het misschien nodig is om een 8 jaar oude mutatie van het datamodel te behandelen.
In een veld of raster van inter-servicing component-applicaties, moet er één en slechts één coherent datamodel zijn of bestaat er een middel voor een datamodel/versie om zichzelf te identificeren.
Vragen we nog steeds of we interfaceconstanten mogen gebruiken? Echt?
Er zijn problemen met gegevensnormalisatie die belangrijker zijn dan deze alledaagse kwestie. ALS je die problemen niet oplost, is de verwarring die je denkt dat interfaceconstanten veroorzaken relatief niets. Zilch.
Vanuit de normalisatie van het datamodel bepaalt u de componenten als variabelen, als eigenschappen, als contractinterfaceconstanten.
Vervolgens bepaalt u welke waarde-injectie, plaatsaanduiding voor eigenschapconfiguratie, interfaces, definitieve strings, enz. wordt gebruikt.
Als je het excuus moet gebruiken dat je een component moet vinden die gemakkelijker te dicteren is tegen interfaceconstanten, betekent dit dat je de slechte gewoonte hebt om datamodelnormalisatie niet toe te passen.
Misschien wil je het datamodel compileren tot een vcs-release. Dat je een duidelijk herkenbare versie van een datamodel kunt tevoorschijn halen.
Waarden die zijn gedefinieerd in interfaces zijn volledig gegarandeerd niet-veranderbaar. En deelbaar. Waarom zou je een set laatste strings in je klas laden vanuit een andere klas als je alleen die set constanten nodig hebt ??
Dus waarom dit niet om een datamodelcontract te publiceren? Ik bedoel, als je het coherent kunt beheren en normaliseren, waarom niet? …
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"
}
}
}
}
Ik kan nu verwijzen naar de gecontracteerde labels van mijn apps op een manier zoals
CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family
Dit verwart de inhoud van het jar-bestand? Als Java-programmeur geef ik niet om de structuur van de jar.
Dit geeft complexiteit aan osgi-gemotiveerde runtime swapping? Osgi is een uiterst efficiënt middel om programmeurs in staat te stellen door te gaan met hun slechte gewoonten. Er zijn betere alternatieven dan osgi.
Of waarom niet dit? Er is geen lekkage van de privé-constanten in het gepubliceerde contract. Alle privéconstanten moeten worden gegroepeerd in een privéinterface met de naam “Constanten”, omdat ik niet naar constanten wil zoeken en ik te lui ben om herhaaldelijk “private final String” te typen.
public class PurchaseRequest {
private interface Constants{
String INTERESTINGName = "Interesting Name";
String OFFICIALLanguage = "Official Language"
int MAXNames = 9;
}
}
Misschien zelfs dit:
public interface PurchaseOrderConstants {
public interface Properties{
default String InterestingName(){
return something();
}
String OFFICIALLanguage = "Official Language"
int MAXNames = 9;
}
}
Het enige probleem met interfaceconstanten dat het overwegen waard is, is wanneer de interface is geïmplementeerd.
Dit is niet de “oorspronkelijke bedoeling” van interfaces? Alsof ik me druk zou maken om de “oorspronkelijke bedoeling” van de grondleggers bij het opstellen van de Amerikaanse grondwet, in plaats van hoe het Hooggerechtshof de geschreven brieven van de Amerikaanse grondwet zou interpreteren ???
Ik woon tenslotte in het land van de vrijen, de wildernis en het thuis van de dapperen. Wees dapper, wees vrij, wees wild – gebruik de interface. Als mijn mede-programmeurs weigeren efficiënte en luie manieren van programmeren te gebruiken, ben ik dan door de gouden regel verplicht om mijn programmeerefficiëntie te verminderen om zich aan te passen aan die van hen? Misschien zou ik dat moeten doen, maar dat is geen ideale situatie.