Olio-ohjelmoinnin kipupisteet

Yleinen arkkitehtuuri(Yksinkertaistettu)Tietokanta

Tietoyhteys (O/R)

Domain Model

Business logiikka Palvelukerros

Käyttöliittymä-logiikka

Käyttöliittymän tietomalli

Käyttöliittymä

Debug

Tuotannon muutostarpeet

Uusi Business-tarve• Domain muuttuu

Bugi• Yllättävät

sivuvaikutukset

Olioiden muoto määriteltävä ennen toiminnallisuutta

Luonnollista?• “Minä ja lintu, kentällä juoksen ja lentä䔕 “Minä juoksen kentällä ja lintu lentää”

Pakollinen “alhaalta ylös” suunnittelu

Olio

vs. funktio-parametri

Olioiden “yleiskäyttöisyys”

Kantaluokista haittaa

Johtaa reflectioniin• Virheet ajonaikaisesti asiakkaalle• Suorituskyky hidastuu

C# kipupisteet

Immutable propertypublic class MyObject{    private readonly string myproperty;    public string MyProperty {         get{            return myproperty;        }    }    public MyObject(string prop)    {        myproperty = prop;    }} 19 sanaa+ 10 sulkua!

Tyyppimäärittelytvar list = new List<List<int>>{                new List<int>{1,2,3},                new List<int>{4,5,6},};

Ok!Noise!

Func<Func<int, List<int>, string>, Func<int, List<int>>, int, string> S = (x, y, z)=> x(z, y(z)); 

F# syntaksitype MyObject(prop:string) =     member x.MyProperty = prop

7 sanaa+ 2 sulkua!

let list = [[1;2;3];[4;5;6]]

let S x y z = x z (y z) Ok!

Generics parametrikonstruktori

void ei ole tyyppi

Func ja Action ovat eri luokat

Ei ole “jokotai”-tyyppiä

Ei ilman rajapintaa• Switch ottaa parametrina

const:in?

Joko Reflektio tai castaus• Suorituskyky• Ajonaikaiset virheet