Iltaa
Tänään varsin kokeilin tehdä +10 haastetta, josta seurasi sekä iloa että hajatelmia.
Mietin lähinnä olio-ohjelmointia ja erilaisia periaatteita sekä malleja.
Että mitä jos noita malliratkaisuja tuotettaisiinkin siltä pohjalta?
Kaikenlaista kikkaretta siinä voisi skriivailla esim. joksikin kirjastoksi.
X-kokoisen taulukon generointi Y-muuttujan arvolla,
erilaisia laskureita,
ratkaisujen vaatimien "toimintoja"
jne...
Kehittäisi samalla sitä olio-näkemystä/ajattelua.
PHP -haasteessahan arvioidaan ainoastaan lopputulosta, ei sitä että millä tekniikalla tai millä kielellä ne on toteutettu.
Toki noin yksinkertaisiin probleemeihin olio-ohjelmointi harvoin tuo merkittävää etua. Toki itse voi kasailla kuvailemasi tyylistä työkalukirjastoa, jota sitten käyttää useissa tehtävissä. Mallivastauksiin sellainen malli ei kuitenkaan mielestäni hyvin sovi, koska malliratkaisun idea on esittää miten asia voidaan toteuttaa yksinkertaisesti. Jos jokaisen vastauksen liitteenä olisi tuhattaitoinen kirjasto, niin se lähinnä vähentäisi selkeyttä.
Haasteen tehtävissä olio-ohjelmointia ei edes kannata käyttää. Se olisi lähinnä teennäistä ja huonoa esimerkkiä.
Olioita sain itse harjoitella Putkapostin puolella. Esim. tehtävä 15 (Kielitiedettä) on aika haasteellinen ja siihen yritin tehdä oman luokan etsittäville sanoille. Kyllä siitä mielestäni apuakin oli (tulos 7553 on neljänneksi paras!)
Huomasin muuten, että symbols on tehnyt tähän tehtävään maksimin (8046), jonka johdosta jlaire (8000) on menettänyt putkapustin maksimipisteet. Sama tilanne tehtävän nro 48 - Triplatulkinta kohdalla!
TapaniS kirjoitti:
Olioita sain itse harjoitella Putkapostin puolella. Esim. tehtävä 15 (Kielitiedettä) on aika haasteellinen ja siihen yritin tehdä oman luokan etsittäville sanoille. Kyllä siitä mielestäni apuakin oli (tulos 7553 on neljänneksi paras!)
Ei kai tuohon tehtävään luokkia sotkemalla mitään helpotusta saa tai edes lisää luettavuutta omaan koodiinsa.
Näin äkkiseltään ajatellen tehtävässä pääsee jo aika pitkälle kun sorttaa sanojen kirjaimet ja keräilee ryhmiinsä ne joiden levensteinin etäisyys toisiinsa on enintään yksi.
Tässä nyt vaikuttaa muodostuvan eri asennoituminen kuin aloituspostauksessa.
Kyse ei ole onelinereiden kodaamisesta vaan "laadukkaan" koodin tekemisestä.
Eikä ne onelineritkaan luettavuutta tue?
Haasteet ovat kuitenkin hyvin rajattuja "ongelmia" hyvin rajallisin reunaehdoin.
Poikkeusten määrä on siis minimoitu ja voidaan keskittyä vain itse pähkinään.
Usein siis haetaan ratkaisua eikä keskityä niihin sen edellytyksiin, joita nyt oman suppean ymmärryksen puitteissa olisin laajentamassa osaksi haasteita.
Toki voi olla, ettei luokkien sotkeminen tee ratkaisusta ainakaan sen selkeämpiä.
Aloituksen tavoitteena ei ollutkaan selkeyttää ratkaisuja vaan soveltaa niihin aikuisten oikeasti koodin muodostuksen periaatteita/teorioita.
Näin voisi selkeyttää muita asioita kuin pelkkää ratkaisua.
Ja ratkaisujakin voi olla monenlaisia riipuen tilanteesta tekijästä.
Yksi sanoo, että koodi lukee tietoja väärästä polusta, mutta toisen mielestä tiedot ovat väärässä paikassa.
Täten, on kaksi hyvin erilaista ratkaisua ongelmaan.
Tämä nyt ei ole kovin koodaamista, mutta yritän tuoda pointtini esille: on helppoja tapoja ratkaista asioita ja sitten nk. kestäviä tapoja.
Mutta jos joku viisaampi sanoo, että ei kannata, niin silloin se ei luultavasti kannata.
Multibyte kirjoitti:
Haasteet ovat kuitenkin hyvin rajattuja "ongelmia" hyvin rajallisin reunaehdoin.
Poikkeusten määrä on siis minimoitu ja voidaan keskittyä vain itse pähkinään.
Olio-ohjelmoinnissa hyvin suunniteltu luokka täyttää kutakuinkin juuri nämä kriteerit. Toisin sanoen jokainen oliomallinen ratkaisu php-haasteen ongelmiin olisi suurin piirtein tällainen:
class Solution
{
public function solve(...$arguments)
{
// logic
}
}
$result = (new Solution)->solve(...$_GET);
// For scalar results
print $result;
// For multi-value results
foreach ($result as $row) {
// print formatted $row
}Ja jos koet jonkin php-haasteen tehtävän hyödylliseksi / uudelleen käytettäväksi, niin silloin voit juuri esimerkkini tavoin kääräistä sen luokkaan. Esimerkiksi rot13-haaste eli pähkinä #24 voisi olla tällainen.
Ainoa hyöty oliomallisesta lähestymistavasta olisi ehkä se, että samalla oppisi erottelemaan tulostamisen ja vastauksen muotoilun varsinaisesta ongelman ratkaisusta. Tämä on yksi kulmakivi hyvän ohjelmointitavan sisäistämisessä. Mutta se ei vaadi luokkia vaan ihan hyvin toimii puhtailla funktioillakin. Käytännössä saman hyödyn saisi sillä, että mallivastaukset noudattaisivat tätä periaatetta niiltä osin, kuin se on järkevää.
The Alchemist kirjoitti:
Olio-ohjelmoinnissa hyvin suunniteltu luokka täyttää kutakuinkin juuri nämä kriteerit....
Tässä on jo hyvä alku :)
Hei maailma -ohjelman voi toteuttaa näin:
<?php
class Tervehdys {
private $teksti;
public function __construct($teksti) {
$this->teksti = $teksti;
}
public function __toString() {
return $this->teksti;
}
}
class Tulostaja {
public function tulosta($teksti) {
echo $teksti;
}
public function tulostaRivi($teksti = "") {
$this->tulosta($teksti);
$this->tulosta("\n");
}
}
class TervehtiväOhjelma {
private $tervehdys;
public function __construct($teksti) {
$this->tervehdys = new Tervehdys($teksti);
}
public function aja() {
$tulostaja = new Tulostaja;
$tulostaja->tulostaRivi($this->tervehdys);
}
}
class HeiMaailmaOhjelma extends TervehtiväOhjelma {
public function __construct() {
parent::__construct("Hei maailma!");
}
}
$ohjelma = new HeiMaailmaOhjelma;
$ohjelma->aja();Toinen vaihtoehto on toteuttaa se näin:
<?php echo "Hei maailma!\n";
Kumpi on parempi?
Ei ole mitään järkeä käyttää olio-ohjelmointia vain olio-ohjelmoinnin vuoksi. Ensimmäisen esimerkin koodi on huonoa, koska siinä tehdään yksinkertainen asia monimutkaisesti. Aivan samasta syystä PHP-haasteen tehtävissä ei kannata käyttää olio-ohjelmointia: teennäisestä koodista ei opi oikeasti olio-ohjelmoinnin ajattelutapaa, koska luokat ovat idealtaan hyödyttömiä.
Olio-ohjelmointi ei tee automaattisesti koodista parempaa. Joskus koodin voi kyllä tehdä paremmin, kun käyttää olio-ohjelmointia hyvin. Toisaalta usein jokin muu ohjelmointitapa olisi yhtä lailla mahdollinen. Olio-ohjelmointi vain on eräs suosittu tapa. Kannattaa selvittää hyvät ja huonot puolet ja valita kussakin tilanteessa sopiva tapa.
Olio-ohjelmoinnista on yllättävän vaikea keksiä lyhyitä harjoitustehtäviä, koska olio-ohjelmoinnin suurimmat hyödyt tulevat esiin vasta kohtalaisen monimutkaisissa tilanteissa. Pienissä projekteissa se on lähinnä tapa asetella koodia eikä vaikuta ohjelman suunnitteluun ja rakenteeseen juuri lainkaan.
Tässähän tuli jo monta asiaa lyhyesti ja selkeästi.
Mielestäni on tärkeää erottaa hyöty vs. vaihtoehto.
Vaikkei olio periaattella toisinnettu scriptkiddying olisikaan hyödyllistä koodin/ohjelman ts. kääntäjän näkökulmasta, niin on se kuitenkin täysin eri asia kehittäjänäkökulmasta.
Ja eipä tässä sellaiset asiat kenties ihan heti tule esille kuten DRY ja SRP.
Itselleni DRY on asia johon törmään tuon tuosta, mutten ole saanut siihen mitään ohjenuoraa.
SRP on toinen johon törmään, mutta jota en saa käärästyä foliohattuni sisään.
Rajanveto on vaikeaa, mutta kai se liittyy osittain suunnitelmattomuuteen ja kokonaiskuvan puutteeseen.
Puhumattakaan sitten eri patterneista ynnättynä DD, MVC, MVVM...
DRY:hän on ohjenuora itsessään: Don't repeat yourself.
Grez kirjoitti:
DRY:hän on ohjenuora itsessään: Don't repeat yourself.
Kyllähän sitä nyt lukea osaa, mutta usein se tuntuu "pakolliselta" toistaa itseään.
Vastaavasti SRP paisuttaa jotain työstettävää lohkoa, joka lopulta punoo koko spaghetin.
Multibyte kirjoitti:
Mielestäni on tärkeää erottaa hyöty vs. vaihtoehto.
Vaikkei olio periaattella toisinnettu scriptkiddying olisikaan hyödyllistä koodin/ohjelman ts. kääntäjän näkökulmasta, niin on se kuitenkin täysin eri asia kehittäjänäkökulmasta.
Miten kehittäjän näkökulmasta voisi olla hyödyllisempää tehdä jokin yksinkertainen asia monimutkaisesti, jos lyhyt nopea toteutus riittäisi hyvin tekemään työn. Puhumattakaan, jos useampi kehittäjä joutuisi työskentelemään myöhemmin koodin kanssa. Muutaman rivin funktiosta saa kohtuullisen nopealla silmäyksellä selvitettyä mitä siinä on tehty.
Olio-pohjaisuus ei automaattisesti tee koodista parempaa. Modulaariseen koodiin on myös muita tapoja, mitkä toimivat aivan yhtä hyvin.
Otetaan vaikka The Alchemist:in aiemmin mainitsema rot13. Tämä on niin yksinkertainen tehtävä, että muutaman rivin funktio riittää hyvin toteutukseen. Jos kuitenkin halutaan ottaa modulaarisempi lähestymistapa ja tukea muutakin kuin rot13 erikoistapausta, niin tämän voisi kirjoittaa esimerkiksi (8th Forth, sori en osaa PHP:ta):
ns: cypher
: modulate
tuck n:- 26 n:+ 26 n:mod n:+
;
: caesar \ intext key -- outext
>r
(
dup '. n:> if
dup r@ n:+ swap
'A 'Z n:between if 'A else 'a then modulate
then
) s:map rdrop
;
: rot13 \ intext -- outtext
13 caesar
;
ns: user
: app:main
"Hello World!" dup . cr cypher:rot13 dup . cr cypher:rot13 . cr
bye
;PL/I:llä en edes vaivautuisi kirjoittamaan omaa funktiota rot13-toteutukselle. Translate() sisäänrakennettu funktio tekisi tuon käytännössä suoraan.
Tai sitten vaikeimman kautta, ettei olis mitään järkeä.
On kyllä käsittämätöntä tuon PL/I:n mukaanottaminen joka vastaukseen.
Eipä tuo php:llakaan ole kovin monimutkaista. (Kuten ei millään muullakaan).
str_rot13('Jotain tekstiä');
groovyb kirjoitti:
On kyllä käsittämätöntä tuon PL/I:n mukaanottaminen joka vastaukseen...
Keskustelussa käsiteltiin oliopohjaisuuden hyödyistä verrattuna muihin ohjelmointimalleihin. Viestissäni oli mukana selkeä ja toimiva 8th Forth esimerkki. PL/I nyt sattuu vain olemaan yksi käyttämistäni ohjelmointikielistä. Harmi, että tämä on sinulle elämää suurempi ongelma.
Oletko muuten joku koulukiusattu reppana joka haluaa foorumilla purkaa pahaa oloaan muihin, kun tunnut niin kärkkäästi tarttuvan kaikkeen mitä kirjoitan?
translate('Jotain tekstiä', 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz','NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm');jalski kirjoitti:
(01.02.2018 10:38:38): ”– –” Keskustelussa käsiteltiin oliopohjaisuuden...
Eiköhän kaikki ymmärtänyt ko. viestin ihan oikein.
Multibyte kirjoitti:
jalski kirjoitti:
(01.02.2018 10:38:38): ”– –” Keskustelussa käsiteltiin oliopohjaisuuden...
Eiköhän kaikki ymmärtänyt ko. viestin ihan oikein.
Jatka vaan niiden hienojen lyhenteiden ulkoa opettelua, ehkä joskus keksit niille jotain oikeatakin käyttöä.
No nyt saavuttiin koodarin kääntöpiirille, kun kaikki voi olla vain 0 tai 1.
lol
rofl
kek
dr(y)
sudo chmod a-w .
Aihe on lukittu, joten siihen ei voi vastata.