functienaam kort of specifiek (lang)
Stel je wilt functies maken waarmee je een artikel (nieuwsbericht) kan toevoegen, editen, getten en verwijderen. Kies je dan voor hele korte namen, of kies je voor speficieke (lange) namen?
Even 2 hele simpele voorbeeldjes om te laten zien wat ik bedoel.
Kort:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$article = new Article();
$article->add('This is a new article');
$article->edit('Look at my new text!');
echo $article->get();
$article->remove();
?>
$article = new Article();
$article->add('This is a new article');
$article->edit('Look at my new text!');
echo $article->get();
$article->remove();
?>
Specifiek/lang:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$article = new Article();
$article->addArticleText('This is a new article');
$article->editArticleText('Look at my new text!');
echo $article->getArticle();
$article->removeArticle();
?>
$article = new Article();
$article->addArticleText('This is a new article');
$article->editArticleText('Look at my new text!');
echo $article->getArticle();
$article->removeArticle();
?>
Waar kies jij voor en waarom?
Vooral met afkortingen krijg je een naamgeving die té kort is. Niet iedereen begrijpt wat bepaalde afkortingen betekenen, in e-commerce bijvoorbeeld RRP, COD en EOQ.
Verder vind ik dat je vooral ondubbelzinnig moet zijn. Dus niet kortweg $Totaal als je een $TotaalInclusiefBtw naast een $TotaalExclusiefBtw hebt.
Uiteraard moet het duidelijk blijven waar het om gaat, maar daar is in principe ook commenten voor.
En inderdaad wat Ward zegt, als je instence $article is, en je gaat hier functies op aanroepen is het al duidelijk wat je doet.
Wat je eventueel wel zou kunnen doen is ipv add of addArticleText addText doen, zodat je een korte naam hebt maar toch duidelijk ziet dat het om het toevoegen van tekst gaat.
Wellicht ook een idee om het kort te houden is addTxt bijvoorbeeld.
Maar dan kan je toch nog editText() en addText() gebruiken.
Mij is het niet duidelijk dat Article::add() addText is.
(Kris, je hebt gelijk... inderdaad niet duidelijk dat add eigenlijk addText betekent. Het was even een voorbeeldje, maar ik snap wat je bedoelt.)
Nu nog eentje die ik zelf lastig vind. Stel ik heb een class Services waarin services zijn opgeslagen. Omdat services alleen worden toegevoegd vanuit een configuratiebestand is het niet zinnig om een functie te maken waarmee je 1 service kunt toevoegen. Het is zinvoller om altijd een array van services toe te voegen. Als je nu een method add($services) zou maken, is dat dan duidelijk genoeg? Of moet je omdat er altijd meerdere services worden toegevoegd dan toch maar een addServices() method maken? Of is add() voldoende en zet je in het commentaat erbij wat er bedoeld wordt?
Hoe zou je je class noemen?
Ik noem de class Services.
Ik zou hier addServices gebruiken. Dit omdat met alleen add() is het niet duidelijk wat je toevoegt.
Net zoals bij je vorige voorbeeld was zou add() niet duidelijk zijn maar addText() wel.
Zou je dan toch best niet een extra class Service hebben?
(Waarbij je dus members van Service toevoegt aan Services, in een array)
Gewijzigd op 26/04/2013 15:08:45 door Kris Peeters
@Kris: waarom een extra class Service? In de class services zitten alle services. Als ik dan een service nodig heb, doe ik bjiv. dit: $paths = $services->get('paths'); Snap je?
En een extra class Service, ik kan er wel in komen. Ligt er net aan hoe uitgebreid je je container wilt maken, maar goed dat heb ik je al een paar keer uitgelegd dus dat gaan we hier niet herhalen.
Aan 1 service apart heb ik niets; aan een reeks services wel.
Dat je een class Services maakt, begrijp ik.
Maar of je er iets mee bent of niet, een service is en blijft een object.
Het feit dat je apart niets bent met een object, lijkt me onvoldoende reden om niet meer in objecten te denken, waarbij alle functionaliteit van dat ene object wordt geregeld door methodes van de class zonder meervoud
Gewijzigd op 26/04/2013 15:18:36 door Kris Peeters
@Kris: ik snap wel wat je bedoelt... maar ik begrijp niet hoe dat in de praktijk zou moeten werken. Als ik een service uit de services class ophaal, dan krijg ik wel een object terug. Dus het zijn nog steeds objecten.
Als ik dit doe:
$paths = $services->get('paths');
Dan krijg ik 1 object terug.
Maar misschien kun je een voorbeeldje geven van wat jij bedoelt, zodat ik je beter begrijp?
Wat krijg je precies terug als je die get() uitvoert? Wat voor variabele wordt dat?
Is dat enkel maar een string met als waarde het pad naar die service?
In het bovengenoemde voorbeeld is de service "Paths" een service (een object) waarin alle paden zijn opgeslagen. Als ik dus ergens in mijn applicatie een pad nodig heb, doe ik bijv. dit:
$image_paths = $services->get('paths')->get('images');
Of je Service klassen wilt of niet is weer een vraag die ook met je container te maken heeft. Gebruik je slechts alleen Factories als services, dan is dit niet nodig. Maar wil je tagging, building, ect. toevoegen aan je services dan is het gebruik van een Service klasse bijna verplicht (lees: het kan niet zonder).
Dat is het feitelijk ook. Het is een class waaruit ik een service kan ophalen. Die services stel ik in via een config bestand en ze krijgen hun eigen argumenten mee. Ik kan ze ook (wel of niet) sharen en (wel of niet)publiekelijk opvraagbaar maken
Het werkt eigenlijk prima. Misschien klopt het volgens de OOP conventies niet 100% maar ik kan er goed mee uit de voeten. Dus voorlopig laat ik het zo.