Code herstructureren (PHP)

[gvdh81]

Zoals menig ander programmeur ben je ooit begonnen in een programmeertaal en heb je in de loop der tijd een aardige library opgebouwd van zaken die je liever niet meer kwijt wilt. In mijn geval een slordige 80Kb aan veelgebruikte, al dan niet zelfgeschreven functies in één enkele PHP file. Dit varieerd van debug functies, tot functies voor arrays, datum/tijd, template functies en de hele zut. Ik werk inmiddels met PHP5 en ben bezig om alles zo object georienteerd mogelijk aan te pakken, vandaar de volgende ideeen:

Laatst zat ik eens door een cursusboek van MCP heen te bladeren en was er ineens erg voor om mijn "library" op te gaan splitsen in lossen klassen, zodat je bijv. alle functies daar stopt waar je ze verwacht. Denk dan bijv. aan:
$debug->write(..)
$debug->writeln(..)
$date->formatForSQL(...)
$template->isChecked(...)

et cetera.

Nu is het bij C# zo, dat je enkel de library hoeft te "includen" en je kunt bijvoorbeeld System.Data.OleDb.OleDbDataReader aanroepen. In PHP werkt dit natuurlijk iets anders, aangezien je voor zover ik weet niet zo ver "omlaag" kunt gaan, zonder eerst overal losse, nieuwe instanties van te maken, tenzij je "debug::writeln" gaat doen, toch?

Graag verneem ik jullie gedachten over een dergelijke herstructurering van bestaande code. Is het de moeite waard, hoe hebben jullie het eventueel aangepakt, en wat zou de beste methode zijn?

[Janoz]

Wat je daar mbt C# noemt zijn niet allemaal classes, maar zijn packages/namespaces. Dit zit inderdaad niet in php en is ook 1 van de grote mankementen van die taal.

[NMe]

Wat verwacht je eigenlijk concreet te gaan horen hier? Of het al dan niet handig is alles op te delen in losse files danwel klassen? Op zich is het natuurlijk logisch dat het indelen in losse bestanden met logische groepering de leesbaarheid ten goede komt. Als je vervolgens ook nog eens met PHP5 werkt (en dus fatsoenlijke OO-ondersteuning hebt), dan kun je ook nog eens aparte klassen gebruiken voor de verschillende groepen. Overerving van bijvoorbeeld functies voor MySQL van een algemene databaseklasse is wel zo handig; je interface is dan namelijk hetzelfde, ongeacht of je ineens overstapt op PostrgreSQL of niet.

Ik verwacht in elk geval niet dat er hier iemand gaat roepen: "laat het asjeblieft in één file staan!!!1"

[gvdh81]

Ik verwacht dat ook niet, maar ik had een klein beetje gehoopt dat PHP5 namespaces ondersteunde en dat ik dat gewoonweg nog niet gezien had. Helaas is dat niet het geval en zal ik iets anders moeten verzinnen

[NMe]

Je zou natuurlijk namespaces kunnen benaderen met classes, zoals ze bijvoorbeeld hier doen, maar meer dan een benadering zou het niet worden.

[Alex]

Je zou inprinciepe een .(punt) kunnen vervangen door een slash en daarmee een eigen include functie/methodiek bouwen. Probleme is alleen dat je die dan weer altijd moet initialiseren met een functie waar dat nog niet zit.

Belangrijke tip die ik je kan geven: kijk je functies nog eens goed door. PHP is in de loop der tijd een beetje verzand in alle functies. Ik heb op dit moment moeite om van C# naar PHP te stappen omdat ik zo enorm moet zoeken naar al die 30.000 functies. Kijk daarom uit dat je geen 2e wiel uit aan het vinden bent!

[gvdh81]

Kijk dat wat je zegt is meteen een beetje het probleem van PHP.

Soms heeft een functienaam EenDergelijkeNaam, soms een_dergelijke_naam en soms heet ie gewoon totaal onlogisch. Namespaces heeft PHP wel even ondersteund, maar er werd geen logische manier gevonden om het te implementeren, vandaar dat ze het hebben "gedropt".

Ik zal eens kijken naar de link die NME gaf.

[gvdh81]

even in een nieuwe reply mijn reactie. Ik zat aan een dergelijk systeem te denken wat ze in deze thread stoppen.

Bijv. ik zou de volgende namespaces willen gebruiken:
system.debug.*
system.data.xml.*

Ik zou het dan aanroepen door zoiets dergelijks te doen:
SytemDebug::LogLine();
SytemDataXml::SomeFunction();

In mijn autoload zou ik het dan zo maken dat de classname gesplitst zal worden op Capitals en dat zou dan de volgende filenames geven:
system/debug.php
system/data/xml.php

In die desbetreffende files zit dan de classname "SystemDebug" en "SystemDataXml", is zoiets logisch?

[Michali]

Opsplitsen op hoofdletters is niet wenselijk. Dan beperk je jezelf te veel met het kunnen geven van een naam. Ik zou dan eerder voor een underscore gaan. Iets als dit bijvoorbeeld:

PHP:

class System_Debug
{
 //....
}
function __autoload($className)
{
    include './lib/' . str_replace('_', '/', $className) . '.php';
}

Zelf gebruik ik dit soort truukjes niet. Ik zorg gewoon voor een korte prefix: DB, of Sys oid. Neemt niet te veel ruimte in en is duidelijk genoeg.

[JKVA]

Maar waarom ga je eigenlijk proberen zelf om die mankementen van de taal heen te werken? Dan krijg je straks klassenamen van 100 karakters, dat is fijn instantieren.

Nee, ik wil niet flamen op PHP, maar als je zulke dingen moet gaan doen kun je beter naar Java of .NET stappen waarin namespaces/packages ondersteund worden en zelfs nog extra's bieden zoals package scoping waardoor je variabelen publiek zijn maar niet voor iedereen zichtbaar. Om nog maar te zwijgen over de klassenamen die op deze manier lekker kort blijven.

[flowerp]

gvdh81 schreef op woensdag 30 augustus 2006 @ 11:09:
Soms heeft een functienaam EenDergelijkeNaam, soms een_dergelijke_naam en soms heet ie gewoon totaal onlogisch. Namespaces heeft PHP wel even ondersteund, maar er werd geen logische manier gevonden om het te implementeren, vandaar dat ze het hebben "gedropt".

Komt dit niet een beetje heel knullig over? Hoe kan men nou ooit stellen dat PHP geschikt is voor profesionele doeleinden als er op deze manier gerommeld wordt?

Ook snap ik de comment boven niet. Men kon geen logische manier vinden om namespaces te implementeren? Alsof er niet tig andere talen op de markt zijn waarvan men het direct had kunnen afkijken. Daarnaast is het wellicht ook een beetje vreemd dat er niet meteen met OO begonnen is. Ik snap dat je sommige dingen pas later implementeerd in een taal omdat iets nog niet bestaat/in de mode is op het moment dat een taal geboren wordt (bv annotations ten tijde van Java 1.0) . Maar OO bestond zeer zeker toen PHP 1 uitkwam, en het is ook niet alsof PHP die extra tijd gebruikt heeft om een hele nieuwe (betere) manier van OO toe te voegen.

[smokalot]

flowerp schreef op zaterdag 02 september 2006 @ 21:06:
[...]


Komt dit niet een beetje heel knullig over? Hoe kan men nou ooit stellen dat PHP geschikt is voor profesionele doeleinden als er op deze manier gerommeld wordt?

Ook snap ik de comment boven niet. Men kon geen logische manier vinden om namespaces te implementeren? Alsof er niet tig andere talen op de markt zijn waarvan men het direct had kunnen afkijken. Daarnaast is het wellicht ook een beetje vreemd dat er niet meteen met OO begonnen is. Ik snap dat je sommige dingen pas later implementeerd in een taal omdat iets nog niet bestaat/in de mode is op het moment dat een taal geboren wordt (bv annotations ten tijde van Java 1.0) . Maar OO bestond zeer zeker toen PHP 1 uitkwam, en het is ook niet alsof PHP die extra tijd gebruikt heeft om een hele nieuwe (betere) manier van OO toe te voegen.

OO voor een simpele webscripting taal ligt niet heel erg voor de hand. Ik denk dat men niet verwacht had dat PHP voor zulke grote projecten gebruikt zou gaan worden, en pas bij grote projecten is OO *echt* handig.

Als je klasses gaat gebruiken alsof t namespaces zijn verlies je juist het OO gebeuren. ik was vroeger een grote fan van php, omdat het zo lekker vergevend is (if($var) werkt ook gewoon zonder eerst van int naar bool te casten enzo), maar vind tegenwoordig de duidelijkheid van Java/C# erg prettig.

[flowerp]

smokalot schreef op zondag 03 september 2006 @ 00:11:
[...]
OO voor een simpele webscripting taal ligt niet heel erg voor de hand. Ik denk dat men niet verwacht had dat PHP voor zulke grote projecten gebruikt zou gaan worden, en pas bij grote projecten is OO *echt* handig.

Natuurlijk, helemaal mee eens. Iets wat veel mensen vergeten is dat het verschil tussen 100 regels en 100.000 regels niet een kwestie is van 'gewoon' 1000x keer meer werk, maar een heel andere aanpak vereist.

Voor een simpele webscripting situatie (homepage oid van enkele pagina's) heb je inderdaad niet perse classes, web components of object relational mappings (orm), etc nodig. Waarom mensen dan toch PHP voor grote projecten zijn gaan gebruiken is me echter niet helemaal helder.

[smokalot]

flowerp schreef op zondag 03 september 2006 @ 12:14:
[...]


Natuurlijk, helemaal mee eens. Iets wat veel mensen vergeten is dat het verschil tussen 100 regels en 100.000 regels niet een kwestie is van 'gewoon' 1000x keer meer werk, maar een heel andere aanpak vereist.

Voor een simpele webscripting situatie (homepage oid van enkele pagina's) heb je inderdaad niet perse classes, web components of object relational mappings (orm), etc nodig. Waarom mensen dan toch PHP voor grote projecten zijn gaan gebruiken is me echter niet helemaal helder.

nou ja, PHP is niet heel sterk op dat gebied, maar is kwa performance, stabiliteit en (makkelijk toepasbare) features wel heel sterk. Zeker met het beetje OO van PHP5 kun je best redelijk je structuur overzichtelijk houden.

Moet je kijken hoeveel enorme projecten er in C geschreven zijn

[JKVA]

smokalot schreef op zondag 03 september 2006 @ 13:27:
[...]
nou ja, PHP is niet heel sterk op dat gebied, maar is kwa performance, stabiliteit en (makkelijk toepasbare) features wel heel sterk. Zeker met het beetje OO van PHP5 kun je best redelijk je structuur overzichtelijk houden.
[...]

Ik denk eerder dat de reden voor grote projecten in PHP is dat er veel mensen bekend mee zijn. Een klant klopt aan bij een webdesign bureau (die ze kennen omdat ze ooit een website voor hem gemaakt hebben) voor een applicatie en die wordt dan in PHP gemaakt. Dat heeft niet met performance of stabiliteit te maken, maar met kennis.

Moet je kijken hoeveel enorme projecten er in C geschreven zijn

Dat heeft meer te maken met het feit dat er toen nog geen mooie talen bestonden en C de enige optie was. Bovendien vallen die enorme projecten van toen in het niet bij de projecten van tegenwoordig.
Die projecten zijn vaak vooral onbeheersbaar, niet groot.

[smokalot]

JKVA schreef op zondag 03 september 2006 @ 15:22:
[...]

Ik denk eerder dat de reden voor grote projecten in PHP is dat er veel mensen bekend mee zijn. Een klant klopt aan bij een webdesign bureau (die ze kennen omdat ze ooit een website voor hem gemaakt hebben) voor een applicatie en die wordt dan in PHP gemaakt. Dat heeft niet met performance of stabiliteit te maken, maar met kennis.
[...]

Dat heeft meer te maken met het feit dat er toen nog geen mooie talen bestonden en C de enige optie was. Bovendien vallen die enorme projecten van toen in het niet bij de projecten van tegenwoordig.
Die projecten zijn vaak vooral onbeheersbaar, niet groot.

de linux kernel, glibc, gcc, Gnome/Gtk, en dat is alleen nog meer in GNU land, zijn toch flinke projecten geschreven in C, met nog eens de extra organisatorische moeilijkheid dat mensen elkaar amper zien.

Zou ik toch niet onbeheersbaar noemen.

[flowerp]

smokalot schreef op zondag 03 september 2006 @ 20:43:
[...]
de linux kernel, glibc, gcc, Gnome/Gtk, en dat is alleen nog meer in GNU land,

Over het algemeen worden dit soort projecten door mensen gedaan die geen aanhanger zijn van het "don't make me think" motto

Dit soort projecten wordt ondernomen door mensen die veelal top of the top in het hacker wereldje zijn. C bevat vanaf de taal zelf weinig wat helpt bij het structureren van code, maar vergeet niet dat in de tijd dat C bedacht werd de functie al een gewaagde constructie was die onderdeel was van het toenmalige gehypte "gestructureerd programeren". Nu zien we een functie als het meest basale van een programmeer taal en is gestructureerd programmeren zo'n vanzelfsprekendheid dat het als term eigenlijk niet meer bestaat.

In de loop der tijd zijn er zeer veel frameworks/libs voor C geschreven, tot aan complete object emulatie libs aan toe. Dit zijn veelal niet de meeste eenvoudige libs, maar voor het beoogde C publiek (de hacker) is dat te doen. Veel niet-hackers hebben het C platform al lang geleden verlaten; eerst voor C++ en nu voor Java en C#. De prutser heeft zich door de inherente complexiteit van C nooit tot dit platform aangetrokken gevoelen.