Hvorfor bruke klasser?

[Iriver]

Hei!

 

Den måten jeg har lært PHP er lang tid med prøving og feiling. Føler kanskje at jeg har lært det litt "på feil måte".

For eksempel vet jeg ikke hva klasser er for noe. Har lest litt om det, men forstår ikke nytteverdien.

 

Kan noen gi meg et godt eksempel på dette? For eksempel i forbindelse med et nettsamfunn som Facebook eller lignende.

Er det likt som function()? Hvorfor ikke bruke den?

 

Takk

[ilpostino]

klaser brukes såvidt jeg vet kun når du skal ha Objekt Orientert Programmering (OOP) og brukes i store sites.

[Flimzes]

Klasser er objektorientert programmering, og er for mange noe av det vanskeligste å lære seg.

 

Objektorientert programmering baserer seg på at du deler opp det du skal lage i objekter.

 

Skal du ha et objekt "bruker", så lager du en klasse med en rekke variablier, og funksjoner som er unike for "bruker". Du kan lage en uendelig mengde med "brukere" som alle har unike variabler og navn, men alle vil ha samme egenskaper definert av klassen.

 

Det er vel så enkelt jeg klarer å presentere prinsippet bak det.

[Terrasque]

Det kan kanskje hjelpe å tenke på en klasse som en samling av data (variabler) og logikk (funksjoner).

 

La oss gå et steg videre med det som Filmzes startet med, en class for "user". Når man bare ser på variabler, så tenker man fort "det samme kan jeg gjøre med en array".

 

Men la oss si at du f.eks skal ha en passord reset funksjon. Vanlig måte å lage det på er en funksjon som tar en bruker(id) som opsjon. Noe a la reset_user_password(user); - Så må man sende mail til bruker.

 

Hvis man er litt famovertenkende har man kanskje en funksjon som heter send_user_mail(user, subject, text); (som igjen kanskje bruker en annen funksjon du har laget for faktisk å sende eposten) slik at man har den logikken på en plass istedet for hundre plasser.

 

Men, enten må du ha samme koden for å slå opp brukeren og tilhørende data fra databasen, reset_user_password() finner epost adressen og gir til send_email funksjonen. Men da er det ikke en send_user_email lenger, bare en standard send_email, og hvis du f.eks senere åpner for flere epost adresser per bruker må du plutselig oppdatere en haug med plasser i koden.

 

Hvis man hadde en "user" klasse, kunne den hentet ut relevant data ved init, og hatt send_email og reset_password definert. Så hadde du hatt all bruker info og relatert logikk i en enkel pakke.

[Choping]

I PHP føles OOP oftest veldig overflødig, det er tar få % av resten av koden hos meg. Brukes mest til database, templates og andre ting jeg vil dra rundt i scriptet.

[Yankes]

Her må jeg også slenge meg på. Finnes det virkelig ingen tutorials der ute som klarer å forklare OOP skikkelig? Jeg har delvis lært med noen enkle ting ved hjelp av tutorials, men jeg klarer virkelig ikke å fatte nytteverdien av det. Forklaringen til Terrasque er den beste tutorialen jeg har lest hittil.

 

For å ta et eksempel så har jeg tittet litt på http://www.killerphp.com/tutorials/object-oriented-php/.

Men her får jeg bare oppfatningen: hva er huleste er vitsen med dette?

 

Hvis jeg tar utgangspunkt i tutorialen der, hvorfor ikke bare sette de navnene han bruker rett i en variabel eller et array?

I det eksempelet der virker det, for meg, tungvindt og unødvendig med OOP.

 

Men jeg ble faktisk litt klokere nå, takket være Flimzes og Terrasque, men er det ingen som vet om noen bra sider eller tutorials som forklarer dette godt og med eksempler? Der nytteverdien kommer godt frem.

 

Jeg driver en side med nesten 300 brukere og kjenner meg godt igjen i de eksemplene Terrasque kommer med, skal jeg endre på en ting må jeg endre det mange steder (ja, jeg skjønner at det er der nytteverdien ligger). Jeg vil gjerne lære meg OOP og forstå det skikkelig, men trenger å komme meg i gang og forstå opplegget.

[Flimzes]

http://www.cplusplus.com/doc/tutorial/ her har du en veldig god side for å lære seg c++, der har de også en veldig god presantasjon av oop. Har ikke sett så mye på php, så vet ikke om noen guider som tar hånd om oop der.

 

edit: om du begynner her http://www.cplusplus.com/doc/tutorial/classes/

så burde ikke de språklige forskjellene være så store.

Endret 25. februar 2011 av Flimzes

[Terrasque]

Vil si at PHP's klasse-implentasjon er heller tung å jobbe med. Personlig begynte jeg ikke å bruke klasser før jeg begynte å bli god i python.

 

Omtrent alt i python er i bunn og grunn en klasse. Implentasjonen er (IMHO) veldig enkel og fleksibel å jobbe med, og det føles rett og slett naturlig å bruke klasser for ting.

 

Det er hovedsaklig tre tilfeller hvor jeg bruker klasser:

1. Hvis jeg har mye logikk og/eller kode som bør være samlet

2. Hvis jeg har behov for å bruke deler av logikken om igjen, kanskje bytte ut noen deler av det.

3. Som en wrapper rundt noe. F.eks db access, telnet osv. Gjemmer all standard koden bak et enkelt interface.

 

Jeg sa tidligere at nesten alt er en class i python.. Mer presis, alt er et object (class instance). Og når man begynner å forstå det, er det ganske mindblowing hvis man ikke har erfaring med klasser før..

 

For eksempel "asd" - en vanlig string. Rettelse, en instance av "str" klassen, med tilhørende funksjoner. Eksempler : "asd".lower() - "asd".isdigit() - "asd".split("s") osv. Noe som er stilig i seg selv. Men la oss se på noe litt mer gøy:

 

Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "asd"
>>> a.split("s")
['a', 'd']
>>> a.islower()
True
>>> type(a)
<type 'str'>
>>> a.split
<built-in method split of str object at 0x7f95787275d0>
>>> print a.split.__doc__
S.split([sep [,maxsplit]]) -> list of strings

Return a list of the words in the string S, using sep as the
delimiter string.  If maxsplit is given, at most maxsplit
splits are done. If sep is not specified or is None, any
whitespace string is a separator and empty strings are removed
from the result.

>>> dir(a)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '_formatter_field_name_split', '_formatter_parser', 'capitalize', 'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find', 'format', 'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'partition', 'replace', 'rfind', 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
>>> class MyStr(str):
...   def split(self, *args, **kwargs):
...     print "No, I REFUSE!"
...
>>> a = MyStr(a)
>>> a.lower()
'asd'
>>> a.isdigit()
False
>>> a.split("s")
No, I REFUSE!
>>> a.split
<bound method MyStr.split of 'asd'>
>>> def split2(*args, **kwargs):
...   print "I still refuse"
...
>>> a.split = split2
>>> a.split()
I still refuse
>>> a.split
<function split2 at 0x7f1995aefc80>
>>>

 

Du kan også overskrive ting som + (funksjon __add__), == (funksjon __eq__), hvordan den blir vist (__str__), osv... og som du sikkert la merke til, så arvet den alt jeg ikke overskrev fra den originale klassen.

Endret 25. februar 2011 av Terrasque

[Milktea]

Tror innsikten kommer tidsnok.

 

Jeg brukte lang tid på å se nytteverdien av klasser/OOP selv om jeg leste flere innføringer. Det virket bare som alt de gjorde var å løse problemene på en vanlig måte, med unntak av at funksjonene ble pakket inn i klasser. Etter å ha prøvd meg på et noe større prosjekt med tusener av linjer med kode innså jeg derimot til slutt hva det egentlig går ut på, og hvorfor det er en så populær programmeringsmetode. Tror absolutt at "større prosjekt" er nøkkelordet her.

[emilkje]

Tror innsikten kommer tidsnok.

 

Jeg brukte lang tid på å se nytteverdien av klasser/OOP selv om jeg leste flere innføringer. Det virket bare som alt de gjorde var å løse problemene på en vanlig måte, med unntak av at funksjonene ble pakket inn i klasser. Etter å ha prøvd meg på et noe større prosjekt med tusener av linjer med kode innså jeg derimot til slutt hva det egentlig går ut på, og hvorfor det er en så populær programmeringsmetode. Tror absolutt at "større prosjekt" er nøkkelordet her.

 

Nailed it! Etter å ha bygget noen prosjekter med litt størrelse, både Java og PHP, så kan jeg ikke få sagt nok hvor fundamentalt OOP er. Ikke minst hvis man er et team. Tenk dere å ta over kode etter en eller anna slask som har presset hele prosjektet inn i sekvensielle funksjoner og handliger... da kan man like gjerne gi opp og begynne på nytt (med oop selvsagt). OOP kombinert med MVC arkitektur = WIN.

[quantum]

Hm, ja, for mange begynner det å gå opp et lys når de ser muligheten for å modellere "ting" i virkeligheten, arv, generalisering/spesialisering osv. Dette er ofte det oo-tutorials presenterer. Men metoden er vel så nyttig når det gjelder å strukturere kode slik at man kan få til gjenbruk og modularisering. Man kan jo få til godt strukturert kode i f.eks. C også, men da er det ofte ved å rette seg etter og «simulere» objektorienterte prinsipper.

 

«Oppdagelsen» av objektorientering blir forøvrig ofte tilskrevet Ole Johan Dahl og Kristen Nygaard, så dette er faktisk en god norsk oppfinnelse helt på linje med ostehøvelen :-)

[MailMan13]

http://streaming.ndc2010.no/tcs/?id=E241ACE5-D26B-41FA-8FA1-FBB3AD8DF5B3

 

4:11 til ca 20:00 er et ganske godt, om litt overfladisk, innlegg om "hvorfor OO".

[Azidops]

Mange gode poster her så skal ikke lage ekko, men til trådstarter og dere andre som ikke har OOP-erfaring vil jeg si at OOP med PHP ikk er den beste innfallsporten pga. HTML er stateless. Det kan derfor være vanskelig å se nytten av OOP ved mindre prosjekter.

 

Skal du derimot lage større applikasjoner, enten det er på web eller desktop, er OOP den rådende programeringsparadigmet. Vil du lære deg OOP er det kanskje best å begynne med applikasjonsprogrammering i Java, .Net, C++ etc.

[Jonas]

Når man har skrevet procedural kode, så er det veldig lett å tenke at all koden du hittil har skrevet, kan veldig enkelt bare plasseres inni en klasse-deklarasjon og gjøre akkurat det samme som den gjorde før. Med en slik tankegang så vil OOP naturligvis fremstå som vanvittig overflødig, men litt av poenget er at det ikke er ordentlig OOP.

 

For å vise dere små barn hvordan oss godt voksne leker, så tenker jeg det er best med et eksempel. Begynte sånn smått å slenge sammen litt MVC når jeg først så tråden og dette er resultatet etter et par intense timer. DISCLAIMER: Purely for educational purposes. I eksempelet ønsker jeg utelukkende å vise dere hvordan man kan utnytte kraften i OOP. Jeg har ikke lagt fem sekkunders innsats i sikkerhet eller andre temaer. Jeg driver heller ikke support, men kan gjerne svare på videre spørsmål. De som har drevet med dette før vil umiddelbart se at koden er preget av at jeg har drevet en del med Rails. Det ligger sannsynligvis også igjen litt spor av features jeg har fjernet fordi det kludret til eksempelet.

 

Last ned her og se live her. Koden benytter seg av nyere features som namespaces, anonyme funksjoner og late static binding, hvilket betyr at dere trenger PHP 5.3 for å kjøre dette.

 

For de som ikke kjenner til arkitekturen i eksempelet, så kalles det MVC. I en MVC-basert applikasjon så finner man som regel ting av interesse i controllers, models og views. Her følger en controller i eksempelet og ett view.

 

<?php
   namespace Controllers;
   class User extends \ Controller {
       public function __default () {
           $users = \ Models \ User :: all();
           $this -> setData('users', $users);
       }
       public function show () {
           $user = \ Models \ User :: getByID($_GET['id']);
           $this -> setData('user', $user);
       }
   }

<ul>
   <li><strong>Id:</strong> <?= intval($user -> getID()); ?></li>
   <li><strong>Navn:</strong> <?= html($user -> getName()); ?></li>
</ul>

<p>Denne brukeren har postet følgende kommentarer.</p>

<table>
   <tr>
       <th>Id</th>
       <th>Dato</th>
       <th>Kommentar</th>
   </tr>
   <?php if (count($user -> getComments()) > 0): ?>
       <?php foreach ($user -> getComments() as $comment): ?>
           <tr>
               <td><?= intval($comment -> getID()); ?></td>
               <td><?= html($comment -> getDate()); ?></td>
               <td><?= html($comment -> getComment()); ?></td>
           </tr>
       <?php endforeach; ?>
   <?php else: ?>
       <tr>
           <td colspan="3">Denne brukeren har foreløpig ikke postet noen kommentarer.</td>
       </tr>
   <?php endif; ?>
</table>

<?php yieldTo("../application/views/layouts/layout.{$view}.php", $data); ?>

Med en god MVC-implementasjon, så kan man gjøre ganske mye morsomme ting med veldig lite kode. Litt av målet med en skikkelig arkitektur og rammeverk er nettopp det å slippe masse unødvendig boilerplate kode og akkurat det kan man potensielt skrive mye av i et stort prosjekt.

 

$user = \ Models \ User :: getByID($_GET['id']);
$user -> setParams($_POST['user']);
\ Models \ User :: update($user);

All automagien går gjerne på bekostning av hastighet, ytelse og skalerbarhet, men resultaterer i vanvittig mye penere og lettlest kode, raskere utviklingsperiode og enklere vedlikehold. En typisk rails-applikasjon vil eksempelvis blæste en database til helvete, men alle som har vært med på prosjekter før vet derimot at fordelene danker ut ulempene, selv på en dårlig dag.

php-oop-example.zip

Endret 4. mars 2011 av Jonas

[tickinghd]

At OOP er meget bra for generell tilnærming på programmering er absolutt sant, men at OOP er den eneste måten å lage skalerbare nettløsninger på er en sannhet med moderasjoner.

 

Drupal er laget i ren prosedyreprogrammering og er ryddig og veldig modulært. Det er liten tvil om at Dries Buytaert som laget Drupal i sin tid gjorde noe riktig når man ser på suksessen i ettertid.

 

Men å lage noe som både er skalerbart, ryddig og modulært i prosedyreprogrammering er meget vanskelig og alle kan ikke være genier. Som en som har utviklet mye i Drupal er det litt vanskelig å ta med seg den kunnskapen til andre områder innen programmering. Det er her OOP er så bra og grunnleggende viktig fordi det setter en programmeringstandard som mye lettere kan gjenbrukes.

 

Det er en årsak til at OOP prioriteres på universiteter og høgskoler. Selv om det finnes enkelttilfeller der prosedyreprogrammering kan fungere bra (eks. webprogrammering på stateless protokoller som http) så er OOP en mer standardisert og generell tilnærming, og dermed mer nyttig.