Skip to end of metadata
Go to start of metadata

Mivel a Java nyelv egy évtizedig nem tartalmazott enumerációs típusokat, az ötös Java verziótól bevezetett enum kevesek által használatos, és még kevesebbek által használatos igazán jól. Induljunk egy olyan enum típusból, amely a négy égtájat hordozza magában, s emígy néz ki:

public enum Direction
{
NORTH,
SOUTH,
EAST,
WEST,
}

Ez egy szimpla enum deklaráció, azonban az enum hordozhat metódusokat is:

public enum Direction
{
  NORTH,
  SOUTH,
  EAST,
  WEST;
   
  public Direction getOpposite()
  {
    return [...];
  }
}

A probléma az, hogy az adott égtájjal szembeni égtájat nem tudjuk megadni egyszerűen. Ezért próbálkozhatunk azzal, hogy egy konstruktort is elkészítünk az enum osztályunkhoz:

public enum Direction
{
  NORTH(SOUTH),
  SOUTH(NORTH),
  EAST(WEST),
  WEST(EAST);

  Direction opposite;

  Direction(Direction opposite)
  {
    this.opposite = opposite;
  }

  public Direction getOpposite()
  {
    return opposite;
  }
}

A fenti programmal a probléma, hogy a SOUTH referenciára előbb hivatkozunk, mint ahogy az deklarálva van. Egy apró kis csellel megoldható azzal, hogy röptében deklaráljuk minden egyes enum osztály getOpposite metódusát:

public enum Direction
{
  NORTH { public Direction getOpposite() { return SOUTH; } },
  EAST { public Direction getOpposite() { return WEST; } },
  SOUTH { public Direction getOpposite() { return NORTH; } },
  WEST { public Direction getOpposite() { return EAST; } };
   
  public abstract Direction getOpposite();
}
      
      
Page viewed times

21 Comments

  1. Unknown User (frimen)

    Tudna valaki értelmes példát irni, amikor használta ezt a tipust, ugyanis az ilyen hülye-gyerek tipusú példákkal az a baj, hogy nem sok "élet" szaga van.

    1. Auth Gábor AUTHOR

      Tudna valaki értelmes példát irni, amikor használta ezt a tipust

      Adatbázisoknál alapvető, sőt: nélkülözhetetlen. (smile)

  2. Anonymous

    valami piszokul gyakran, peldaul egy hibernate takom-bakom:

    public enum UserType {
     ADMIN,
     GUEST,
     SUBSCRIBER,
     TRIALIST,
     HAXOR
    }
    @Entity //perzisztens mint allat
    public class User {
     @Enum //a tobbit meg lesz@rjuk...
     UserType type;
     String name;
     //getterek, setterek
    }

    Az enum kiraly dolog.

    1. Unknown User (frimen)

      Köszi.. ettől féltem.:)

      Ismét sikerült valami piszok szart megvalósítást összehozniuk. Szóval marad a rég bevált módszer, és ezután sem fogok sokat foglalkozni vele..

      1. Anonymous

        Frimen, neked tanitanod kellene. Mindenki tanit aki ilyen hulye :)
        1. Unknown User (frimen)

          Hülye vagyok? :)

          No és mond miért?

        2. Auth Gábor AUTHOR

          Mindenki tanit aki ilyen hulye :)

          :)))))))))))))))))))))
          Köszönöm a bókot... :D

    2. Unknown User (frimen)

      És hogy hozzátegyek egy hátrányt, ez a szánalmas kód:

      public enum UserType {
       ADMIN,
       GUEST,
       SUBSCRIBER,
       TRIALIST,
       HAXOR
      }

      összesen 1231 byte lefordítva, tömören pedig +944 byte... nevetséges!

  3. Anonymous

    Simán hasznos az enum! Leginkább akkor értékelhető, ha már valaki találkozott a static final integer enum (anti)pattern hátulütőivel:
    -nemcsak az érvényes értékeket írhatod be hanem bármit.
    -toString-nél semmitmondó int értékeket ad vissza.
    -hosszabb távú serializációnál gondok lehetnek, ha közben megváltoznak az értékek.
    -gondok lehetnek, ha nem együtt fordítják a konstansokat definiáló osztályt (interfészt) a kliens osztállyal. konkrétan, a kliens osztályban benn maradnak a régi értékek.

    Vannak még további hátrányok is, most hirtelen ennyit tudok felidézni. Az enum hátránya, hogy nem lehet byte maszkosat játszani vele. Azt nem tudom mennyivel nagyobb az erőforrásigénye, de az is egy hátrány.

    tvik

    1. Anonymous

      Frimen: A memóriaigényt is erőforrásigénynek értettem. Természetesen ha csak makróként akarsz használni egy konstanst, akkor nem éri meg. De pl. egy

      for(UserType u : userTypeCollection) System.out.println(u);  

      -hez hasonló lehetőség elég hasznos tud lenni.
      Ha kézzel csinálod meg a Sysout-okat switch case-zel vagy akárhogy, még több bájtba kerül.
      tvk

      1. Unknown User (frimen)

        A memóriaigényt is erőforrásigénynek értettem.

        Jól értetted, hisz a kettő összefügg: nagyobb objektum/osztály = nagyobb erőforrás/lassabb kód.
        Elvégre egy class-al oldották meg az enum tipust, ami "elvileg" jó, mert több lehetőséget add,
        és ha már oo nyelvről van szó.. de ezzel az a probléma (azokon túl amiket valaki (lehet Te))
        leirtál [ma 10:59], hogy szerintem pazarlás..
        Ez nem előrelépés.. én személy szerint jobban örültem volna valami "primitiv"-ebb megvalósításnak.

        Ha kézzel csinálod meg a Sysout-okat switch case-zel vagy akárhogy, még több bájtba kerül.

        Ezzel azért erősen vitatkoznék! :-)

    2. Anonymous

      ...már valaki találkozott a static final integer enum (anti)pattern hátulütőivel

      tvik: szolj ha tevednek, de ez az amikor egy interface-ba felsorolod a public static final integer NAGYBETUSKONSTANS dolgokat.Ezekre teljesen passzolnak azok a hibak amiket leirtal.

      És hogy én is hozzátegyek egy hátrányt

      Tvik lejjebb a hosszu felsorolasban nem az enum-ok hatranyait sorolta fel. (A bytemaszkos dolog szerintem megoldhato)
      Az a baj, hogy mar eleve ugy tetted fel a kerdest, hogy te ennel mar sokkal okosabb dolgot tudsz, a valaszt mar el sem olvastad, a peldamat ami egyebkent tenyleg egyszeru (de hat milyen legyen egy pelda) meg leszanalmasoztad. Tanulopenz, legkozelebb magyarazzon el neked barmit is az akinek nincs jobb szorakozasa :)

      Kocka

      1. Anonymous

        Kocka: Erre gondoltam, de nem az az antipattern pontos neve amit írtam. Csak a hasamra ütöttem. Azt hiszem a pontos név Constant Interface Antipattern.

        Frimen: Én is jobban örültem volna primitívebb megoldásnak, de a mocsokszarozásnál azért szerintem tegyük magasabbra a lécet. :)

        tvik

        1. Unknown User (frimen)

          Én is jobban örültem volna primitívebb megoldásnak,

          Legalább egy valamiben egyetértünk..:)

          de a mocsokszarozásnál azért szerintem tegyük magasabbra a lécet. :)

          Tegyük... de nem tudok nem mocsok-szarozni, mert szerintem a java elég rossz irányba megy sok tekintetben..

      2. Unknown User (frimen)

        akkor én értelmeztem rosszul.. nem nagyon néztem még meg az enum-ot, mert megvoltam eddig is nélküle. Egyébként meg tényleg kösz a magyarázást.. igaz még nem tudom mire tudom használni.. Egyébként, hogy a pénzedért kapj is valamit:

        interface-ba felsorolod a public static final integer NAGYBETUSKONSTANS

        - interface-ben Integer-t használni int helyett elég gáz..

        - nemcsak az érvényes értékeket írhatod be hanem bármit.

        Ez szerintem nem mindig probléma, ill. nem árt néha megvizsgálni milyen értéket állít be valami

        - toString-nél semmmitmondó int értékeket ad vissza.
        - hosszabb távú serializációnál gondok lehetnek, ha közben megváltoznak az értékek.
        - gondok lehetnek, ha nem együtt fordítják a konstansokat definiáló osztályt (interfészt) a
        - kliens osztállyal. konrétan, a kliens osztályban benn maradnak a régi értékek.

        Erre inkább nem reagálok.. se füle se farka.. de igaz, a java is és a legtöbb nyelv is afelé megy, hogy a programozoknak minnél kevésbé kelljen megtanulni programozni, minnél többet megoldjon a nyelv..

        1. minnél kevésbé kelljen megtanulni programozni, minnél többet megoldjon a nyelv.

          Vagy hogy ne kelljen mindig ugyanazt a problemat megoldani, es a tenyleges feladatra koncentralhass, ez minden magasszintu programozasi nyelv egyik torekvese, mig az alacsonyszintuek inkabb a trukkos optimalizacioknak adnak helyet. Maganvelemenyem.

          1. Unknown User (frimen)

            Vagy hogy ne kelljen mindig ugyanazt a problemat megoldani, es a tenyleges feladatra koncentralhass, ez minden magasszintu programozasi nyelv egyik torekvese, mig az alacsonyszintuek inkabb a trukkos optimalizacioknak adnak helyet. Maganvelemenyem.

            Egyetértek és még sem... mert pölö, ha a hihetetlenül magas szintű java nyelv magas szintű megoldásait használnám fel abban a  programban amit irok, akkor felköthetném magam, mert a kod kiló/megabájtokkal nagyobb lenne.. és sokkal lassabb.

            1. gondolom micro edition
            2. Anonymous

              Egyébként nem kötelező enum-okat használni, van amikor nem is ajánlják.
              tvik

    3. Anonymous

      Az enum hátránya, hogy nem lehet byte maszkosat játszani vele. Azt nem tudom mennyivel nagyobb az erőforrásigénye, de az is egy hátrány.

      Ez ebben a formában hamis. Lehet vele bitmaszkosat játszani! :-) Lásd EnumMap, EnumSet típusok. Azok amikor lehetséges bitmaszkot használnak.

      1. Na jó, pongyolán fogalmaztam.

        Atomi típusokon végzett ~|& műveletekre gondoltam, ahol nem mellékes hogy az eredmény is atomi típus.