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

• axioma veterán

  #10246

  #10245 Drizzt

  2019-01-20 10:59: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

  

  axioma

  veterán

  #10245 Drizzt

  #10245 Drizzt

  Alapvetően probléma nincsen vele, de én inkább csinálnék egy másik mátrix típust(Matrix), ami teljesen a ProjMatrix implementációitól. És akkor nem lenne generikus a ProjMatrix interface, a getUnderlying helyett meg lenne egy Matrix getMatrix. És az egyes implementációknak lenne az az implementation detail-je, hogy a belső saját mátrixából hogyan fog mátrixot csinálni, factory-kal, különböző bemenő adatok alapján. Pl.: lenne egy ilyen a Matrix createMatrix(double[][] mtx), illetve valami más értelmes adat. A konstruálás paramétereit mindig az vezényelje, hogy milyen adataid lesznek ahol felhasználod ezt az interface-et.

  Működni tökéletesen működni fog amit csináltál, viszont az nem fog nekem tetszeni, hogy a felhasználó kódnak végül mindenképpen tudnia kell a konkrét implementáló osztályokról, mert van olyan method az interface-ben, ami implementáció specifikus értéket vár/ad vissza. Így nem tudod pl.: ServiceLoaderrel betölteni az implementációkat, hanem minden új implementációnál újra kell majd fordítanod a kódot. Ami nem feltétlenül probléma, de egy megfontolandó dolog.

  Ami sérül ebben az interface-ben, az a SOLID design elvekben a "dependency inversion principle". Nem jó practice, ha az interface felhasználója bármilyen specifikus dolgot kell tudjon az implementációból(esetedben az M típust).

  Itt most azert kell a generic, mert ahogy latszik is, pl. az add az direkt csak a sajat underlying-jait tudja osszeadni. Tehat egy kod nem keverheti az underlying-okat, mert pont az a lenyeg hogy ne legyen az egesz lehuzva a get(x,y) szintjere, hanem a meglevo megvalositas "teljes erejet" hasznalja ki. Senki nem is fog es nem is akar olyat irni, hogy nd4j matrixot adunk az apache-oshoz.
  A cel nem az, hogy az interface elrejtse a megvalositast, csak hogy lehessen idovel cserelni alatta. De kozben nem fogjuk kidobni az nd4j sebesseget... [idokozben atment vegre a 3rd party engedelyezesen], meg az esetleges kesobbi GPU-val gyorsitast. Ugy kell elkepzelni, hogy a program egy futasa alatt a megvalositasok kozul mindig csak egy letezik, jojjon az barhonnan, es mint ProjMatrix tipusu valtozok lesznek kezelve [igen, van ProjMatrixUtils is create-tel... az interface amugy nekem kivulrol jon mint input, nem mondom hogy nem szolhatok bele - bar amikor probaltam, hogy ha csak 2dim matrixaink vannak, talan nem kene-e az interface-t se altalanos n-dim-nek csinalni, foleg ha a ket "gyari" megvalositas egyike alapbol se kepes ra... de siman lepattantam], egy teljes refactort tuti nem tudnek atvinni. A ...Utils-t bovithetem, masikat nemigen. Es en kell az implementaciokat csinaljam, a flatmatrix csak azert merult fel, mert az apache-t akartam "legyorsulni" (az nd4j-t mar vszinu nem fog sikerulni, bar majd meglatjuk, mivel naponta es hosszan futo job-rol van szo, csak az azon mert sebesseg szamit, nem az "altalanos").

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