ugrás a tartalomhoz

High-quality Microsoft technology samples for Professional Developers

inf · 2016. Jan. 24. (V), 04.00
Kódminták gyűjteménye Microsoft technológiákhoz
 ■
1

Látva azt, hogy mostanában

Hidvégi Gábor · 2016. Jan. 24. (V), 10.31
Látva azt, hogy mostanában mit művel a Microsoft, a minőség szót egy lapon emlegetni velük kimeríti a gúnyolódás kategóriáját. Ez már nem ugyanaz a cég, amelyik az újításaival messze megelőzte a korát az Internet Explorer 4-5-6 sorozattal, hanem dilettáns hipszterek gyülekezete.

Kiváló példa a minőségre a Skype: a tipikus szoftver, ami minden verzióval csak rosszabb lesz.
  • Évekbe tellett kijavítani azt a hibát, hogy ne szivárogjon a memória, mert nap végére már négy-ötszáz megabájtot is megevett.
  • Évekbe tellett megcsinálni, hogy az Escape billentyű lenyomására megbízhatóan bezárja a chat ablakot.
  • Bizonyos partnereknél az üzenetek néha órák alatt érkeznek meg.
  • A képernyőmegosztás bizonyos gépeken nem működik, az első képkocka átvitele után nem küld többet.
  • Bizonyos partnereknél konferenciát csak egy bizonyos sorrendben lehet indítani.

Feltételezem, hogy a cégnél egységes minőségpolitika van, azaz minden szoftver fejlesztésénél vannak bizonyos követelmények. Ha a Skype-ból vagy a Windows-ból indulok ki, messze vannak attól, amit minőségnek lehet nevezni.
2

Ha ez neked annyira fáj,

inf · 2016. Jan. 24. (V), 19.07
Ha ez neked annyira fáj, akkor nyiss neki egy új témát, ne pedig másokét offold vele szét. Kösz!
3

De neki mindenhová le kell

bamegakapa · 2016. Jan. 24. (V), 21.04
De neki mindenhová le kell ezt írni, hátha egyszer végre mindenki belátja, hogy mindvégig neki volt igaza. Legyünk megértőek :P.
4

Oké

Hidvégi Gábor · 2016. Jan. 25. (H), 00.28
Igyekszem. Ettől függetlenül nézted te azokat a kódokat? Véletlenszerűen kiválasztottam egyet: imageQueryBuilder.js. Attól lesz egy metódus belső használatú, hogy a neve elé tesznek egy aláhúzást, és odaírják mellé, hogy "Internal method" (188. sor)? Ha belső használatú, akkor miért írhatja felül bárki?

Miért nem a hagyományos módon definiálnak belső változókat és metódusokat?
<script type="text/javascript">
  function obj() {
    var beallitasok = {};

    function beallitas(_tulajdonsag, _ertek) {
      if (_ertek === undefined) {
        beallitasok[_tulajdonsag] = _ertek;
      }
      return beallitasok[_tulajdonsag];
    }

    this.beallitas = beallitas;
  }

  var Obj = new obj;
  obj.beallitas('tulajdonság', 'érték');
</script>


Vagy statikus tagoknál "Type members are often called »static« members, though in JavaScript they are not actually static.".
Ha nincsenek JS-ben statikus tagok, akkor miért nevezzük úgy őket? Ez félrevezető lehet sokak számára.

Miért használnak .forEach metódust, amikor egyrészt kevesebbet tud, mint egy hagyományos for ciklus (nincs benne a break-hez hasonló funkció), valamint akár tízszer lassabb hozzá képest?

Kíváncsiságból utánaolvastam a WinJS.Class-ban pár dolognak. A Custom types and WinJS Class oldalon például a következőképp ad új tagot a Robothoz:
Object.defineProperty(Robot.prototype, "modelName", {
    get: function () { this.computeModelName(); }
});

Ennek mi az előnye a következőhöz képest?
Robot.prototype.modelName = {
    get: function () { this.computeModelName(); }
};


Vagy vegyük az oldal végén lévő örököltetést. Miben jobb az a következőnél?
function SpaceRobot(_name) {
  this.name = _name;
}
SpaceRobot.prototype = new Robot();
SpaceRobot.prototype.constructor = SpaceRobot;
SpaceRobot.prototype.airSupply = '';
SpaceRobot.prototype.saveSelf = true;

Csak azért kérdem, mert a WinJS.Class.derive oldalán semmilyen információt nem lehet olvasni arról, milyen dolgokat művel a derive a kapott paraméterekkel. Aggat rájuk más metódusokat, tagokat? Ha igen, miért nincs leírva? Ha nem, miért használjuk egyáltalán?

(Szerkesztve: közben utánaolvastam, hogy a SpaceRobot.prototype = new Robot(); nem túl szerencsés, ha a konstruktornak vannak mellékhatásai.)
5

Egy kódot néztem, mert nekem

inf · 2016. Jan. 25. (H), 01.28
Egy kódot néztem, mert nekem az éppen hasznos volt. Nem volt vele semmi gondom. Ennyi.
6

Object.defineProperty(Robot.p

Poetro · 2016. Jan. 25. (H), 18.26
Object.defineProperty(Robot.prototype, "modelName", {
    get: function () { this.computeModelName(); }
});
Ennek mi az előnye a következőhöz képest?
Robot.prototype.modelName = {
    get: function () { this.computeModelName(); }
};

Az az előnye, hogy a new Robot().modelName automatikusan meghívja a computeModelName metódust, anélkül, hogy neked explicit meg kellene hívni. Ezen kívül a te általad javasolt, egy teljesen más objektum architektúrát eredményez, ahol a modelName-nek van egy get metódusa, míg a Object.defineProperty a modelName nem listázandó, nem módosítható stb.
7

Így világos, köszönöm, és ez

Hidvégi Gábor · 2016. Jan. 25. (H), 19.55
Így világos, köszönöm, és ez miben jobb annál, mintha egy adattagot függvényeken keresztül írok, olvasok?
8

Semmiben

vbence · 2016. Jan. 25. (H), 21.07
max, hogy a kódod kevésbé lesz portolható, mert nem minden nyelvben vannak propertyk.
9

Az ilyen property-k

Hidvégi Gábor · 2016. Jan. 25. (H), 21.36
Az ilyen property-k hibakeresése jól megoldott?
11

Hogyan portolnád a kódot

Joó Ádám · 2016. Jan. 26. (K), 01.35
Hogyan portolnád a kódot nyelvek közt? Ha arra gondolsz, hogy az API nem feleltethető meg egy az egyben két különböző nyelvű implementáció esetén, azt egyrészt az API felhasználójaként nem érzem problémának, másrészt szinte elkerülhetetlen.
10

Hogy kezdetben nem kell

Joó Ádám · 2016. Jan. 26. (K), 01.29
Hogy kezdetben nem kell megírnod a függvényeket, csak ha idővel írás-olvasás helyett valami mást akarsz csinálni a tulajdonság használatakor. Ilyenkor a változás nem érinti azokat, akik használják a kódod.
12

Elsőre nem tűnik túl erős

Hidvégi Gábor · 2016. Jan. 26. (K), 10.04
Elsőre nem tűnik túl erős érvnek. Egyrészt a mass replace-t már ezer éve kitalálták, másrészt komplexitást rejt el. Ha függvényt hívsz, arról feltételezheted, hogy megváltoztathatja egy objektum állapotát, de egy adattag értékének közvetlen állításakor ez nem feltétlenül igaz.
13

Pedig az előző hozzászólásod

Joó Ádám · 2016. Jan. 26. (K), 15.14
Pedig az előző hozzászólásod alapján már elfogadtad a universal access principle-t, hisz a konzisztensen függvényeken keresztül végzett írás-olvasás célja is ez. A property szintakszis csupán segít elkerülni a függvények megírását, ahol az felesleges.

Az, hogy elfedi a komplexitást, egy ismert velejárója, ilyenkor az adott művelet komplexitása dokumentálható. Ez a bizonytalanság egyébként nyelvi szinten is ismert, a tömbhossz a klasszikus példája, ami általában tulajdonságként érhető el, de legalább egyszer minden programozó elgondolkodik rajta, hogy nem kellene-e tárolni a ciklus előtt.

A mass replace pedig még ha nem is vezet be hibát sehol, akkor is minden hívó újrafordítását eredményezi, míg ha változatlan marad az API, akkor elég az újralinkelés.
14

Az, hogy elfedi a

Hidvégi Gábor · 2016. Jan. 26. (K), 16.49
Az, hogy elfedi a komplexitást, egy ismert velejárója, ilyenkor az adott művelet komplexitása dokumentálható.
Akkor ez egy nagyon rossz gyakorlat, ráadásul nem is lesz intuitív a kód.
15

Minden függvény elfedi a

Joó Ádám · 2016. Jan. 26. (K), 17.09
Minden függvény elfedi a műveleti komplexitást. Hogy O(1) vagy O(n!) azt csak a dokumentációból tudhatod.
16

Nem, én a setter/getter

Hidvégi Gábor · 2016. Jan. 26. (K), 17.33
Nem, én a setter/getter függvényekre gondoltam, amiket adattagok írásakor/olvasásakor hívunk.

Ha nincsenek publikus adattagok, csak függvények, akkor van okod feltételezni, hogy más is történik. Ezért írtam, hogy a setter függvények nem intuitívak, ugyanis ránézésre egy külső adattag írásakor nem tudod megmondani, hogy fog-e egyéb függvény lefutni a háttérben.
17

Ezért írtam, hogy a setter

Joó Ádám · 2016. Jan. 26. (K), 17.41
Ezért írtam, hogy a setter függvények nem intuitívak, ugyanis ránézésre egy külső adattag írásakor nem tudod megmondani, hogy fog-e egyéb függvény lefutni a háttérben.


Ezt semmilyen függvény hívásakor nem tudod megmondani, miért pont a settereknél hiányolod?
18

$Objektum->tulajdonsag =

Hidvégi Gábor · 2016. Jan. 26. (K), 18.00
$Objektum->tulajdonsag = 5;
$Objektum->setTulajdonsag(5);

Amikor átnézed a kódot, az elsőnél azt várod, hogy az objektumnak csak a tulajdonsag adattagja fog változni, a második esetben viszont bármi történhet, azaz más állapot is megváltozhat. Ekkor nyilvánvaló, hogy a setTulajdonsag metódusba is bele kell nézni hiba esetén.

Az első sorra ránézve nem derül ki, hogy van mögötte setter, ezért írtam, hogy nem intuitív a használata.
19

Értem, amit mondasz, csak

Joó Ádám · 2016. Jan. 26. (K), 18.11
Értem amit mondasz, csak arra próbállak ráébreszteni, hogy egy tulajdonság írása egy adattípus felhasználója szemszögéből pont ugyanolyan művelet mint bármilyen másik, és így önkényes ettől az egytől várni, hogy garanciát adjon a műveleti komplexitásra.

Visszatekintve jobb lett volna, ha a nyelvek tervezői soha nem különböztetik meg az operátorokat az eljárásoktól, akkor nem zavarna meg az intuíciód.
21

Így viszont zavar

Hidvégi Gábor · 2016. Jan. 26. (K), 18.27
Ennek az egésznek hibakeresés során van jelentősége, azt viszont a fentiek miatt nehezítheti, ha az ember nem ismeri teljes egészében a kódot.
20

Best practice: kerülni kell a

MadBence · 2016. Jan. 26. (K), 18.22
Best practice: kerülni kell a költséges implementációkat (tipikus példa: DOM innerHTML property), illetve nyilván egy getternek nem illik módosítania az objektum állapotát. Viszont egy setter esetén pl sokkal kényelmesebb API-t kapunk (tipikus példa: koa). Azt, hogy egy property írásától "mit várunk el", az meg rajtunk múlik: elolvassuk-e az API dokumentációt/forráskódot, vagy sem.
22

A kényelemnek mindig ára van,

Hidvégi Gábor · 2016. Jan. 26. (K), 18.40
A kényelemnek mindig ára van, ami jelen esetben további komplexitás a kódban a fentebb leírtak miatt, komplexitás a futtatókörnyezetben, emellett a setter függvényeknek, ha jól sejtem, csak egy paramétert lehet adni.