Ik ben een Request class aan het maken. Via deze class kan ik bijv. het domein van de opgevraagde URL opvragen, of het subdomein, en of het een beveiligde (https) verbinding betreft. De gegevens haal ik op uit de $_SERVER array. Nu had ik gewoon allemaal public funtcions gemaakt. Echter... ik realiseer me ineens dat gedurende 1 request de $_SERVER array altijd hetzelfde is. Het zou dan raar zijn als ik telkens als ik de Request class nodig heb "new Request()" zou doen.
Nu vraag ik me af wat volgens jullie de beste oplossing is. Ik zou een singleton kunnen maken, zodat je niet "$request = new Request()" doet, maar "$request = Request::getInstance()". Wat ik ook kan doen is iedere functie in de Request class static maken, zodat ik het domein bijv. als volgt opvraag: $domain = Request::getDomain();
hmmm, okeej... maar als je dan een subrequest uitvoert... maak je dan opnieuw een request object aan? Maar dat kan toch niet, want $_SERVER, $_POST etc. is dan toch nog steeds hetzelfde?
Maar dat vind ik dus het lastige. Ik wil een simpel framework bouwen... en dan vraag ik me dus ook af waar ik dan die subrequests voor nodig zou hebben... en als ik dan al een subrequest zou hebben, waarvoor zou ik dan een nieuw request object moeten aanmaken.
Ik wil vooral zo effectief mogelijk programmeren en niet "programmeren om het programmeren". Testen ga ik niet doen, dus vandaar mijn vraag of ik de constructor dan niet gewoon private zou maken.
Oké, dan laten we het hele subrequest verhaal varen. Alsnog moet je je OO applicatie niet dichtbouwen, je moet niet zorgen dat elke weg naar uitbreiding geblokkeerd is. Daarom moet je dus niet je constructor opeens private gaan maken of een singleton gebruiken.
Tevens testen niet doen? Dat weet je zeker? Je weet dat zodra je gaat testen je code logischer wordt, je sneller script omdat je alles test en je weet dat testen je later extreem veel voordeel op gaat leveren? Denk bijv. aan fixen van een bug, allereerst moet je de bug kunnen nabootsen en vervolgens moet je er maar zeker van zijn dat alles in je framework nog werkt nadat je de bug denkt opgelost te hebben.
Wat je doet is dat je een test schrijft die de bug nabootst en dat je vervolgens de bug oplost en dan alle tests van het framework afspeelt, slagen alle tests dan weet je zeker dat alles in je framework niet werkt.
Ik ben best benieuwd naar jou redenen om niet te gaan testen.
Nou, zeg nooit nooit... maar ik wil me daar nu niet mee bezig houden. Zoveel tijd heb ik niet. Da's de voornaamste reden.
Voor de rest wil ik m'n framework lichtgewicht maken. Veilig, efficiënt en doeltreffend. Zonder veel rare fratsen.
Mijn reden waarom ik de contructor private zou maken, zou dan zijn om te voorkomen dat ik alle globals zou gaan doorgeven, terwijl er een makkelijkere methode is. Door de contstructor private te maken, dwing je jezelf om altijd de makkelijke functie te gebruiken.
