De @Accessors-annotatie van Lombok gebruiken

1. Overzicht

Het is vrij typisch om te hebben krijgen en set methoden in ons domeinobjecten, maar er zijn andere manieren die we misschien expressiever vinden.

In deze tutorial leren we over Project Lombok's @Accessors annotatie en de ondersteuning ervan voor vloeiende, geketende en aangepaste accessors.

Voordat we verder gaan, moet onze IDE Lombok installeren.

2. Standaardaccessoires

Voordat we kijken naar de @Accessors annotatie, laten we eens kijken hoe Lombok de @Beter en @Setter annotaties standaard.

Laten we eerst onze klas maken:

@Getter @Setter openbare klasse StandardAccount {private String-naam; privé BigDecimal-saldo; }

En laten we nu een testcase maken. We kunnen in onze test zien dat Lombok typische getter- en setter-methoden heeft toegevoegd:

@Test openbare ongeldig gegevenStandardAccount_thenUseStandardAccessors () {StandardAccount account = nieuwe StandardAccount (); account.setName ("Basic Accessors"); account.setBalance (BigDecimal.TEN); assertEquals ("Basic Accessors", account.getName ()); assertEquals (BigDecimal.TEN, account.getBalance ()); }

We zullen zien hoe deze testcase verandert als we ernaar kijken @Accessor‘S opties.

3. Vloeiende accessors

Laten we beginnen met de vloeiend keuze:

@Accessors (vloeiend = waar)

De vloeiend optie geeft ons accessors die geen krijgen of set voorvoegsel.

We zullen de ketting optie in een oogwenk, maar aangezien het standaard is ingeschakeld, laten we het nu expliciet uitschakelen:

@Accessors (fluent = true, chain = false) @Getter @Setter openbare klasse FluentAccount {private String-naam; privé BigDecimal-saldo; }

Nu gedraagt ​​onze test zich nog steeds hetzelfde, maar we hebben de manier veranderd waarop we toegang krijgen tot en de status muteren:

@Test openbare ongeldig gegevenFluentAccount_thenUseFluentAccessors () {FluentAccount account = nieuwe FluentAccount (); account.name ("Vloeiend account"); account.balance (BigDecimal.TEN); assertEquals ("Fluent Account", account.name ()); assertEquals (BigDecimal.TEN, account.balance ()); }

Merk op hoe de krijgen en instellen voorvoegsels zijn verdwenen.

4. Geketende Accessors

Laten we nu eens kijken naar het ketting keuze:

@Accessors (chain = true)

De ketting optie geeft ons setters die terugkeren dit. Merk nogmaals op dat het standaard is waar, maar we zullen het expliciet instellen voor de duidelijkheid.

Dit betekent dat we meerdere kunnen ketenen set bewerkingen samen in één statement.

Laten we voortbouwen op onze vloeiend accessors en verander het ketting optie om waar:

@Accessors (fluent = true, chain = true) @Getter @Setter openbare klasse ChainedFluentAccount {private String-naam; privé BigDecimal-saldo; } 

We krijgen hetzelfde effect als we weglaten ketting en specificeer gewoon:

@Accessors (vloeiend = waar)

En laten we nu eens kijken hoe dit onze testcase beïnvloedt:

@Test openbare ongeldig gegevenChainedFluentAccount_thenUseChainedFluentAccessors () {ChainedFluentAccount account = nieuwe ChainedFluentAccount () .name ("Fluent Account") .balance (BigDecimal.TEN); assertEquals ("Fluent Account", account.name ()); assertEquals (BigDecimal.TEN, account.balance ()); }

Merk op hoe de nieuw verklaring wordt langer met de setters aan elkaar geketend, wat boilerplate verwijderen.

Dit is natuurlijk hoe Lombok's @Bouwer maakt gebruik van kettinged vloeiend accessors.

5. Voorvoegsel Accessors

En tot slot kunnen onze velden soms een andere naamgevingsconventie hebben dan we zouden willen laten zien via getters en setters.

Laten we eens kijken naar de volgende klasse die de Hongaarse notatie gebruikt voor zijn velden:

openbare klasse PrefixedAccount {private String sName; privé BigDecimal bdBalance; }

Als we dit zouden blootleggen met @Beter en @Setter, zouden we methoden krijgen zoals getSName, wat niet zo leesbaar is.

De voorvoegsel optie stelt ons in staat om Lombok te vertellen welke voorvoegsels we moeten negeren:

@Accessors (prefix = {"s", "bd"}) @Getter @Setter openbare klasse PrefixedAccount {private String sName; privé BigDecimal bdBalance; }

Laten we dus eens kijken hoe dat onze testcase beïnvloedt:

@Test openbare ongeldig gegevenPrefixedAccount_thenRemovePrefixFromAccessors () {PrefixedAccount account = nieuw PrefixedAccount (); account.setName ("Voorgeprogrammeerde velden"); account.setBalance (BigDecimal.TEN); assertEquals ("Voorgeconfigureerde velden", account.getName ()); assertEquals (BigDecimal.TEN, account.getBalance ()); }

Merk op hoe de accessors voor onze sName veld (setName,getName) laat de leidende positie weg s en de accessors voor bdBalance laat de leidende weg bd.

Echter, Lombok past alleen voorvoegsels toe als een voorvoegsel wordt gevolgd door iets anders dan een kleine letter.

Dit zorgt ervoor dat als we een veld hebben dat geen Hongaarse notatie gebruikt, zoals staat, maar begint met een van onze voorvoegsels, s, we eindigen niet met getTate ()!

Laten we tot slot zeggen dat we onderstrepingstekens in onze notatie willen gebruiken, maar deze ook willen volgen met een kleine letter.

Laten we een veld toevoegen s_notes met voorvoegsel s_:

@Accessors (prefix = "s_") private String s_notes;

Als we de regel voor kleine letters volgen, krijgen we methoden zoals getS_Notes (), dus Lombok past ook voorvoegsels toe wanneer een voorvoegsel zelf eindigt in iets dat geen letter is.

6. Configuratie-eigenschappen

We kunnen een project- of directory-brede standaard instellen voor onze favoriete combinatie van instellingen door configuratie-eigenschappen toe te voegen aan een lombok.config het dossier:

lombok.accessors.chain = waar lombok.accessors.fluent = waar

Zie de Lombok Feature Configuration Guide voor meer details.

7. Conclusie

In dit artikel hebben we de vloeiend, ketting, en voorvoegsel opties van Lombok's @Accessors annotatie in verschillende combinaties om te zien hoe dit de gegenereerde code beïnvloedde.

Bekijk voor meer informatie de Lombok Accessors JavaDoc and Experimental Feature Guide.

Zoals gewoonlijk is de bron voor dit artikel beschikbaar op GitHub.