Helper:n käyttö

Ei. Periyttämällä vaan jää epäselväksi, saako periytettyyn luokkaan jatkaa ominaisuuksien toteuttamista. Helper:n kanssa sen voi aika helposti ajatella, että ei oikein sopisi.. tee miten tykkäät! :)

Periytyminen yleisesti on surkea rakenne ja lähes ainoa juttu missä se nyt on toiminut yhtään on lähinnä käyttöliittymäkomponentit.

Eli jos haluaa kirjoittaa rakenteellisesti siistiä oliokoodia, periytymisen sijasta kannattaa kirjoitella interfaceja ja toinen asia sitten se, että pitää välttää gettereitä ja settereitä. Pitää ajatella asia niin, että käsketään oliota tekemään asioita ja ne pitäkööt datan omana tietonaan mahdollisimman paljon.

Toki tuotakin pitää välttää, ja pyrkiä sitä ennen ratkomaan ongelmaa funktionaalisesti tai järjestelmällä työvaiheita kuin liukuhihnaa, eli vaikka dataflow patternia.

Vasta kun nuo kaksi edellistä ratkontatapaa on tutkittu, ongelma ratkeaa viimeistään oliorakenteella kun vaan miettii huolella niitä olioiden välisiä kommunikaaio yhteyksiä. Yleisesti ottaen riippuvuudet niiden välillä pitäisi minimoida. Hyvä esimerkki riippuvuuksien minimoimisesta on esimerkiksi signals and slots malli.

Missä periytyminen on toiminut huonosti?

Ite tykkään kyllä taas periyttää asioita aina mahdollisimman paljon, eli on kantaluokka jossa totetutetaan mahdollisimman paljon yhteisiä asioita, sitten perityissä luokissa on koodailtu vain ne eroavaisuudet ja peritty versio on koodimäärältään mahdollisimman pieni.

Oma toteutus esim. käytännössä on raportointi missä tulostetaan kymmeniä erilaisia raportteja, perityissä versioissa on eroavaisuutena vain sql-haku ja mahdollisesti määritelty eri tyylitiedosto raportille.

"Periyttämällä vaan jää epäselväksi, saako periytettyyn luokkaan jatkaa ominaisuuksien toteuttamista."

No jättää sen metodin kokonaan kirjoittamatta perittyyn versioon jos se siellä ei saa toimia? Objektien tyypiä voi myös aina tarkistella if (x is TLuokkaX)

keps kirjoitti:

Missä periytyminen on toiminut huonosti?

Ite tykkään kyllä taas periyttää asioita aina mahdollisimman paljon, eli on kantaluokka jossa totetutetaan mahdollisimman paljon yhteisiä asioita, sitten perityissä luokissa on koodailtu vain ne eroavaisuudet ja peritty versio on koodimäärältään mahdollisimman pieni.

Oma toteutus esim. käytännössä on raportointi missä tulostetaan kymmeniä erilaisia raportteja, perityissä versioissa on eroavaisuutena vain sql-haku ja mahdollisesti määritelty eri tyylitiedosto raportille.

"Periyttämällä vaan jää epäselväksi, saako periytettyyn luokkaan jatkaa ominaisuuksien toteuttamista."

No jättää sen metodin kokonaan kirjoittamatta perittyyn versioon jos se siellä ei saa toimia? Objektien tyypiä voi myös aina tarkistella if (x is TLuokkaX)

Lue lisää

"Missä periytyminen on toiminut huonosti?"

Käytännössä joka paikassa. Siinä kun tulee tarpeeton kytkentä siihen kantaluokkaan ja näin ollen sen muokkaus menee vaikeammaksi.

Että ehdottomasti tekee ennemmin niitä interfaceja jos oliokoodia kirjoittaa. Rakenne pysyy paljon parempana kun jättää perimisen, getterit ja setterit pois. Ja sitä oliorakennettakin tulisi välttää jos parempaakin löytyy.

M-Kar kirjoitti:

"Missä periytyminen on toiminut huonosti?"

Käytännössä joka paikassa. Siinä kun tulee tarpeeton kytkentä siihen kantaluokkaan ja näin ollen sen muokkaus menee vaikeammaksi.

Että ehdottomasti tekee ennemmin niitä interfaceja jos oliokoodia kirjoittaa. Rakenne pysyy paljon parempana kun jättää perimisen, getterit ja setterit pois. Ja sitä oliorakennettakin tulisi välttää jos parempaakin löytyy.

Lue lisää

Onko olio-ohjelmointi tätä nykyä vanhanaikaista?

kyssyy kirjoitti:

Onko olio-ohjelmointi tätä nykyä vanhanaikaista?

Ei. Se ei vaan ikinä ole ollut ensisijainen ratkaisumalli.

Funktionaalisuus on ymmärretty varmaan 50-luvulta lähtien ideaaliseksi ratkaisumalliksi koska funktionaalisuus poistaa koodista kaikki sivuvaikutukset.

Liukuhihna- ja oliorakenne tulivat molemmat samoihin aikoihin joskus 60-luvulla, ja unix arkkitehtuurissa juurkin ne pipet on olennainen juttu.

oliorakenne alkoi oikeasti saada merkitystä ohjelmie laajentuessa ja erityisesti tapahtumapohjaisissa jutuissa mitä näkee esim. graafisissa käyttöliittymissä.

Mutta, se ongelman ratkaisun järjestys mihin hyvässä koodissa on aina pyritty on funktionaalisuus->liukuhihna->oliorakenne. Ja tuossa järjestyksessä sivuvaikutukset muuhun koodiin kasvaa, eli hallittavuus kärsii, säikeistäminen vaikeutuu, on monimutkaisempi ja jne.

Oliorakennekin tarvitsee asioiden huomioimista, että välttää niitä typeriä asioita kuten perimistä, getteriä ja setteriä mitkä lisää sivuvaikutuksia. Sitten jos ratkaisumalli menee oliorakennetta huonommaksi, koodi on jo kelvotonta spagettisotkua.

--

Nämä siis on matalan tason juttuja kuitenkin, korkeammalla tasolla palastellaan ongelmaa palveluihin ja käyttöliittymäkomponentteihin ja noita eritellään.

On ihan hyvää harjoitusta yrittää optimoida koodin rakenne niin elegantiksi kuin mahdollista., mauttomuuksiin saakka.

Kuulostaa minun korvaan täydeltä pupulta tuo. Tai no kait se riippuu, että jos koodailee jotain käyttistä tai tosi matalantason juttuja C-kielellä, silloin oliot ei ole mahollisuus. Koodailun aloitin 1989 josta olio-ohjelmoitia vuodesta 1998. Oliomalli on vaan niin selkee, koska on helmpompi hahmottaa ongelman ratkaisut läehmmäksi tosielämän tilanteita. Olio-ohjelmointi ei periaatteessa eroa funktionaalisesta / proceduaalisesta lähestymistavasta muutoin kuin että otat instanssin luokasta jonka alaisuudessa nämä funktiot on, eli objekti on ikään kuin nimiavaruus näille funktioille, joita pystyt myös perimään ja kopioimaan, monipuolista, ihanaa ja mahtavaa :)

Mutta meitä on moneen junaan, työpaikallakin yksi tykkää C-kielestä kuin hullu puurosta, vaikka olio-ohjelmointikin on hallussa, itsellä se on taas päinvastoin.

keps kirjoitti:

Kuulostaa minun korvaan täydeltä pupulta tuo. Tai no kait se riippuu, että jos koodailee jotain käyttistä tai tosi matalantason juttuja C-kielellä, silloin oliot ei ole mahollisuus. Koodailun aloitin 1989 josta olio-ohjelmoitia vuodesta 1998. Oliomalli on vaan niin selkee, koska on helmpompi hahmottaa ongelman ratkaisut läehmmäksi tosielämän tilanteita. Olio-ohjelmointi ei periaatteessa eroa funktionaalisesta / proceduaalisesta lähestymistavasta muutoin kuin että otat instanssin luokasta jonka alaisuudessa nämä funktiot on, eli objekti on ikään kuin nimiavaruus näille funktioille, joita pystyt myös perimään ja kopioimaan, monipuolista, ihanaa ja mahtavaa :)

Mutta meitä on moneen junaan, työpaikallakin yksi tykkää C-kielestä kuin hullu puurosta, vaikka olio-ohjelmointikin on hallussa, itsellä se on taas päinvastoin.

Lue lisää

"no kait se riippuu, että jos koodailee jotain käyttistä tai tosi matalantason juttuja C-kielellä, silloin oliot ei ole mahollisuus."

Siis onhan se oliorakenne toki mahdollinen C-kielellä. Ohjelmointikieli ei vaan sitä suoraan tue mutta eihän se sitä estä.

"Oliomalli on vaan niin selkee, koska on helmpompi hahmottaa ongelman ratkaisut läehmmäksi tosielämän tilanteita."

Se vaan on edelleen heikompi tapa kuin funktionaalinen tai liukuhihnaratkaisu koska koodille tulee enemmän sivuvaikutuksia.

Toki sillä on käyttötilanteita missä se toimii hyvin.

M-Kar kirjoitti:

Ei. Se ei vaan ikinä ole ollut ensisijainen ratkaisumalli.

Funktionaalisuus on ymmärretty varmaan 50-luvulta lähtien ideaaliseksi ratkaisumalliksi koska funktionaalisuus poistaa koodista kaikki sivuvaikutukset.

Liukuhihna- ja oliorakenne tulivat molemmat samoihin aikoihin joskus 60-luvulla, ja unix arkkitehtuurissa juurkin ne pipet on olennainen juttu.

oliorakenne alkoi oikeasti saada merkitystä ohjelmie laajentuessa ja erityisesti tapahtumapohjaisissa jutuissa mitä näkee esim. graafisissa käyttöliittymissä.

Mutta, se ongelman ratkaisun järjestys mihin hyvässä koodissa on aina pyritty on funktionaalisuus->liukuhihna->oliorakenne. Ja tuossa järjestyksessä sivuvaikutukset muuhun koodiin kasvaa, eli hallittavuus kärsii, säikeistäminen vaikeutuu, on monimutkaisempi ja jne.

Oliorakennekin tarvitsee asioiden huomioimista, että välttää niitä typeriä asioita kuten perimistä, getteriä ja setteriä mitkä lisää sivuvaikutuksia. Sitten jos ratkaisumalli menee oliorakennetta huonommaksi, koodi on jo kelvotonta spagettisotkua.

--

Nämä siis on matalan tason juttuja kuitenkin, korkeammalla tasolla palastellaan ongelmaa palveluihin ja käyttöliittymäkomponentteihin ja noita eritellään.

On ihan hyvää harjoitusta yrittää optimoida koodin rakenne niin elegantiksi kuin mahdollista., mauttomuuksiin saakka.

Lue lisää

Käsittääkseni tämä funktionallisuus käyttää aika paljon rekursiota?
Eikö rekursio ole taas tapa hidastaa ohjelman suoritusta (ja kasvattaa suoritusaikaista kokoa)?

rekursio_kysymys kirjoitti:

Käsittääkseni tämä funktionallisuus käyttää aika paljon rekursiota?
Eikö rekursio ole taas tapa hidastaa ohjelman suoritusta (ja kasvattaa suoritusaikaista kokoa)?

Ei tarvitse aina rekursiota mutta toki rekursio toimii funktionaalisesti.

Hidastuminen sitten niin ja näin koska funktionaalinen koodi säikeistyy. Suorituskyky ei käytännössä ole mikään ongelma funktionaalisuudessa.

M-Kar kirjoitti:

Ei tarvitse aina rekursiota mutta toki rekursio toimii funktionaalisesti.

Hidastuminen sitten niin ja näin koska funktionaalinen koodi säikeistyy. Suorituskyky ei käytännössä ole mikään ongelma funktionaalisuudessa.

Lue lisää

Esim. (while) silmukalla tehtynä tiedetään etukäteen paljonko silmukka vie muistia muttei tätä ei tiedetä rekursiolla.
(Jossain vaiheessa silmukalla tehtyä koodia pidettiin parempana, suositeltavana)

vielävähänymmällään kirjoitti:

Esim. (while) silmukalla tehtynä tiedetään etukäteen paljonko silmukka vie muistia muttei tätä ei tiedetä rekursiolla.
(Jossain vaiheessa silmukalla tehtyä koodia pidettiin parempana, suositeltavana)

Lue lisää

Koodi vie ilman rajumpia kääntäjäoptimointeja ~suunnilleen sen verran paljon on kirjoittanut koodia. Käätäjäoptimoinnit voi sitten avata kirjoitetut whine silmukat auki jolloin ne vie enemmän.

Rekursiolla näin ei taida käydä. Kaiken järjen mukaan paljon vaikeampaa kääntäjälle. Sen sijaan rekursio kuluttaa ajonaikaisesti muistia pinosta mitä enemmän niitä funktiota kutsutaan. Käytännössä kuitenkin vain tavuja, aina kun tulee funktiokutsu ja palaaminen sieltä vapauttaa sen muutaman tavun.

Käytännössä käännetyn koodin viemää tilaa tai pinon viemää muistin kulutusta ei ole tarvinnut miettiä 80-luvun jälkeen.