Olio-ohjelmoinnin ongelmat
C#-kielen ongelmat
Sanko F# -tapahtuman diasarja
Copy: https://docs.google.com/presentation/d/1oJm-PRWkCy4qbUOunD2xE-hCZ2gARvN9ASIouuEe02k/edit?usp=sharing
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).