C# nykyiset kipupisteet

822 views

Published on

Olio-ohjelmoinnin ongelmat
C#-kielen ongelmat

Sanko F# -tapahtuman diasarja

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
822
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Jokaisessa kerroksessa on rajapinta (Interface) ja sen toteuttava luokka Luokkaa ei löydä helposti, se saattaa tulla IoC:lla Kerrosten rajapinnat eivät saa muuttua Usein kerrokset ovat “turhia” pass-through-kerroksia Ehkä sisältävät null-checkit (ja olio-mappauksen kerroksen olioista toisiin) OMG Ponies: http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx
  • Ylläpitovaiheessa koodin muuttaminen on kalliimpaa kuin kehitysvaiheessa On kaksi syytä muuttaa koodia ylläpitovaiheessa: Business-tarve muuttuu, Domain-olion rooli muuttuuBugi: Koodissa näyttäisi lukevan eri tavalla kuin ohjelma toimii Kummassakin tapauksessa ollaan ongelmissa
  • Olioita on alun perin perusteltu ihmisille luonnollisena mallina. Suunniteltava bottom-up, vaikka määrittelyt tehdään kuitenkin ensin korkeammalla tasolla ennen yksityiskohtia.
  • Tässä container… Sitten tarvitaanmanager,provider, factory, …Ja interfacet tietysti…Mitä tämä oikeastaan tekee?
  • Yleiskäyttöisyys ei ikinä onnistu, koska kaikkea tulevaa toiminnallisuutta ei alussa koskaan tiedetä Ainoa toimiva yleiskäyttöisyys on Reflection Menetetään kääntäjän virheentarkistukset Tyyppijärjestelmä ei ole .NET:ssa sattumalta!
  • - Kuinka vaikeaa se voi olla???Noise! Perus property { get;set; } on helppo, mutta olioista on vaikeaa tehdä sellaisia, ettei joku muu voisi käyttää set:iä saamaan olion väärään tilaan.
  • Kuvan alareunan funktio on oikeasti toimiva… :-)
  • Uudempi kieli ja lyhyemmät käskyt ja paremmat kirjastot eivät ole itse asiassa edes pääpointti.F#:lla on korkeampi abstraktiotaso kuin C#:lla. Kuten C-kiellellä on korkeampi abstraktiotaso kuin assembler-kielellä.
  • Javalla ei tietenkään voi tehdä mitään tämän suuntaistakaan:Javan generics on vain “syntacticsugar”, eli kääntäjä optimoi sen pois
  • - Tämä olisi ok, jos kieli muutenkin erittelisi sivuvaikutukset, mutta myös Func voi suorittaa sivuvaikutuksen. Tästä syystä:F#-funktiot eivät ole yhteensopivia C# kanssa, Aito patternmatching ei toimi F# listakäsittely on ilmaisuvoimaisempaa kuin LINQ. Lisäksi listojen jako useisiin IEnumerableihin on hankalaa (lähinnä vain GroupBy-kikka).
  • Reflektioon ajautuminen: suorituskyky, käännösvirheiden menetys
  • C# nykyiset kipupisteet

    1. 1. Olio-ohjelmoinninkipupisteet<br />
    2. 2. Tietokanta<br />Yleinenarkkitehtuuri(Yksinkertaistettu)<br />Tietoyhteys(O/R)<br />Käyttöliittymä<br />Domain Model<br />Käyttöliittymän tietomalli<br />Business logiikka<br />Käyttöliittymä-logiikka<br />Palvelukerros<br />Debug<br />
    3. 3. Tuotannonmuutostarpeet<br />
    4. 4. Olioiden muoto määriteltävä ennen toiminnallisuutta<br />
    5. 5. Olio<br />
    6. 6. vs. funktio-parametri<br />
    7. 7. Olioiden“yleiskäyttöisyys”<br />
    8. 8. C# kipupisteet<br />
    9. 9. Immutable property<br />public class MyObject<br />{<br />    private readonly string myproperty;<br />    public string MyProperty { <br />        get{<br />            return myproperty;<br />        }<br />    }<br />    public MyObject(string prop)<br />    {<br />        myproperty = prop;<br />    }<br />}<br />
    10. 10. Tyyppimäärittelyt<br />var list = new List<List<int>>{<br />                new List<int>{1,2,3},<br />                new List<int>{4,5,6},<br />};<br />Ok!<br />Noise!<br />Func<Func<int, List<int>, string>,<br /> Func<int, List<int>>, int, string> S = (x, y, z)=> x(z, y(z));  <br />
    11. 11. F# syntaksi<br />type MyObject(prop:string) =<br />     member x.MyProperty = prop<br />let list = [[1;2;3];[4;5;6]] <br />let S x y z = x z (y z) <br />Ok!<br />
    12. 12. Generics parametrikonstruktori<br />
    13. 13. void ei ole tyyppi<br />
    14. 14. Ei ole “jokotai”-tyyppiä<br />

    ×