OOP constructor wanneer wel en wanneer niet?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ervaren senior C# developer in Arnhem gezocht

Organisatie Voor een van mijn businesspartners uit de omgeving van Arnhem ben ik op zoek naar een ervaren senior C# ASP.NET developer. Deze organisatie maakt complexe software producten voor bepaalde bedrijfsprocessen. Denk hierbij aan beslisregelsystemen, klachtenmanagementsystemen, digitale formulieren of een combinatie hiervan in één portaal. De software wordt specifiek op elke klant zijn wens aangepast. Bij de klanten moet je denken aan enerzijds provincies, gemeenten en overheidsinstanties en anderzijds aan banken, hypotheekverstrekkers en verzekeringsmaatschappijen. Binnen het bedrijf, van circa zestig man groot, heerst een informele sfeer. Collegialiteit staat er hoog in het vaandel, wat je terugziet in de wekelijkse vrijdagmiddagborrel

Bekijk vacature »

Wouter J

Wouter J

20/12/2011 17:52:30
Quote Anchor link
De constructor is een mooie magic method in OOP. Het helpt je om simpele dingen te doen en de classe voor te bereiden op het gebruik.

Alleen nu vraag ik me af. Wat is nou mooier OOP:
Versie 1
De constructor om de naam, wachtwoord, enz. al vast te stellen
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
class User
{
  protected $name;
  protected $pass;

   public function __construct( $name, $pass )
  {

    $this->name = (string) $name;
    $this->pass = (string) uniqid().'24hg4532'.sha1($pass);
  }
}


$wouter = new User('wouter', 'doemaarwat');
?>


Versie 2
Of is dit mooier? En gebruik je een constructor alleen om bepaalde variabelen toe te voegen, connectie te maken met de db, enz.?
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
  class User
  {
    protected $name;
    protected $pass;

    public function setName( $name )
    {

      $this->name = (string) $name;
    }


    public function setPass( $pass )
    {

      $this->pass = (string) uniqid().'2da41gd34'.sha1($pass);
    }
  }


$wouter = new User;
$wouter->setName('wouter');
$wouter->setPass('doemaarwat');
?>
Gewijzigd op 20/12/2011 17:53:26 door Wouter J
 
PHP hulp

PHP hulp

19/09/2019 09:39:48
 
Niels K

Niels K

20/12/2011 18:11:56
Quote Anchor link
Hoi Wouter,

In de constructor zet ik altijd datgene waarvan het object afhankelijk van is (bijvoorbeeld een database) en een setter gebruik ik voor de rest.

Niels
 
Roel -

Roel -

20/12/2011 18:12:21
Quote Anchor link
Ik zou voor het eerste gaan. De constructor doet zoals je zelf al zegt, de voorbereiding van het object.

Die set() methods zijn meer om later nog dingen bij te werken, zoals je wachtwoord in jouw voorbeeld.
 
Erwin H

Erwin H

20/12/2011 18:17:18
Quote Anchor link
Ik zou het af laten hangen van wat het object kan. Als het object ook bruikbaar is zonder de user en password, dan zou ik het niet opgeven in de constructor. Als echter alle functies (of beter functionaliteiten) van het object afhankelijk zijn van deze gegevens dan is het via de constructor meegeven wel al een dwang om ervoor te zorgen dat het gezet is.
Een beetje zoals Niels dus ook zegt.
 
Marco PHPJunky

Marco PHPJunky

20/12/2011 18:20:01
Quote Anchor link
Naar mijn idee is een constructor bedoeld om bepaalde attributen en eigenschappen en vars te laden die noodzakelijk zijn voor de class zelf..


Ik kan er ook naast zitten hoor maar mocht dit zo zijn dan hoor ik dat graag want je bent nooit uitgeleerd :P
 
Wouter J

Wouter J

20/12/2011 19:13:13
Quote Anchor link
Ok, bedankt voor de antwoorden. Het ligt er dus aan wat het nut van de class is.

In dit voorbeeld, een user heeft altijd een username en een password. Je kunt niet een user hebben zonder een naam. Dus je zal user wel meenemen in de constructor en de password niet? Aangezien het password alleen nodig is bij het inloggen en je daar een aparte class voor nodig is?
 
Jelmer -

Jelmer -

21/12/2011 09:44:10
Quote Anchor link
Jep.

In C++ en andere object-georiënteerde talen waar memory management wel belangrijk is heb je RAII als vuistregel. RAII houdt ongeveer in dat wanneer je een object aanmaakt, je het ook direct kan gebruiken. En daarvoor moet je dus bij het aanmaken alle afhankelijkheden meegeven.. via de constructor. Als je dat consequent afdwingt heb je nooit een object dat wel bestaat, maar nog niet gebruikt kan worden. En dat scheelt ook weer een boel checks in het object zelf schrijven (kan dit object gebruikt worden? zijn alle bronnen aanwezig?)

(edit: het slaat niet helemaal op PHP, maar het idee dat wanneer je een object hebt, je het ook daadwerkelijk al direct kan gebruiken is voor mij wel het grote voordeel van constructors goed gebruiken in PHP.)
Gewijzigd op 21/12/2011 09:45:31 door Jelmer -
 
Pim -

Pim -

21/12/2011 13:27:34
Quote Anchor link
Een (halve) uitzondering: proxy objecten
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.