Új hozzászólás Aktív témák

• Szmeby tag

  #3308

  #3307 thon73

  2015-08-08 10:19:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Szmeby

  tag

  #3307 thon73

  #3307 thon73

  Köszönöm. Bár ezzel a válasszal nem sokra mentem.

  Megpróbálom kicsit érthetőbben elmagyarázni. Az InputMethodService több billentyűzet adatait tartalmazza a nagyjából a következő módon:

  InputMethodService - KeyboardView - GeneralKeyboardData - Keyboard - Button - Text

  Természetesen egy kicsit összetettebb az egész, de a sor minden egyes gomb esetén ezen alaposztályok leszármazottaiból áll össze. A sor végén álló "Text" pl. definiálja az "A" karaktert (néhány egyéb tulajdonsággal, pl. hogy . után legyen nagy, meg ilyesmi.)

  A mi szempontunkból az egyetlen lényeges dolog, hogy amikor a "Text" osztály el szeretné küldeni az 'A' karaktert, akkor az InputMethodService osztály metódusaira van szüksége. (Amire viszont senki másnak.)

  Eddig pont ugyanúgy oldottam meg, ahogy pl. a Context-nél történik (Tehát nem a service-t szerettem volna contextből kinyerni.), vagyis az InputMethodService szépen végigutazott az egész soron, és az összes "Text" példány tárolta a hivatkozást, hogy tudjon kommunikálni.

  A változáson pedig azért kezdtem el gondolkodni, mert szerettem volna az egész adatstruktúra legenerálását leválasztani a Service-ről. Emiatt viszont az InputMethodService nem áll rendelkezésre akkor, amikor az adatstruktúra elkészül.

  Több lehetőséget találtam:
  Amikor a kész adatstruktúrát a Service-hez kapcsolom, végigmegyek az összes elemen és megadom az InputMethodService-t.
  Vagy egyedül a GeneralKeyBoardData (az adatstruktúra legalsó eleme) kapja meg, és a Text ettől kérdezi le.
  Vagy valahogy kiszedem az InputMethodService hivatkozását magából az InputMethodService-ből, amiből egyébként egyetlen van, és addig folyamatosan él, amíg nem váltok másik billentyűzetre (ilyenkor viszont az adatstruktúra sem létezik tovább.)

  Amúgy eddig az "erőltetett objektumokkal" szépen működik, de azt gondoltam, kell legyen ennek egyszerűbb módja is. Csak éppen még nem jöttem rá, mi az, ezért kértem segítséget az utolsó elgondoláshoz.

  ((A fentiektől függetlenül filozófiailag "sok hülye meg erőlteti itt az objektumokat" kijelentésnek igen komoly háttere van. Nagyon sok, nálamnál sokkal komolyabb programozó vitatja az objektum-orientált programozás előnyeit szemben a hagyományos, lineáris programozással. Mielőtt mindenki nekem ugrana és szétszedne, nem állást foglaltam mellettük, csak tényként megemlítettem ezt az iskolát is. Én ugyan nem tudom megítélni, de valószínűleg amúgy a java egy objektum-orientált android környezetben nem is alkalmas erre.))

  "Bár ezzel a válasszal nem sokra mentem."
  Szóval van állapota? Van unit teszt?

  De mindegy is, inkább írok.
  A singleton önmagában nem ördögtől való. Probléma akkor lehet, ha van állapota, és azt a tőle függő komponensek változtathatják. Ugyanis ha a sigletonban van field, és az nem csak olvasható, akkor nem tudod előre megjósolni, hogy a singletonod éppen milyen állapotban van, mivel azt a komponensek kedvük szerint állítgatják. Sztochasztikussá válik a viselkedése. Ugyanez igaz a random vagy az idő használatára is. A random viselkedés pedig rejtett bugokat szül.
  Info: shared global state

  Tegyük fel, téged ez a veszély nem fenyeget, mert nincs benne field, vagy az csak olvasható. Ilyenkor még mindig probléma lehet, ha a singletont használó osztályaidat (unit) tesztelni akarod. Pl.:
  public class MyClass {
  
  //...
  
  public String doingSomethingCool(String id) {
  Entity e = MyDatabaseAccessorSingleton.getInstance().findById(id);
  // ...
  return coolStuff;
  }
  }

  Hogyan teszteled a metódust, ha nem szeretnél mellette egy működő adatbázist is futtatni. Sajnos sehogy.

  Lehetséges megoldás:
  public class MyClass {
  private final MyDatabaseAccessorSingleton db;
  
  public MyClass(MyDatabaseAccessorSingleton db) {
  this.db = db;
  }
  
  //...
  
  public String doingSomethingCool(String id) {
  Entity e = db.findById(id);
  // ...
  return coolStuff;
  }
  }

  A teszt immáron helyettesítheti az adatbázisos objektumot egy teszt double (mock) példánnyal. Ez esetben viszont már megkérdőjelezhetővé válik, hogy valóban szükséges-e singletonként definiálni azt. De ez már messzire mutat.

  Leszámítva a fenti két problémát a singleton egy tök jó pattern, és bátran alkalmazhatod, ha szükségét látod. Csak ésszel kell csinálni.

  Ez talán válasz arra a kérdésedre, hogy a contextet miért nem oldották meg így. A contextnek szerintem van változó állapota. Ebből singletont csinálni egyenlő a káosszal.

  -----

  Áttérve a konkrét problémára. Sajnos tényleg nem ismerem az android architektúráját, és lehet, hogy a singletonnal jársz jobban. Ezt megerősíteni és cáfolni sem tudom. Majd a tapasztalt androidosok biztos leírják a véleményüket.

  Remélem, nem értelmezem félre a dolgot, de nekem az jött le, hogy az InputMethodService megsérti az SRP principlet, mert nemcsak az a dolga, hogy felépítsen egy billentyűzetet (KeyboardView - GeneralKeyboardData - Keyboard - Button - Text), hanem ki is kell szolgálnia a billentyűzetre tapicskoló eventeket. Ezt talán célszerű lenne két külön osztályban megvalósítani. Talán te is pont ezt írtad.
  Legalábbis ha jól értem, hogy az "adatstruktúra" alatt a billenyűzetet érted, rajta a gombokkal, textekkel.

  Véleményem szerint az elnevezések alapján az event fogadása nem feltétlenül a text feladata, hanem a buttoné. Legalábbis ha én olvasok egy kódot, akkor arra számítok, hogy a text csak a gombon lévő szöveg tartalmáért felel, annak stílusáért, stb. Az esemény pedig a gombon keletkezik. De ez akár elnevezési probléma is lehet. Én mindenesetre a gombra fogok hivatkozni, a textet nagyon nem ideillőnek érzem.

  Szóval a gombok event listenere pedig továbbpasszolja az eseményt egy event handlernek (talán az InputMethodServicenek?), ami elvégzi a gombnyomás mögé rejtett logikát. A gombnak tehát szüksége van ebből egy példányra, hiszen mit ér a gomb, ha nem csinálhat semmit.
  Nincs sok lehetőség:
  1. Leküldöd a billentyűzet legyártásakor minden gombnak ezt a referenciát.
  2. Vagy csak a GeneralKeyBoardDatáig. Bár akkor a GeneralKeyBoardData példányt kell majd továbbpasszolnod a gombok felé, hogy azok lekérdezhessék. Tehát ígyis-úgyis utazik lefelé egy referencia, így ha ez a megoldás nem hoz látható javulást, akkor nem éri meg, csak ront az átláthatóságon.
  3. Használod a gombban a singletont.
  4. Használsz valamilyen android hókuszpókuszt. Az előző hozzászólásomban a contextre gondoltam, legalábbis a neve alapján arra asszociáltam, hogy ezen keresztül elérhetők ill. elérhetővé tehetők a szükséges komponensek. A válaszodból az jött le, hogy nem.

  "Vagy valahogy kiszedem az InputMethodService hivatkozását magából az InputMethodService-ből"
  Ezt nem értem, itt a singleton.getInstance()-ra gondoltál, ugye?

  Nekem ez az egész egyébként UI-szagúnak tűnik, és backend fejlesztőként én úgy gondolom a UI-t nem is igazán kell tesztelni. Legalábbis nem így. Állapota meg biztos nincs, ugye? Szóval menjen az a singleton!

  Sajnálom, hogy nem tudtam érdemben segíteni, csak a java oldalt ismerem.

  Senki sem fog programozási paradigmákról flame wart indítani, annyi féle létezik, imperatív, deklaratív, oo, stb, egyesek valamennyire átfedésben vannak másokkal, mindegyiknek van előnye és hátránya, ostobaság lenne erről vitatkozni. A programozás úgyis arról szól, hogy kiválaszd a neked/projektnek megfelelőt, és megtanulj együtt élni a hátrányaival.
  Vagy készítesz egy új programnyelvet, új megoldásokkal, és majd csak utána jössz rá, hogy a többinél nem jobbat alkottál, csak másabbat.
  Szóval a "komoly" emberek vitassák bátran az oo-t, ha nincs jobb dolguk. Én is fel tudok hozni egy csomó hátrányt az OOP-ben, de ugyanúgy a funkcionális nyelvekben is, stb. De miért tenném? A világ nem lesz jobb, ha elkezdek fikázni egy paradigmát, vagy egy nyelvet.
  Amit viszont én írtam (static hívások, globális állapottal, javaban) az egy erősen kisarkított példa volt, természetesen ironizáltam. Bele kell törődni, hogy a java egy oo nyelv, és a szabályokat ugyan meg lehet szegni, csak hosszútávon legtöbbször nem éri meg.

  A "lineáris programozás" alatt mit értesz?

Új hozzászólás Aktív témák