Separation of Concerns
- Onderwerp starter the goose
- Startdatum
- Status
Frats
Terugkerende gebruiker
- Lid geworden
- 22 nov 2008
- Berichten
- 4.492
Hoi,
PHP kent geen compile-time, aangezien het een scripting taal is.
Verder is "Seperation of Concerns" een design pattern, dus ik begrijp niet helemaal hoe je dat toe wilt passen op de include (wat trouwens een control structure is, geen functie) gezien het nogal low level is...
Je kunt include gebruiken voor SoC, je kunt het ook gebruiken om SoC stuk te maken...
Dus wat wil je nou precies weten?
PHP kent geen compile-time, aangezien het een scripting taal is.
Verder is "Seperation of Concerns" een design pattern, dus ik begrijp niet helemaal hoe je dat toe wilt passen op de include (wat trouwens een control structure is, geen functie) gezien het nogal low level is...
Je kunt include gebruiken voor SoC, je kunt het ook gebruiken om SoC stuk te maken...
Dus wat wil je nou precies weten?
Hey frats,
dank je om te antwoorden.
Aangezien separation of concerns stelt dat je taken van elkaar moet scheiden wanneer ze een andere change driver hebben, kan je met include dacht ik separation of concerns bereiken.
Een voorbeeld:
Index.html:
Toepassing Separation of Concerns
In de code hierboven, zien we dat de opmaak gescheiden wordt van de content. De opmaak wordt immers bepaald in style.css, waarnaar verwezen wordt in <head>. Dit volgt de stelling van Separation of Concerns aangezien de opmaak een andere change driver heeft als de content.
Veronderstel dat de website bestaat uit N aantal pagina’s. Onder de assumptie van unlimited systems evolution, zou het aantal pagina’s van de website oneindig worden. Indien de opmaak niet gescheiden is en integraal deel uitmaakt van het content bestand, zal een wijziging van de opmaak leiden tot een oneindig aantal codeer veranderingen. De website is bijgevolg niet stabiel, daar de impact van een verandering niet constant blijft naarmate het systeem groeit. De impact van een verandering is dus niet enkel afhankelijk van de aard van de verandering, maar tevens van de grootte van het systeem. Hierdoor ontstaan combinatorische effecten.
Door het scheiden van de opmaak in een apart bestand (dat door het content bestand wordt opgeroepen), wordt dit probleem opgelost. Bij een wijziging van de opmaak hoeft dit immers nog maar op één plaats aangepast te worden, namelijk in style.css. Hierdoor wordt stabiliteit bereikt en zijn er geen combinatorische effecten meer aanwezig.
Schending Separation of Concerns
We zien dat het menu integraal deel uitmaakt van index.html. Het menu werd dus niet gescheiden van de content. Dit is een schending van Separation of Concerns, aangezien de content van het menu een andere change driver heeft dan de content van index.html. Het menu dient daarom als een aparte taak aanzien te worden.
Veronderstel dat de website uit N aantal pagina’s bestaat. Onder de assumptie van Unlimited systems evolution, wordt N oneindig. Indien het menu niet gescheiden is en integraal deel uitmaakt van het content bestand, zal een wijziging in het menu leiden tot een oneindig aantal codeer veranderingen. De website is dus niet stabiel (zie boven).
Door het scheiden van het menu in een apart bestand (dat door het content bestand wordt opgeroepen), wordt dit probleem opgelost. We kunnen dit doen door gebruik te maken van php include, zoals hieronder wordt getoond. Een wijziging aan het menu, hoeft nu enkel nog maar doorgevoerd te worden in navigatie.php. Hierdoor wordt stabiliteit bereikt en zijn er geen combinatorische effecten meer aanwezig.
Index.php:
Navigatie.php:
Ik zou denken dat bovenstaande redenering klopt. Maar bereik je op run-time dan nog altijd separation of concerns?
Alvast bedankt!
The goose
dank je om te antwoorden.
Aangezien separation of concerns stelt dat je taken van elkaar moet scheiden wanneer ze een andere change driver hebben, kan je met include dacht ik separation of concerns bereiken.
Een voorbeeld:
Index.html:
PHP:
<html>
<head>
[…]
<link href="style.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="menu">
<ul>
<li class="active"><a href="index.html" accesskey="1" title="">Home</a></li>
<li><a href="praesidium.html" accesskey="2" title="">Praesidium</a></li>
<li><a href="activiteiten.html" accesskey="3" title="">Activiteiten</a></li>
<li><a href="fotos.html" accesskey="4" title="">Foto's</a></li>
<li><a href="voetbal.html" accesskey="5" title="">Voetbal</a></li>
<li><a href="skireis.html" accesskey="6" title="">Skireis</a></li>
<li><a href="geschiedenis.html" accesskey="7" title="">Geschiedenis</a></li>
<li><a href="nieuwsbrief.html" accesskey="8" title="">Gastenboek</a></li>
<li><a href="sponsors.html" accesskey="9" title="">Sponsors</a></li>
</ul>
</div>
[…]
</body>
</html>Toepassing Separation of Concerns
In de code hierboven, zien we dat de opmaak gescheiden wordt van de content. De opmaak wordt immers bepaald in style.css, waarnaar verwezen wordt in <head>. Dit volgt de stelling van Separation of Concerns aangezien de opmaak een andere change driver heeft als de content.
Veronderstel dat de website bestaat uit N aantal pagina’s. Onder de assumptie van unlimited systems evolution, zou het aantal pagina’s van de website oneindig worden. Indien de opmaak niet gescheiden is en integraal deel uitmaakt van het content bestand, zal een wijziging van de opmaak leiden tot een oneindig aantal codeer veranderingen. De website is bijgevolg niet stabiel, daar de impact van een verandering niet constant blijft naarmate het systeem groeit. De impact van een verandering is dus niet enkel afhankelijk van de aard van de verandering, maar tevens van de grootte van het systeem. Hierdoor ontstaan combinatorische effecten.
Door het scheiden van de opmaak in een apart bestand (dat door het content bestand wordt opgeroepen), wordt dit probleem opgelost. Bij een wijziging van de opmaak hoeft dit immers nog maar op één plaats aangepast te worden, namelijk in style.css. Hierdoor wordt stabiliteit bereikt en zijn er geen combinatorische effecten meer aanwezig.
Schending Separation of Concerns
We zien dat het menu integraal deel uitmaakt van index.html. Het menu werd dus niet gescheiden van de content. Dit is een schending van Separation of Concerns, aangezien de content van het menu een andere change driver heeft dan de content van index.html. Het menu dient daarom als een aparte taak aanzien te worden.
Veronderstel dat de website uit N aantal pagina’s bestaat. Onder de assumptie van Unlimited systems evolution, wordt N oneindig. Indien het menu niet gescheiden is en integraal deel uitmaakt van het content bestand, zal een wijziging in het menu leiden tot een oneindig aantal codeer veranderingen. De website is dus niet stabiel (zie boven).
Door het scheiden van het menu in een apart bestand (dat door het content bestand wordt opgeroepen), wordt dit probleem opgelost. We kunnen dit doen door gebruik te maken van php include, zoals hieronder wordt getoond. Een wijziging aan het menu, hoeft nu enkel nog maar doorgevoerd te worden in navigatie.php. Hierdoor wordt stabiliteit bereikt en zijn er geen combinatorische effecten meer aanwezig.
Index.php:
PHP:
[…]
<div id="menu">
<?php include("navigatie.php"); ?>
</div>
[…]Navigatie.php:
PHP:
<?php
$menu = array(
array("index.php",1,"Home"),
array("praesidium_2009.php",2,"Praesidium"),
array("activiteiten.php",3,"Activiteiten"),
array("fotos.php",4,"Foto's"),
array("voetbal.php",5,"Voetbal"),
array("skireis.php",6,"Skireis"),
array("geschiedenis.php",7,"Geschiedenis"),
array("gastenboek.php",8,"Gastenboek"),
array("sponsors.php",9,"Sponsors")
);
[…]
?>Ik zou denken dat bovenstaande redenering klopt. Maar bereik je op run-time dan nog altijd separation of concerns?
Alvast bedankt!
The goose
Frats
Terugkerende gebruiker
- Lid geworden
- 22 nov 2008
- Berichten
- 4.492
Je kunt met include inderdaad seperation of concerns bereiken...
Zoals jij het nu maakt (hoewel je voorbeeld nog niet compleet is, maar dat zie je vast zelf ook) lijkt het wel redelijk te werken, en zul je idd het menu nog maar op 1 plek hoeven te wijzigen.
Wat ik echter nog steeds niet begrijp is waarom het relevant is of je tijdens run-time nog steeds seperation of concerns hebt? Op dat moment is de cpu bezig en die maakt het echt niet uit of je code wel of niet onderhoudbaar is; dat is alleen relevant voor de programmeur.
Heb je al naar de grotere PHP frameworks (zoals ZEND) gekeken? Die maken heel goed gebruik van includes door pagina's op te breken in 'views', die elk een herbruikbaar stukje html voorstellen; je menu zou dus een file zijn, je wireframe zou een file zijn, en elk van je pagina's zou een file zijn.
Vervolgens zou de view natuurlijk ook dynamisch gevuld worden uit een database, dus als je meerdere artikelen zou tonen met dezelfde layout, zou daar maar 1 view voor zijn, die in de runtime ingevuld zou worden afhankelijk van het verzoek van de user.
Zoals jij het nu maakt (hoewel je voorbeeld nog niet compleet is, maar dat zie je vast zelf ook) lijkt het wel redelijk te werken, en zul je idd het menu nog maar op 1 plek hoeven te wijzigen.
Wat ik echter nog steeds niet begrijp is waarom het relevant is of je tijdens run-time nog steeds seperation of concerns hebt? Op dat moment is de cpu bezig en die maakt het echt niet uit of je code wel of niet onderhoudbaar is; dat is alleen relevant voor de programmeur.
Heb je al naar de grotere PHP frameworks (zoals ZEND) gekeken? Die maken heel goed gebruik van includes door pagina's op te breken in 'views', die elk een herbruikbaar stukje html voorstellen; je menu zou dus een file zijn, je wireframe zou een file zijn, en elk van je pagina's zou een file zijn.
Vervolgens zou de view natuurlijk ook dynamisch gevuld worden uit een database, dus als je meerdere artikelen zou tonen met dezelfde layout, zou daar maar 1 view voor zijn, die in de runtime ingevuld zou worden afhankelijk van het verzoek van de user.
SvU
Terugkerende gebruiker
- Lid geworden
- 26 jan 2007
- Berichten
- 1.534
Eh, nee, een principe. Design patterns helpen je dat te bereiken.
Verkeerd gezien. Ik ben nog niet zo goed met officiele principes en patterns - Status
