[PHP] Gebruik van classes

[Verwijderd]

Omdat ik nu een paar dagen bezig ben met classes en het ook nog aardig wil lukken, doemde bij mij de vraag op: wanneer moet je nou classes gebruiken en wanneer juist weer niet ?

Graag ook redenen vermelden (voorbeeldjes mag ook )...

[dusty]

[voer hier de standaard redenen, van mij, in waarom je nooit classes zou moeten gebruiken onder PHP.]

(zoek zelf maar, ik ga ze niet weer intikken en een soort gelijke discussie aan.)

[xshredx]

prachtig antwoord, dusty, en dat voor een lite-mod...

antwoord dan niet!

Ik probeer classes te gebruiken wanneer ik weet dat een stuk code, of bepaalde functionaliteit, herbruikbaar moet zijn (cliché voorbeeld: database class, session class, ...). En bij iets grotere scripts/sites vind ik dat het opdelen in, en denken over classes, de kwaliteit van mijn code verhoogt. Mijn classe-aanpak is dan misschien niet noodzakelijk de snelste (zowat in executie-tijd als in ontwikkeltijd), maar wat mij betreft wel makkelijkste om mee te werken (en te debuggen), en de manier om met meerderen aan code te werken.

[Zoijar]

Ik gebruik alleen maar classes. Enige dat index.php bij mij doet is dit:

PHP:

<?    require_once('class/main.class.php');    session_start();    $main = new Main($HTTP_SESSION_VARS);    $main->start($HTTP_GET_VARS);    $main->end();?>

En verder heb ik een soort session class waar objecten van af kunnen leiden, en zo variabelen verschillende scope/levensduur te geven. Bv class scope/session lifetime, heb je een soort singleton die state bewaart. Of shared scope, dan is het een shared var tussen al je bezoekers via een locked txt file.
Op dat moment kan je vrijwel net als in C++ programmeren.

[Alarmnummer]

Als je oo gaat programmeren dan ga je altijd werken met classes (of interfaces) en dan heb je de vraag verder niet wanneer je wel of geen classes gebruikt omdat je niet anders kan.

Je maakt een class als je een groep data met bijbehorende acties wilt bundelen in 1 object. Verder vind ik het vrij lastig om op je vraag verder dieper in te gaan, omdat oo een zeer gecompliceerd iets is, en niet even valt uit te leggen in een paar regels.

[Verwijderd]

Op zondag 28 juli 2002 19:53 schreef Alarmnummer het volgende:
Als je oo gaat programmeren dan ga je altijd werken met classes (of interfaces) en dan heb je de vraag verder niet wanneer je wel of geen classes gebruikt omdat je niet anders kan.

Je maakt een class als je een groep data met bijbehorende acties wilt bundelen in 1 object. Verder vind ik het vrij lastig om op je vraag verder dieper in te gaan, omdat oo een zeer gecompliceerd iets is, en niet even valt uit te leggen in een paar regels.

Er zijn vele (studie)boeken over het object georiënteerd programmeren zelf. Lees dus eens zo'n boek of ga op zoek naar online boeken. Je kunt zo heleboel informatie op doen en jouw vraag wordt daarin zeker heel uitgebreid behandeld.

[Alarmnummer]

Op zondag 28 juli 2002 19:57 schreef ridde100 het volgende:
Er zijn vele (studie)boeken over het object georiënteerd programmeren zelf. Lees dus eens zo'n boek of ga op zoek naar online boeken. Je kunt zo heleboel informatie op doen en jouw vraag wordt daarin zeker heel uitgebreid behandeld.

Ik neem aan dat je het niet tegen mij hebt

in mijn kast staan:
"Design Patterns of Reusable Object Oriented Software" (openbaring)
"Pattern Oriented Software Architecture I - A System of Patterns"
"Pattern Oriented Software Architecture II - Patterns for Concurrent and Networked Objects"
"Concurrent Programming in Java - Design principles and patterns"

en nog een hele zooi andere oo gerelateerde boeken

oja.. en deze week komt:
"UML Distilled: A Brief Guide to the Standard Object Modeling Language" daar ook nog bij

[Verwijderd]

Ik gebruik zelf dus nooit OO, het zal ongetwijfeld handig zijn maar zonder OO werkt alles ook lekker

[Alarmnummer]

Op zondag 28 juli 2002 20:26 schreef xtentic het volgende:
Ik gebruik zelf dus nooit OO, het zal ongetwijfeld handig zijn maar zonder OO werkt alles ook lekker

Ik programmeerde vroeger procedureel (c,pascal) en ik programmeer nu voornamelijk oo omdat dit veel geavanceerder is. Je houd je rotzooi beter bij elkaar ipv dat het over je hele system verspreid ligt. Hierdoor kan je ook veel makkelijker stukken hergebruiken, je kan veel makkelijker ontwerpen omdat je een object kan maken met een verwachte functionaliteit en dat ga je later implementeren. En met oo kun je veel krachtigere constructies maken dan met alleen procedureel.

oo is the way to go (voorlopig nog)

[Verwijderd]

Op zondag 28 juli 2002 20:34 schreef Alarmnummer het volgende:

[..]

Ik programmeerde vroeger procedureel (c,pascal) en ik programmeer nu voornamelijk oo omdat dit veel geavanceerder is. Je houd je rotzooi beter bij elkaar ipv dat het over je hele system verspreid ligt. Hierdoor kan je ook veel makkelijker stukken hergebruiken. En je kan veel makkelijker ontwerpen omdat je een object kan maken met een verwachte functionaliteit en dat ga je later implementeren.

Ik dacht dat functies daar voor bedoeld waren ... en zo ben ik dus ooit begonnen met programmeren, eerst alles met goto's en gosubs (basic) en toen met functies ed... ik begrijp dat je met classes gewoon de zelfde functie wel 1000 x kan gebruiken zonder dat data door elkaar komt, maar dat kan met functies ook

[Alarmnummer]

Op zondag 28 juli 2002 20:35 schreef xtentic het volgende:

[..]

Ik dacht dat functies daar voor bedoeld waren ... en zo ben ik dus ooit begonnen met programmeren, eerst alles met goto's en gosubs (basic) en toen met functies ed... ik begrijp dat je met classes gewoon de zelfde functie wel 1000 x kan gebruiken zonder dat data door elkaar komt, maar dat kan met functies ook

Maar die functies gaan over een bepaald stuk data. En dat moet je juist bij elkaar gaan bundelen, dus data en functies bij elkaar. Hierdoor hoeft niet altijd van buiten te bekend zijn wat de data is (encapsulation). En kan je ook makkelijker wijzigingen aanbrengen daarin.

[Verwijderd]

Op zondag 28 juli 2002 20:37 schreef Alarmnummer het volgende:

[..]

Maar die functies gaan over een bepaald stuk data. En dat moet je juist bij elkaar gaan bundelen, dus data en functies bij elkaar. Hierdoor hoeft niet altijd van buiten te bekend zijn wat de data is (encapsulation). En kan je ook makkelijker wijzigingen aanbrengen daarin.

Dat zal zo zijn, voor templates wat ik gelezen heb is het heel handig maar ik heb mijn template engine zo gebouwd dat het even simpel is als het werken met classes, en denk dat ik niet de enigste ben die er zo over denk: dat classes niet of on nodig zijn.

[Alarmnummer]

Ik denk dat ons meningsverschil vooral komt omdat jij geen oo programmeur bent maar een script programmeur. Maar zo gauw je 'echt' gaat programmeren dan zul je zien dat het oo paradigma hele interessante aspecten heeft.\

ps: ik vond oo programmeren in het begin ook 2 keer niets. En ging weer fijn procedureel programmeren daarin. Maar na verloop van tijd leer je er meer over en zie je ook in dat oo vele malen krachtiger is dan procedureel.

[dusty]

Op zondag 28 juli 2002 19:47 schreef xshredx het volgende:
prachtig antwoord, dusty, en dat voor een lite-mod...

antwoord dan niet!
[..]

De discussie waarom ik vind dat men geen classes moet gebruiken onder PHP heb ik al enkele keren eerder vermeld, Het is ook meteen een indicatie dat er meer over te vinden is in de search.

Aangezien er hier [PHP] in de titel staat, zou deze discussie op PHP en classes moeten slaan. Niet over het algemeen OO-gebruik.

[dusty]

Op zondag 28 juli 2002 20:46 schreef xtentic het volgende:
[..]
en denk dat ik niet de enigste ben die er zo over denk: dat classes niet of on nodig zijn.

Zit je met een script-taal zoals PHP kan je makkelijk zonder classes. Ga je echter naar een andere programmeertaal zoals C++ en Delphi kan je er in principe niet omheen wil je een degelijk onderhoudbaar programma maken.

[Alarmnummer]

Waarom zou het onlogisch zijn om niet op een oo stijl te gaan programmeren in een taal die wel oo mogelijkheden heeft? Over het algemeen wordt oo geprefereerd boven procedureel, en waarom zou php daar een uitzondering op zijn?

ps: geef me anders die link maar.

[dusty]

Op zondag 28 juli 2002 21:08 schreef Alarmnummer het volgende:
Waarom zou het onlogisch zijn om niet op een oo stijl te gaan programmeren in een taal die wel oo mogelijkheden heeft? Over het algemeen wordt oo geprefereerd boven procedureel, en waarom zou php daar een uitzondering op zijn?

ps: geef me anders die link maar.

Classes + PHP is trager dan Procedureel + PHP.

Leg eens uit hoe je een constructor in PHP gebruikt, en vertel mij dan daarna eens hoe ik een deconstructor daar tegenover gebruik in PHP.

[Alarmnummer]

Op zondag 28 juli 2002 21:15 schreef dusty het volgende:

[..]

Classes + PHP is trager dan Procedureel + PHP.

Gelukkig hoef ik niet alleen maar snelle code te schrijven. De meeste code die ik schrijf die heeft vrij veel overhead, maar dat heb ik er graag voor over om allerlei geavanceerde (oa oo) technieken te gebruiken.

Leg eens uit hoe je een constructor in PHP gebruikt, en vertel mij dan daarna eens hoe ik een deconstructor daar tegenover gebruik in PHP.

Ik ben verder niet thuis in oo in php, dus ik kan je sowieso al niet helpen met de constructor. En aangezien php geen garbage collection heeft, zal een destructor ook wel naadje zijn

Ik ben op dit moment me wat aan het verdiepen in de slechte oo kwaliteiten van php. Wie kan er nou ontwerpen zonder interfaces (ik ontwerp nu voornamelijk vanuit interfaces, en het feit dat er ook nog een implementatie ergens is, is niet super belangrijk meer). + je hebt op een hele elegantie manier polymorfisme in je systeem, dat veel krachtiger is dan single inheritance.

ps: ik hoor misschien niet helemaal in dit topic thuis, maar ik verveel me het apelazerus

[Verwijderd]

Op zondag 28 juli 2002 20:03 schreef Alarmnummer het volgende:

[..]

Ik neem aan dat je het niet tegen mij hebt

in mijn kast staan:
"Design Patterns of Reusable Object Oriented Software" (openbaring)
"Pattern Oriented Software Architecture I - A System of Patterns"
"Pattern Oriented Software Architecture II - Patterns for Concurrent and Networked Objects"
"Concurrent Programming in Java - Design principles and patterns"

en nog een hele zooi andere oo gerelateerde boeken

oja.. en deze week komt:
"UML Distilled: A Brief Guide to the Standard Object Modeling Language" daar ook nog bij

Nee, ik had het idd niet tegen jou!

BTW: Zijn goede boeken die je in de kast hebt staan.

[Verwijderd]

Op zondag 28 juli 2002 21:15 schreef dusty het volgende:

[..]

Classes + PHP is trager dan Procedureel + PHP.

Leg eens uit hoe je een constructor in PHP gebruikt, en vertel mij dan daarna eens hoe ik een deconstructor daar tegenover gebruik in PHP.

Bij mijn weten hoef je PHP code niet te destructen. Dit gebeurt automatisch op de server. Echter, ik heb het ook maar uit onbekende bron.

[^Mo^]

In PHP 4.3.0 zitten dacht ik destructors, en ik geloof ook functie overloading. Constructors zijn er al...

[WimB]

Wordt het in PHP nog mogelijk om delen van een klasse private te maken? (of is dat ondertussen al mogelijk)

[Nielsz]

Op zondag 28 juli 2002 21:57 schreef WimB het volgende:
Wordt het in PHP nog mogelijk om delen van een klasse private te maken? (of is dat ondertussen al mogelijk)

[url="http://www.zend.com/engine2/ZendEngine-2.0.pdf"]ja[/url]

[xychix]

Op zondag 28 juli 2002 22:19 schreef Nielsz het volgende:

[..]

[url="http://www.zend.com/engine2/ZendEngine-2.0.pdf"]ja[/url]

Erg interressant Document..

staat ook vanalles in over con en de structors etc.. !!

Destructors
Background
No mechanism for object destructors exist today although PHP has support for registering
functions which should be run on request shutdown.
Need
Having the ability to define destructors for objects can be very useful. Destructors can log
messages for debugging, clean up temporary files and so on.
Overview
The proposed solution is like in most other OO languages. When the last reference to an
object is destroyed the objects destructor is called before the object is freed from
memory. Due to the nature of PHP such functionality still needs to be evaluated closely.
For example, when fatal errors occur it might not be possible to call objects destructors
or objects which are in a referential loop which the reference counting mechanism cant
detect might not have their destructor called.
Functionality
The user will define a special method in his class definition (which doesnt receive
arguments). This method will be called __destruct().
So it would look something like:
class MyClass
{
function __destruct()
{
// Run destructor code
}
}

Stukken over
overerving, constructors etc in het document.

[dusty]

Op zondag 28 juli 2002 21:45 schreef _Mo_ het volgende:
In PHP 4.3.0 zitten dacht ik destructors, en ik geloof ook functie overloading. Constructors zijn er al...

Constructors bestaan al geruime tijd in PHP

Echter de 2.0 Engine is nog niet compleet, en dus is niet alle functionaliteit aanwezig die erin komen, dus werkt OO-programmeren in PHP nog niet 100%. (bij definitie dus, omdat de engine nog niet volledig is)

Zolang de engine niet 100% af is, en de php versie het het "gebruikt" niet al een paar maanden in omloop is, ga ik het in iedergeval niet gebruiken.