Sokak által lesajnált Delphi vs C#/WinForms

"mert az összes 3rd party lib-et még nem ismerem..."

Nah, engem meg többek között ez riaszt el a "Java economy"-tól. Szétszórt, bazári, kívülről. Egyszer kaptam egy Java-s SOAP-s tesztprogramot, 10 megás JAR fájl volt, lényegi része kb. 20 sor a main() metódusban.

(Illetve már ott is voltak cifra dolgok, mint pl. a Main metódusban csak példányosítunk egy objectet és meghívunk rajta egy metódust, aminek következtében így nézett ki a kód:

class Main
{
  public static main(String[] args) {
    Main main = new Main();
    main.Main();
  }

  private void Main() {
    // Lényegi részek, kb. 20 sor.
  }
}

Az egészben az volt a legszebb, hogy ha lett volna normális WSDL fájl, tetszőleges random IDE-be behúzva meg tudtam volna írni ugyanazt a 20 sort.

----------------
Lvl86 Troll

Miért, mibe kezdjem, ha mögöttes, működő kódot is mögé szeretnék rántani, ami rendes, valós adatokkal operálna? :)

----------------
Lvl86 Troll

XAML: XML. Minek? (Igen, tudom, Delphinél is ott volt a DFM, azért picit más volt az).
MVVM: Ordasmód túlbonyolított, és gigantikus mértékű felesleges kódtömegeket kell írni, amely nem picit megnehezíti a karbantartást, többek között. Tudom, nagyon nem egészen ugyanaz, de pl. egy Delphi-s ActionManager szerintem használhatóbb lenne. Ha használnom kell, inkább olyan érzésem van, hogy egy halom plusz terhet ad a nyakamba az esetek legnagyobb részében egy viszonylag elenyésző előnyért (amely egyébként a régi modellben is tök jól működhetne annak kisebb-nagyobb javítása után), ahelyett, hogy segítené és gyorsítaná a munkám.

Amikor egy gomb felhelyezése, és a hozzá tartozó eseménykezelő megírása között nekem meg kell írni vagy 30-40 sornyi kódot, akkor szerintem ott valami baj van.

Mondjuk az egész már ott el van kúrva, hogy az egész desktopon bejáratott modelleket megpróbáljuk egy az egyben átültetni webre elfedve a két platform közötti ordító különbségeket.

----------------
Lvl86 Troll

Kifejtenéd, kérlek?

----------------
Lvl86 Troll

Nah, neked is sikerült a lényeget kiragadnod a mondandómból. :) Nem a propertykről lenne szó, hanem, az osztályhoz tartozó metódusokról, ill. azok kiszervezéséről.

Na de hogy a hozzászólásodra válaszoljak: C++ és Java-val az a gond, hogy nincs nyelvi szinten property (MSVC++-t most picit hagyjuk), legalábbis olyan szinten, mint C#-ban.

Másrészt annak önmagában valóban nincs értelme, hogy csak úgy, mindenhez odategyünk +1 set/get metódust. Viszont tegyük fel, hogy szeretnénk validálni és értesülni, hogy az változott valami.

public event EventHandler PrecentChanged;

private int _precent;

public int Precent
{
  get 
  { 
    return _precent; 
  }
  set 
  {
    if (value < 0 || value > 100)
    {
      throw new Exception("Valami nem ok");
    }
    _precent = value;
    
    if (PrecentChanged != null)
    {
      PrecentChanged(this, new EventArgs());
    }
  } 
}

Továbbá C#-s propertyknél további érv a megkülönböztetés mellett, hogy nem ritka, hogy egy program refactoringot használ. Pl. WinForms-os programban elérhető a VS saját property editora, mint komponens. Ennek tetszőleges object-t át lehet adni és automatikusan kikeresi a propertyket. Persze, lehetne setBizbaz() függvényeket is keresni (Javanal külön öröm az is/get, saját PHP-s rendszerünkben hasonló esetre pont ezért használunk kizárólag "get_" -t). Szóval leginkább szemantikai jelentősége van.

Persze, ehhez hozzátartozik az adatrejtés elve is.

Ráadásul ne úgy gondolj a propertykre, mint set/get páros egy adattaghoz. Pl. fa esetén root node. Tfh. nincs tárolva külön.

public Node Parent { get; set; }
public Node RootNode 
{
  get 
  {
    return (this.Parent != null)
      ? this.Parent
      : this;    
  } 
}

Egyébként C# 3.0-tól pont erre vannak az auto propertyk .NET-ben (ld. előző példában a Parent-t), hogy ne kelljen ennyi felesleges kódot beletúrni (Vagy Java-hoz pl. a Project Lombok).

Na meg adhat néhány kényelmi funkciót, mint az indexerek.

A +1 metódushívással sem kell annyit foglalkozni, mint régen, gyakorlatilag minden fordító/JIT csuklóból optimalizálja az ilyeneket. Rubys megoldás meg szintén nem teljesen újkeletű, Delphiben is volt már hasonló:

intefrace

type
  TValami = class
    private
      afoo : Integer
      procedure SetFoo(pfoo: Integer);
    public
      property Foo : Integer read afoo write SetFoo;
  end;

implementation

procedure TValami.Foo(pfoo: Integer)
begin
  if pfoo >= 0 and pfoo <= 100 then begin
    afoo := pfoo;
  end;
end;

end.

Persze, ahogy jönnek új nyelvek, úgy lesznek ezek egyre kevésbé nyögve nyelősek.

----------------
Lvl86 Troll