Link: http://lithify.me/
Ben op zoek naar mensen die hier ook mee werken. Het lijkt enigzins op CakePHP omdat de author hiervan de lead developer was.
2.542 views
Op het eerste gezicht ziet het er allemaal wel aardig uit. Echter, toen ik op github eens door de sources bladerde zag ik dat de classes barsten van de statics. Toen ben ik maar gauw afgehaakt.
te moeilijk voor je ?
:-))
Globals, Statics and Singletons are evil.
Globals, Statics and Singletons are evil.
Flip -- op 26/08/2012 19:32:56
te moeilijk voor je ?
Wat heeft 'te moeilijk' te maken met een overhoeveelheid statics? :)
Waarom zou je afhaken bij statics ?
Statics en singletons zijn niet goed in een goede OO omgeving.
Met singletons is het bijna onmogelijk om test driven development te gebruiken en statics vind ik zelf niet eens OO.
Als je een class static methods meegeeft maak je van de class meer een collectie van functies dan een object. Als je instance methods maakt in de class is de class wel een object. En ook met static methods is het unit testen moeilijk, aangezien deze static zijn en niet per instance verschillen.
Met singletons is het bijna onmogelijk om test driven development te gebruiken en statics vind ik zelf niet eens OO.
Als je een class static methods meegeeft maak je van de class meer een collectie van functies dan een object. Als je instance methods maakt in de class is de class wel een object. En ook met static methods is het unit testen moeilijk, aangezien deze static zijn en niet per instance verschillen.
Mooi gesproken Wouter, ik had het niet beter kunnen verwoorden.
Echt geen probleem om tests te runnen, er zijn zelfs veel goede tests meegeleverd.
Zie: http://lithify.me/docs/manual/appendices/readme.wiki
"You guys use statics all over the place. Aren't those really hard to test?"
Verder zijn statics niet per definitie foute code en hebben ze wel degelijk voordelen.
Zie: http://lithify.me/docs/manual/appendices/readme.wiki
"You guys use statics all over the place. Aren't those really hard to test?"
Verder zijn statics niet per definitie foute code en hebben ze wel degelijk voordelen.
Ik denk dat vriend en vijand het er wel over eens is dat statics eigenlijk niks met OO programmeren te maken hebben, maar een deftige manier zijn om procedurele code in classes te hangen.
In de link staat het eigenlijk all, het probleem met statics (net als met globals en singletons) is 'state'.
En we kunnen er wel een academische discussie van maken, maar die is al heel vaak gevoerd. De ontwikkelaars van PHP willen uiteindelijk ook van de globals en superglobals af.
Ik heb wel eens naar het Laravel framework gekeken, dat is echt heel erg mooi. Maar ook weer in elkaar geplakt met statics. En ik snap wel waarom, je kunt ze te pas en onpas gebruiken, zonder een instantie van de class te instantieëren. En dan ben ik toch weer terug bij 'state'.
Ik zal eens kijken of ik ergens een voorbeeldje kan opsnorren.
In de link staat het eigenlijk all, het probleem met statics (net als met globals en singletons) is 'state'.
En we kunnen er wel een academische discussie van maken, maar die is al heel vaak gevoerd. De ontwikkelaars van PHP willen uiteindelijk ook van de globals en superglobals af.
Ik heb wel eens naar het Laravel framework gekeken, dat is echt heel erg mooi. Maar ook weer in elkaar geplakt met statics. En ik snap wel waarom, je kunt ze te pas en onpas gebruiken, zonder een instantie van de class te instantieëren. En dan ben ik toch weer terug bij 'state'.
Ik zal eens kijken of ik ergens een voorbeeldje kan opsnorren.
Statics zijn niet fout, maar wel in een OO omgeving.
En die FAQ, tja. Ze zeggen het er mooi. Lithum is niet object geörienteerd, maar functioneel geprogrammeerd. En ze hebben die functies mooi gegroepeerd in classes, die dan dienen als een soort namespace. Niks meer en niks minder. Kan mooi zijn, ik vind het niet mooi in een taal die ook object geörienteerd programmeren ondersteund.
En statics juist goed te testen? Niet mee eens. Bij elke test moet je een nieuwe instance hebben, iets wat niet bewerkt kan zijn door andere tests. Nee, elke test heeft recht op zijn eigen objecten, functies, enz.
Dat ze dat dan moeten gaan oplossen met een verkapte vorm van DI vind ik niet 'juist goed' te noemen, ik vind het hetzelfde als een handdoek om een lekkende kraan binden: Het werkt, alleen het is niet de oplossing.
En die FAQ, tja. Ze zeggen het er mooi. Lithum is niet object geörienteerd, maar functioneel geprogrammeerd. En ze hebben die functies mooi gegroepeerd in classes, die dan dienen als een soort namespace. Niks meer en niks minder. Kan mooi zijn, ik vind het niet mooi in een taal die ook object geörienteerd programmeren ondersteund.
En statics juist goed te testen? Niet mee eens. Bij elke test moet je een nieuwe instance hebben, iets wat niet bewerkt kan zijn door andere tests. Nee, elke test heeft recht op zijn eigen objecten, functies, enz.
Dat ze dat dan moeten gaan oplossen met een verkapte vorm van DI vind ik niet 'juist goed' te noemen, ik vind het hetzelfde als een handdoek om een lekkende kraan binden: Het werkt, alleen het is niet de oplossing.