getters setters public properties

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Senior Mobile Developer

Sogeti is een organisatie met een goede werksfeer en zo min mogelijk hiërarchische verhoudingen. Ga je bij ons als Senior Mobile Developer aan de slag? Dan werk je dagelijks met collega’s aan de mooiste IT-projecten. Deze snelgroeiende groep collega’s krijgt energie van hun vak en dat merk je op de werkvloer. Onze klantenkring is groot en divers, dat vraagt om flexibiliteit van jou. Tegelijkertijd betekent dit dagelijks nieuwe dingen leren én dat geen werkdag hetzelfde is. Natuurlijk krijg jij de mogelijkheid je te certificeren. We organiseren regelmatig technische Meet-ups en doen we veel aan kennisdeling waarbij iedereen welkom is, zowel

Bekijk vacature »

Senior PHP developer met ambities tot Software Arc

Functie Momenteel zijn ze op zoek naar een ervaren PHP developer die zichzelf graag bezighoudt met zaken als architectuur en de algehele verbetering van structuren en standaarden. Het is eigenlijk meer operationeel als uitvoerend omdat je bezig gaat met zaken als het verder uitrollen en verbeteren van testautomatisering, codereviews, tickets en de doorloop hiervan en architectuurkeuzes. Mocht je hiernaast ook wat DevOps kennis meenemen is dit mooi meegenomen! Vanwege het kleine team maar de wereldwijde impact die zij leveren is er veel focus op kwaliteit. In deze functie werk je aan één van hun belangrijkste applicaties. Hierin werk je nauw

Bekijk vacature »

Front-end developer gezocht

Functie Je komt in een team met ambitieuze developers die de passie voor Front-End met jou delen. Samen ga je aan de slag met leuke en leerzame opdrachten. Het team heeft een eigen budget en financiën en zij bepalen zelf hoe dat besteed en investeert wordt. Je gebruikt tools als JavaScript, Node.js, React, Angular, Typescript en Vue.js wanneer je werkt aan de opdrachten. Daarnaast zul je veel leren van je collega’s en gezamenlijk een leuke tijd doorbrengen tijdens activiteiten zoals wintersport, hackatons en conferentiebezoeken. Je krijgt niet alleen de mogelijkheid Front-End te ontwikkelen, maar ook vooral jezelf. Dit kan behaald

Bekijk vacature »

Senior Airport Developer ( System engineer)

De functie Nice to know (you) De nieuwe A-pier wordt de duurzaamste van Schiphol. Als deze af is ligt er 4000 vierkante meter zonnepanelen op het dak. En de toiletten? Die spoelen door met regenwater. we gaan ervoor: het creëren van de meest duurzame en hoogwaardige luchthavens ter wereld. een toekomstbestendig en duurzaam Schiphol. Daar werken we elke dag hard aan in team Development & Sustainability. Jij bent regisseur, expert én aanjager van de ontwikkeling van Schiphol. Connecting your world Hoe maak je de ambities en doelstellingen van Schiphol concreet in een project? De waarde voor Schiphol naar eisen die

Bekijk vacature »

Delphi Programmeur

Functie omschrijving Onze opdrachtgever is gespecialiseerd in kantoor-bedrijfssoftware en zit gevestigd in omgeving Numansdorp. Als programmeur ben jij bij dit bedrijf met het volgende bezig; Je vertaalt technische en functionele ontwerpen naar kwalitatieve software. Je ontwikkelt, ontwerpt en test software. Je maakt daarbij veel gebruik met de volgende tools & technologieën: Delphi 10.3 (Rio), QuickReport 6. Je krijgt in deze rol veel vrijheid en verantwoordelijkheid. Je levert projecten van A - Z op, en werkt daarbij projectmatig en gestructureerd. Bedrijfsprofiel Dit bedrijf richt zich op maatwerk software oplossingen. Deze software oplossingen worden ingezet in de financiële branche. Het betreft een

Bekijk vacature »

.NET developer

Functie Als .NET developer wordt jij onderdeel van ons ICT team. In dit multidisciplinaire team ben jij samen met onze senior .NET ontwikkelaar en medior .NET ontwikkelaar verantwoordelijk voor ons ERP systeem. In dit systeem (Navision) ga jij leren ontwikkelen. Wij bieden jou dan ook een gedegen opleiding aan, samen met de ondersteuning van onze Senior .NET developer. Daarnaast ga jij aan de slag met ons portaal geschreven in Sharepoint. Verder ben jij verantwoordelijk voor EDI verkeer en het ontwikkelen binnen het ERP systeem en andere toepassingen en rapportages. Van jou wordt verwacht dat jij het proces goed leert kennen

Bekijk vacature »

Cloud Engineer

Ben jij een ervaren Cloud Engineer die complexe omgevingen kan overzien en wil je graag in vaste dienst werken bij een professioneel en kleinschalig bedrijf waar je een belangrijke rol kan spelen? Wij, IntelliMagic in Leiden, ontwikkelen specialistische IT monitoring software die we als SaaS oplossing verkopen aan grote bedrijven in Europa en de VS. We zijn een Nederlands bedrijf met een goede sfeer en met grote waardering voor de persoonlijke inbreng en kwaliteiten van onze medewerkers. Wij zoeken een ervaren Cloud Engineer met academisch denkniveau die verantwoordelijk wordt voor het beheer van de cloud infrastructuur voor onze Europese klanten.

Bekijk vacature »

Back-end Developer

Functie omschrijving Als Back-end Developer heb je de eer om als eerste interne developer bij deze organisatie te beginnen. Op dit moment zijn er externe developers, maar daar wil de organisatie verandering in brengen. Op termijn moet de gehele afdeling uit intern personeel bestaan. Je kan je voorstellen dat de eerste interne developer ook de nodige kennis mee moet brengen. Dat klopt. Je gaat je namelijk aan het begin bekommeren over de externe developers en uiteindelijk over je interne collega's. Verder ga je het volgende doen: Het bedenken, beheren en onderhouden van webportalen, API-koppelingen en applicaties; Je bedenkt en werkt

Bekijk vacature »

Lead C++ Developer

De rol van Lead C++ Developer Als Lead C++ developer bij KUBUS word je verantwoordelijk voor het implementatie design van requirements en de software architectuur van de desktop applicaties van BIMcollab, ons platform voor 3D model-validatie en issue-management bedoeld om de kwaliteit van 3D design-modellen voor gebouwen te verbeteren. Betere 3D modellen leiden tot betere gebouwen, dus zo draag je bij aan verduurzaming van de gebouwde omgeving met slimmer gebruik van materialen, minder verspilling en energie-efficiënte gebouwen. Een goede gebruikerservaring staat bij ons hoog in het vaandel; we gaan in onze ontwikkeling voor innovatie en kwaliteit. In je rol als

Bekijk vacature »

Senior SQR Java Developer

Vacature details Vakgebied: Software/IT Opleiding: Senior Werklocatie: Eindhoven Vacature ID: 13333 Introductie Are you passionate about contributing to the world's most advanced machines. Do you thrive in a challenging environment working with highly motivated and skilled teams? If so, we have the perfect opportunity for you! We are seeking a Senior Software Design Engineer for Sequence Tooling to play a critical role in creating and maintaining mission-critical software applications. In this role, you will focus on achieving maintainable software architecture that is transparent and easy to extend while maintaining a strong focus on software quality. You will work closely with

Bekijk vacature »

C#.NET Developer

Dit ga je doen Ontwikkelen van de Back-end in .NET6 / C# en WebAPI (Focus);) Ontwikkelen van de Front-End in Nodje.js en Angular (secundair); Opstellen van een technisch ontwerp; Testen, documenteren en implementeren van de nieuwe applicatie; Verzorgen van de nazorg, na de implementatie; Het oplossen van bugs en incidenten. Hier ga je werken Als C#.NET Developer binnen deze organisatie kan jij het verschil maken. Zij werken momenteel nog met programmatuur die is ontwikkeld in C++. Hiervan gaan zij afscheid nemen zodra alle nieuwe software in C#.NET geschreven is. Een grootschalig en langdurig project. Voor hen is deze software van

Bekijk vacature »

Applicatie ontwikkelaar

Functie omschrijving Zelfstandige applicatie ontwikkelaar gezocht voor familiair bedrijf in omgeving Rotterdam! Ben jij op zoek naar een nieuwe uitdaging en zoek jij een informele werkgever waar je zelfstandig kunt werken binnen een leuk IT team, lees dan snel verder want wie weet zijn wij op zoek naar jou! Binnen deze rol houdt jij je met het volgende bezig: Onderhouden en ontwikkelen van de IT systemen; Opzetten van Azure Cloud systemen, denk aan interfaces, hardware op de Cloud, webportalen of BI functies; Werken aan scripts binnen verschillende software applicaties, denk aan ERP en CAD; Ontwikkelen en implementeren van MS PowerApps

Bekijk vacature »

Senior front end developer Digital Agency Amsterda

Functie Wij werken in multidisciplinaire teams aan verschillende projecten, echter blijf je niet gebonden aan 1 team. Dit houdt in dat wij verschillende specialisten in dienst hebben en deze door middel van een roulatiesysteem in multidisciplinaire teams laten werken. Het team bestaat vaak uit Frontend developer(s), Backend Developer(s), Designer(s), Tester(s) en Mobile Developer(s). Deze teams worden afgewisseld waardoor jij de mogelijkheid krijgt om met iedereen een keer samen te werken. Als Frontend Developer ben jij ónze Specialist op dit gebied. Jij werkt mee aan verschillende projecten voor verschillende klanten. Denk bijvoorbeeld aan klanten, zoals’; BAM, IDFA en Ultimaker. Hierbij zorg

Bekijk vacature »

C# .NET Ontwikkelaar ASP.NET

Samengevat: Deze werkgever is een inkooporganisatie. Ben jij een ervaren .Net ontwikkelaar? Heb je ervaring met .Net en C#? Vaste baan: C# .NET Developer .Net MBO HBO €3.100 - €4.300 Onze missie is: “Een essentiële bijdrage leveren aan het verlagen van de integrale kostprijs van de aangesloten groothandels, middels het bundelen van inkoopvolume en het creëren van synergie met en tussen de groothandels en leveranciers, met scherpe inkoopprijzen, goede handelscondities en gerichte dienstverlening als resultaat” Zij werken voor MKB klanten. Deze werkgever heeft veel verschillende projecten. Houd jij van afwisseling? Dan zit je bij hun goed! De branche van dit

Bekijk vacature »

Software ontwikkelaar ASP .Net / C#

Functie omschrijving Gezocht! Software ontwikkelaar. Ben jij bekend met termen als ASP .Net, C# en SQL? Ben jij op zoek naar een afwisselende en uitdagende IT-functie binnen de agrarische sector? En omschrijf jij jezelf als zelfstandig, enthousiast en proactief? Dan hebben wij de perfecte functie voor jou! Als Software ontwikkelaar binnen deze organisatie ben je samen met één andere collega verantwoordelijk voor de ontwikkeling en modificatie van het support en controle programma dat binnen dit bedrijf gebruikt wordt. Je gaat hierbij bijdragen aan de vertaling van klantwensen naar effectieve softwareoplossingen. Verder bestaan je werkzaamheden uit: Technische uitwerking van de business

Bekijk vacature »

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

16/03/2013 21:22:58
Quote Anchor link
De laatste tijd ben ik vaak bezig met het (proberen te) optimaliseren van snelheid, en ik kom dan ook regelmatig met vragen die daar mee te maken hebben. Vandaag kreeg ik van iemand op die forum de tip om in plaats van getters en setters gebruik te maken van public properties. Dit scheelt een hoop methods en ook de nodige regels code.

Maar... is het gebruik van public properties nu wel of niet goed? Ik heb deze vraag een tijdje geleden ook gesteld, maar ben nu aan het twijfelen gebracht. Op internet lees je zeer veel artikelen waarin gesteld wordt dat getters en setters "evil" zijn.

Hoe doen jullie het? Wie gebruikt hier voor alle properties getters en setters? En wie gebruikt public properties? En set je die dan in de __construct?

Ik weet het even niet meer, dus ik ben benieuwd naar jullie meningen... ik heb even wat nieuwe input nodig, dus ik hoop op de nodige reacties. Alvast bedankt!
 
PHP hulp

PHP hulp

29/03/2024 09:28:36
 
Frank Nietbelangrijk

Frank Nietbelangrijk

17/03/2013 01:38:46
Quote Anchor link
Ik ben juist afgestapt van public properties. Mijn ervaring is dat het gebruik van getters en setters (allemaal aparte methods) veel fijner is. zo zet ik in een datum setter de datum-string direct om in een datum-class.
De constructor gebruik ik enkel om direct properties te setten vanuit de parameters die meegegeven worden en om properties te voorzien van een default value.
 
Ward van der Put
Moderator

Ward van der Put

17/03/2013 09:32:46
Quote Anchor link
Frank Nietbelangrijk op 17/03/2013 01:38:46:
Ik ben juist afgestapt van public properties. Mijn ervaring is dat het gebruik van getters en setters (allemaal aparte methods) veel fijner is. zo zet ik in een datum setter de datum-string direct om in een datum-class.
Dat is een sterk argument, maar ook een andere argumentatie: je bent niet afgestapt van public properties, maar overgestapt op veel betere setters.

Nut en noodzaak van naïeve setters en naïeve getters mag je wel in twijfel trekken. Om bij het voorbeeld van Frank te blijven: de volgende Bar doet niets meer met de $Geboortedatum dan een variabele heen en weer schuiven in de getter en setter. Ga je hiervan de snelheid testen, dan is de klasse Foo met een public property veel sneller dan de klasse Bar met naïeve setter en getter.

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<?php
// Openbare Foo
class Foo
{
    public $Geboortedatum;
}



// Naïeve Bar
class Bar
{
    protected $Geboortedatum;

    public function setGeboortedatum($param)
    {

        $this->Geboortedatum = $param;
    }


    public function getGeboortedatum()
    {

        return $this->Geboortedatum;
    }
}


function
DoeTest()
{

    $aantalHerhalingen = 100000;

    $start = microtime(true);
    for ($i = 0; $i < $aantalHerhalingen; $i++) {
        $obj = new Foo();
        $obj->Geboortedatum = '2013-04-01';
        $str = $obj->Geboortedatum;
    }

    echo 'Foo: ', (microtime(true) - $start) * 10, "<br />\n";

    $start = microtime(true);
    for ($i = 0; $i < $aantalHerhalingen; $i++) {
        $obj = new Bar();
        $obj->setGeboortedatum('2013-04-01');
        $str = $obj->getGeboortedatum();
    }

    echo 'Bar: ', (microtime(true) - $start) * 10, "<br />\n";
}


$aantalTests = 5;
for($i = 0; $i < $aantalTests; $i++){
    echo "<br />\n<br />\n== Test #", ($i + 1), " ==<br />\n";
    DoeTest();
}


/*

== Test #1 ==
Foo: 1.6562294960022
Bar: 3.4554100036621

== Test #2 ==
Foo: 1.473069190979
Bar: 3.4723591804504

== Test #3 ==
Foo: 1.4610910415649
Bar: 3.473789691925

== Test #4 ==
Foo: 1.5618586540222
Bar: 3.4958720207214

== Test #5 ==
Foo: 1.4596486091614
Bar: 3.5025119781494

*/

[/code]
Gewijzigd op 17/03/2013 09:33:28 door Ward van der Put
 
Frank Nietbelangrijk

Frank Nietbelangrijk

17/03/2013 10:28:59
Quote Anchor link
Ward, dank je wel voor de heldere argumentatie.
 
Ozzie PHP

Ozzie PHP

17/03/2013 15:23:26
Quote Anchor link
Dankjewel voor jullie reacties!

Ward, jouw uitkomsten zijn volgens mij niet in secondes?
In secondes zou je dit krijgen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
== Test #1 ==
Foo: 0.16562294960022
Bar: 0.34554100036621

Dit is bij 100.000 herhalingen. In de praktijk is het dus iets sneller, maar het zijn ook weer geen MEGA verschillen.

Maar goed, alles is meegenomen. Dan kom ik bij de volgende vraag:
Wel of niet overal aparte setters voor gebruiken? Ik gebruik nu om vanuit de construct een (naïeve) property te setten een aparte private setter method. Niet alleen voor properties, maar voor alles wat vanuit de constructor geset moet worden gebruik ik private setter methods. Dus bijv. zoiets:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
<?php
public function __construct($foo, $bar) {
  $this->setFoo($foo) // dit is een naïeve setter, $this->foo = $foo;
  $this->setBar($bar) // dit is een naïeve setter, $this->bar = $bar;
  $this->setServices(); // dit is een "intelligente" setter met logica
  $this->setRoutes(); // dit is een "intelligente" setter met logica
}
?>

Nu heb ik weer een andere benchmark gedaan...

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<?php
class Foo {

    private $foo0;
    private $foo1;
    private $foo2;
    //...
    private $foo9;

    public function __construct($foo) {
        $this->setFoo0($foo);
        $this->setFoo1($foo);
        $this->setFoo2($foo);
        // ...
        $this->setFoo9($foo);
    }


    private function setFoo0($foo) {
        $this->foo0 = $foo;
    }


    private function setFoo1($foo) {
        $this->foo1 = $foo;
    }


    private function setFoo2($foo) {
        $this->foo2 = $foo;
    }


    // ...

    private function setFoo9($foo) {
        $this->foo9 = $foo;
    }

}


class Bar {

    private $bar0;
    private $bar1;
    private $bar2;
    // ...
    private $bar9;

    public function __construct($bar) {
        $this->bar0 = $bar;
        $this->bar1 = $bar;
        $this->bar2 = $bar;
        // ...
        $this->bar9 = $bar;
    }

}

?>

1.000 aanroepen van new Foo('foo') = 0,00677 seconden
1.000 aanroepen van new Bar('bar') = 0,00227 seconden

Rechtstreeks iets setten vanuit de constructor is dus sneller dan het gebruik van aparte (private) setters. En dat brengt mij dan tot de volgende gedachte:

* Moet je in plaats van private setters niet gewoon ALLES vanuit de constructor zelf setten? Of is dat geen goed OOP? Graag jullie meningen hierover.

In plaats van dit:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
<?php
public function __construct($foo, $bar) {
  $this->setFoo($foo) // dit is een naïeve setter, $this->foo = $foo;
  $this->setBar($bar) // dit is een naïeve setter, $this->bar = $bar;
  $this->setServices(); // dit is een "intelligente" setter met logica
  $this->setRoutes(); // dit is een "intelligente" setter met logica
}
?>

...zou je dan zoiets krijgen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
public function __construct($foo, $bar) {
  // Set properties.
  $this->foo = $foo;
  $this->bar = $bar;
  // Set services.
  // ... hier komen een aantal regels code

  $this->services = $services;
  // Set routes.
  // ... hier komen een aantal regels code

  $this->routes = $routes;
}

?>

Wat vinden jullie daarvan? Dus in plaats van diverse setters aanroepen vanuit de constructor, rechtstreeks alles in de constructor zelf setten?

Graag jullie reacties!
 
Willem vp

Willem vp

01/04/2013 09:07:04
Quote Anchor link
Beetje late reactie ;-) maar mijn mening is dat als je een setter alleen gebruikt in een constructor, die setter dan geen bestaansrecht heeft.
 
Erwin H

Erwin H

01/04/2013 10:09:59
Quote Anchor link
Ozzie, volgens mij ben je nu echt op het punt gekomen dat je je moet gaan afvragen of OOP wel geschikt is voor jouw applicatie. Jouw obsesieve drang naar performance verbetering leidt je nu zelfs naar het in twijfel trekken van een belangrijk punt van een OOP applicatie. Misschien wel het belangrijkste voordeel van OOP.

OOP gebruik je doorgaans niet omdat je de snelst mogelijke applicatie wilt hebben, maar gebruik je omdat het grote voordelen biedt in development. Door de modulaire opbouw kan je grote delen van je code hergebruiken en krijg je enorme flexibiliteit in je applicatie waardoor je eenvoudig delen kunt uitwisselen. In dit licht bezien heb ik al eens uiteengezet waarom wat mij betreft public properties (en zelfs protected) uit den boze zijn. Dat is geen algemene waarheid, maar volgens mij begreep je wel de gedachtegang erachter.

Als je nu echter dat voordeel wilt opgeven alleen maar om een performance verbetering te krijgen (waarvan je nog niet eens weet of het nodig is want je hebt nog helemaal niets draaien om te benchmarken), dan kan je beter terug naar spaghetti code. Dat is namelijk altijd sneller dan OOP. Het kost je veel meer tijd in de ontwikkeling, maar blijkbaar is dat niet meer jouw belangrijkste argument.
 
MayDay PHP

MayDay PHP

01/04/2013 12:08:02
Quote Anchor link
Waarom zou je in godsnaam getters and setters gebruiken? Wel ik denk dat het gewoon gemakkelijker is om door de hele applicatie ->getUserId() in plaats van ->userId aan te roepen en wel omdat als er ooit iets fout gaat, kun je gewoon ->getUserId() aanpassen.

Neem nu aan dat je de gebruikers laat chatten en er worden geen html tags gebruikt kunt je gewoon ->getMessage() aanspreken en die setter doet dan op zijn beurt return strip_tags($this->message). Anders zul je door de hele applicatie echo strip_tags($this->message) moeten doen en als er dan andere fouten aan het licht komen mag je weer beginnen met alle $this->message's te vinden.
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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<?php

class User {

    private $userId;
    private $insertDatetime;

    public function setUserId($userId) {
        $this->userId = $user;
    }


    public function setInsertDatetime($insertDatetime) {
        $this->insertDatetime = $insertDatetime;
    }


    public function getUserId() {
        return (int) $this->userId;
    }


    public function getInsertDatetime() {
        return preg_match('!(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})!', $this->insertDatetime) ? $this->insertDatetime : '0000-00-00 00:00:00';
    }

}


# Even een praktisch voorbeeld:
$user = new User();
$user->setUserId('ABC');
$user->setInsertDatetime('InsertDatetime');

echo $user->getUserId();             # Geeft 0 terug
echo $user->getInsertDatetime();     # Geeft 0000-00-00 00:00:00 terug

# Als je dit nu gewoon zou doen (dit werkt niet met bovenstaande class):

$user = new User();
$user->userId = 'ABC';
$user->insertDatetime = 'InsertDatetime';

echo $user->userId;                  # Geeft gewoon ABC terug
echo $user->insertDatetime;          # Geeft gewoon InsertDatetime terug

?>

Als je nu ook nog eens $user->userId & $user->insertDatetime doorgeeft aan de database zullen er al snel fouten volgen en dit kan dus niet met de getters als ze correct zijn afgesteld.

Wat je natuurlijk ook kunt doen is altijd echo (int) $user->userId aanroepen en bij $user->insertDatetime kijken of het wel een correct formaat heeft. Maar dat is in mijn ogen nutteloos en als er security issues zijn moet je gewoon de getter aanpassen en klaar. Anders zul je door de gehele applicatie mogen lopen te zoeken achter $user->userId & $user->insertDatetime.

Waarschijnlijk zul je hier wel wat performance lost hebben, maar ik denk als je de view en alles samen neemt het niet echt een verschil zal maken op de totale performance omdat je anders ook $user->userId moet controleren.

Update
- Praktisch voorbeeld
- Waarom getters en setters gebruiken
Gewijzigd op 01/04/2013 12:32:09 door MayDay PHP
 
Willem vp

Willem vp

01/04/2013 12:32:49
Quote Anchor link
@MayDay:

Afgezien van je getInsertDatetime() zie ik in jouw aanpak geen verschil met public properties. En die method getUserId vind ik zelfs levensgevaarlijk. Als je namelijk een setUserId("blablabla") doet, geeft getUserId een 0 terug. Op Unix-systemen is dat het userid van root. Waarschijnlijk niet wat je wilt. ;-)

Als je bij setUserId() een controle op het te setten id zou inbouwen, heeft het wél toegevoegde waarde. En volgens mij is dat ook precies waar een setter voor is bedoeld. In getUserId() hoef je het id dan ook niet meer te typecasten naar een integer, omdat je al zeker weet dat het een integer is.

Eigenlijk geldt hetzelfde voor get/setInsertDatetime. De check op validiteit zou ik in de setter zetten, zodat je altijd (syntactisch) correcte data in je properties hebt zitten.

In wat voor gevallen zou dat niet werken bij protected properties?
 
MayDay PHP

MayDay PHP

01/04/2013 12:37:46
Quote Anchor link
@Willem vp
Normaal sla je een gebruiker op in een database en dat geeft toch geen problemen als je (int) $user->userId doet of sla ik hier de bal mis?

Tevens is userId een PRIMARY KEY met een AUTO_INCREMENT en zal deze niet eens een INSERT met userId 0 toestaan. Dus geen enkel probleem als je het mij vraagt. Zelfs geen INSERT met überhaupt een userId gedefinieërd. En bij UPDATE zie ik dit ook niet als een probleem omdat de user niet eens terug zal gevonden worden.

Als je protected properties hebt en iemand doet gewoon $this->userId = 'ABC' heb je terug hetzelfde probleem. Maar je zou inderdaad de fouten kunnen controleren bij de setters. Dat is ook de reden dat ik nu op dit moment in mijn applicatie geen enkele public of protected variabele heb staan!

In dit geval denk ik zelfs dat je performance gain zou kunnen hebben, alleen kan ik dit niet aantonen met een benchmark.

Tevens was mijn voorbeeld misschien niet goed genoeg. Maar ik heb genoeg classess in mijn applicatie waar private properties van levensgroot belang zijn.

Denk maar eens aan een tekst die gevalideerd moet worden op xss... of een hash genereren kan je ook gemakkelijker bij getters en setters. Anders moet je door de hele applicatie echo hash_hmac('algo', 'data', 'key'); doen en als je dan ook maar één iets zoals de key wilt veranderen mag je opnieuw gaan zoeken.
Gewijzigd op 01/04/2013 12:50:27 door MayDay PHP
 
Erwin H

Erwin H

01/04/2013 12:41:56
Quote Anchor link
Willem vp op 01/04/2013 12:32:49:
Afgezien van je getInsertDatetime() zie ik in jouw aanpak geen verschil met public properties.

Er is een levensgroot verschil met public properties.

Bij public properties kan jan en alleman erbij. Wil jij later je class aanpassen en de variabele weghalen (maar niet de getter/setter) dan heb je direct een probleem omdat je daarmee inconsistenties in je code kan gaan introduceren. Omdat je geen idee hebt waar in de rest van al je gebouwde applicaties dat property direct wordt aangeroepen kan je al je code gaan filteren om te weten te komen wat je moet aanpassen. Heb je alles op private staan en alleen de getters en setters public, dan is het geen enkel probleem.

Zelfde geldt voor protected properties (hoewel het potentiele probleem kleiner is).

Bij public en protected properties gaan externe factoren bepalen wat je in je class nog kan aanpassen, dat is geen goede eigenschap...
 
Willem vp

Willem vp

01/04/2013 12:58:44
Quote Anchor link
Quote:
Tevens is userId een PRIMARY KEY met een AUTO_INCREMENT en zal deze niet eens een INSERT met userId 0 toestaan.

Fout. Als je een auto_increment-veld insert met een waarde 0 of NULL, dan zal (in ieder geval MySQL) een record inserten met een nieuw gegenereerd id.

Quote:
Als je protected properties heb en iemand doet gewoon $this->userId = 'ABC' heb je terug hetzelfde probleem.

Nee, dan krijg je de foutmelding "PHP Fatal error: Cannot access protected property User::$userId" ;-)
 
MayDay PHP

MayDay PHP

01/04/2013 13:06:09
Quote Anchor link
Ohh. Dat wist ik niet. Maar bij een INSERT zet ik geen userId, dus alsnog geen probleem. En het tweede voorbeeld was als je dat in een andere class aanroept.

Tevens kun je niet altijd op input valideren omdat je bijvoorbeeld als een gebruiker een account aanmaakt nog altijd alles moet controleren.

Ik heb snel eens geprobeerd om een gebruiker toe te voegen in een tabel met AUTO_INCREMENT en dit werkt dus niet. De tabel accepteert wel de query, maar daar stopt het dus ook. Maar alsdanog bij een INSERT in een tabel met AUTO_INCREMENT moet je geen userId definiëren.
Gewijzigd op 01/04/2013 13:09:55 door MayDay PHP
 
Ozzie PHP

Ozzie PHP

01/04/2013 14:06:38
Quote Anchor link
Bedankt voor jullie reacties.

Erwin H op 01/04/2013 10:09:59:
Ozzie, volgens mij ben je nu echt op het punt gekomen dat je je moet gaan afvragen of OOP wel geschikt is voor jouw applicatie. Jouw obsesieve drang naar performance verbetering leidt je nu zelfs naar het in twijfel trekken van een belangrijk punt van een OOP applicatie. Misschien wel het belangrijkste voordeel van OOP.

OOP gebruik je doorgaans niet omdat je de snelst mogelijke applicatie wilt hebben, maar gebruik je omdat het grote voordelen biedt in development.

Erwin, als je goed kijkt, dan zie je dat dit een topic is van een halve maand geleden. Iemand hier op het forum trok het gebruik van private getters en setters in twijfel, en stelde dat je vaak net zo goed public properties kan gebruiken. Dit zette mij aan het denken met als resultaat dit topic. Ik wil OOP helemaal niet opgeven, maar ik wil wel de juiste wegen bewandelen. Uiteindelijk ben ik tot de conclusie gekomen dat ik niet met public properties wil werken. Wel schaf ik de setter functies af die vanuit de construct worden aangeroepen. Alle set functies die vanuit de constructor worden gedaan, zet ik voortaan in de constructor zelf, gescheiden door commentaar-regels. Ik heb dit gebenchmarkt en dit levert wel degelijk een snelheidsvoordeel op. Binnen de class spreek ik voortaan rechtstreeks de class properties aan (in plaats van een get method binnen de class zelf). Ook dit levert weer snelheidsvoordeel op. En properties die van buiten de class moeten worden benaderd krijgen een eigen getter. Mooi toch? :-)
Gewijzigd op 01/04/2013 14:08:43 door Ozzie PHP
 
Erwin H

Erwin H

01/04/2013 14:36:40
Quote Anchor link
Ozzie PHP op 01/04/2013 14:06:38:
Erwin, als je goed kijkt, dan zie je dat dit een topic is van een halve maand geleden.

Daar hoef ik niet goed voor te kijken, dat zag ik direct al. Ondanks dat heb ik toch de opmerking gemaakt omdat jij in dit topic nog niet verder had aangegeven welke kant je op was gegaan. En gezien al je andere vragen in vele topics blijf ik bij het punt. Wat je ermee doet moet je uiteraard helemaal zelf weten.


P.S. of je OOP wil opgeven is niet de vraag, of het niet beter is, is de vraag. Als je zo bezorgd bent over performance als jij, dan is OOP wellicht niet de goede basis om vanuit te gaan.
 
Ozzie PHP

Ozzie PHP

01/04/2013 14:48:16
Quote Anchor link
Ik vind OOP prima... maar ik wil binnen OOP wel de beste (en voor zover mogelijk snelste) oplossingen. Niks meer en niks minder. Vandaar dat ik soms kritische vragen stel. Stel dat we een doorsnee Mercedes en een Ferrari hebben. Laten we de Mercedes dan even vergelijken met OOP. Ik snap echt wel dat die Ferrari een stuk sneller gaat, maar ik wil dan wel dat binnen de mogelijkheden mijn Mercedes zo snel mogelijk gaat. Ik heb geen verstand van auto's, maar stel dat ik in de Mercedes de verkeerde bougies stop, of ergens een te smalle doorvoerkabel gebruik (ik verzin maar wat) dan gaat mijn Mercedes langzamer dan dat ie zou kunnen. En dat is nu juist waarom ik die vragen stel. Om er het maximaal haalbare uit te halen. En dat kan je alleen bereiken door kritische vragen te stellen en te hopen op nuttige antwoorden van overige forumleden. En die antwoorden krijg ik o.a. van jou waarvoor dank.
 
Wouter J

Wouter J

01/04/2013 14:53:01
Quote Anchor link
Maar vragen zoals dit kun je vergelijken met het vragen of het misschien goed is om een Ferrari bodywork op je Mercedes te zetten. Je verpest dan je Mercedes omdat je graag de snelheid van een Ferrari wilt.

(sidenote: Ik houd niet van Mercedes en Ferrari...)
Gewijzigd op 01/04/2013 14:53:37 door Wouter J
 
Ozzie PHP

Ozzie PHP

01/04/2013 14:58:04
Quote Anchor link
Nee nee. nogmaals... ik vraag niet om de snelheid van een Ferrari, maar ik vraag om de beste snelheid binnen de mogelijkheden van een Mercedes, rekeninghoudend met de "regels" van OOP. Laat ik het anders zeggen... ik wil geen dingen doen die de boel vertragen.

(Uiteraard zijn Mercedes en Ferrari slechts bedoeld ter illustratie.)
 
Wouter J

Wouter J

01/04/2013 15:01:45
Quote Anchor link
Maar wat jij hier wilt is 1 van de basis principes van OO buitenboord gooien om snelheid te krijgen.

Bijv. dit kan heel snel zijn:
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
22
23
24
25
26
<?php
class User
{
    var
$name;
    var
$age;
}

class Database
{
    static function connect()
    {

        // ...
    }

    static function query()
    {

        // ...
    }
}


$user = new User;
$user->age = 52;
$user->name = 'Jaap';

Database::connect();
Database::query("INSERT INTO users (name, age) VALUES name = '{$user->name}' AND age = '{$user->age}'");
?>

Maar als je dat gebruikt dan ben je echt geen Mercedes meer...
 
Ozzie PHP

Ozzie PHP

01/04/2013 15:04:51
Quote Anchor link
Wouter, dat wil ik niet. Ik was aan het twijfelen gebracht, maar heb uiteindelijk besloten om het niet te doen. Lees ook deze reactie.
 
Wouter J

Wouter J

01/04/2013 15:08:37
Quote Anchor link
Nee, je hebt het uiteindelijk niet gedaan, maar alleen omdat er een paar goede mensen waren die je van de rand van de afgrond trokken en je op een veilige plek weer uit de dwangbuis haalden ;-)

Kritische vragen stellen is goed, maar het is beter om eerst na te denken of die vraag wel goed is. Of je niet tever doorgaat en eigenlijk alle principes overboord gooit.
Alsof je in een AJAX t-shirtje in de Feyenoord kern gaat zitten omdat dat AJAX t-shirtje nou eenmaal lekkerder zit. Alsof je vloekt in de kerk. Naja, je begrijpt het.
 

Pagina: 1 2 volgende »



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.