Ano přiznávám se jsem staromilec. Možná dokonce i zpátečník. Mám rád get a set metody a nerad vidím snahu se jich zbavit. Občas se na internetových diskuzích setkám s návrhy jak „lépe“ řešit přístup k vlastnostem objektu. Dokonce se jeden takový návrh dostal do návrhu změn v Javě 7. Návrhy jsou podobné následujícímu: Místo private String foo; public String getFoo() {..} public void setFoo(String foo){..} budeme psát public property String foo; nebo ještě lépe @property private String foo; Tím si ušetříme spoustu práce s nudným psaním get a set metod. Kompilátor všechno krásně vygeneruje za nás. Nejvíc mi vadí to, že nikde nevidím problém, který se těmito návrhy má řešit. Nikdo přece už dávno get a set metody nepíše, všechno to za nás dělá vývojové prostředí. Napadá mě jediný argument, a to že tím pomůžeme Javě v nesmyslné válce o implementaci čehokoli na co nejméně řádek. Dosáhneme tím o trochu lepší výsledky při porovnávání počtu řádek s implementací v Ruby nebo C#. To si opravdu všichni myslí, že počet potřebných řádek kódu je to co určuje kvalitu jazyka? Zpět ale k uvedeným návrhům. Odhlédněme od toho, že ve skutečnosti neřeší žádný reálný problém. Podívejme se co by jejich přijetí znamenalo. Za předpokladu, že by za nás get a set metody generoval kompilátor bychom nezískali vůbec nic. To už rovnou můžeme psát public String foo; a přistupovat k poli přímo. Jediné v čem by nám „zjednodušený zápis“ mohl pomoci by mohlo být nějaké automagické sledování změn hodnot a generování příslušných událostí. To bych ale raději řešil aspekty. Co mi na druhou stranu get a set metody přinášejí? To samé co objektově orientované programování! Možnost skrytí implementace, možnost defenzivního programování a obecně možnost volby. Je totiž mnoho případů, kdy get a set metoda nejsou v té triviální podobě tak jak nám je generuje GUI. Často potřebuji zařídit, aby bylo pole jenom pro čtení. Například když píši neměnitelnou (immutable) třídu. V tom případě udělám set metodu private. Nebo ji udělám protected, když chci, aby ji mohly měnit jen spřátelené třídy. Už vidím návrh, že by se to dalo řešit takto: public property readonly change protected String foo; Krása. Neřeší to ale defenzivní programování. Případy, kdy místo public void setDate(Date date) { this.date = date; } píši public void setDate(Date date) { this.date = new Date(date.getTime()); } To za mě jazyk nemá šanci vyřešit. To si musím napsat sám. Počítač neví, že chci zabránit tomu, aby mi kdokoliv kdykoliv změnil datum, které mám uložené a proto si chci vytvořit defenzivní kopii. Podobně u vracení kolekcí neví, že nechci aby mi ji někdo měnil a chci ji vracet neměnitelnou. public List getList() { return Collections.unmodifiableList(list); } A to už vůbec nemluvím o kontrole vstupních parametrů přicházejících do set metody. Teď se můžeme začít hádat o procenta. Kolik je metod, u kterých mi stačí jednoduchý standardní tvar a kolik je těch, které potřebuji nějak modifikovat? Nemohli bychom náhodou tu většinu řešit magickou anotací a těch pár co potřebujeme změnit napsat postaru? Ne nemohli! Dostali bychom dva různé zápisy pro tu samou věc, museli bychom nějak řešit co dělat, když použijeme anotaci i get metodu a ze všeho by vznikl hrozný zmatek. Ano mohlo by to být stejné jako u implicitních konstruktorů, ale nemyslím si, že nám to všechno stojí za to, jenom kvůli pár ušetřeným řádkům kódu.