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

• #3308 Szmeby tag thon73 #3307

  Új Válasz 2015-08-08 10:19:03 #3308

  Ú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

  Privát üzenet küldése

  

  Szmeby

  tag

  válasz thon73 #3307 üzenetére

  "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