Plugin architectuur

  • Hoi allemaal,


    Op het moment ben ik een idee voor een nieuw project aan het uitwerken. Ik wil plugins toelaten in mijn systeem door ze via een interface te selecteren/uploaden/iets dergelijks. Nu heb ik me de afgelopen tijd verdiept in het toelaten van plugins in je code. Een heleboel informatie gevonden, maar zou graag jullie kijk hierop horen.


    Een van de eerste dingen die ik vond, en naar wat ik zie de meest populaire, is de observer pattern. Hierdoor ben je enkel gelimiteerd aan de hooks die je zelf implementeert.
    Ik wil juist dat het modulair is en makkelijk schaalbaar is. Daardoor ben ik bij de volgende oplossing gekomen: https://stackoverflow.com/ques…ins-for-a-php-application (even scrollen naar de reactie van Volomike).
    Het lijkt mij de beste oplossing doordat je daar vanuit zowat alles kan aanpassen. Hoe zou je overigens deze pattern noemen? Er staat decorator bij, maar dat lijkt me toch net wat anders.


    Heeft iemand een mening hierover? Waarom dit bijvoorbeeld bad practise is of juist een goede strategie. Andere 'patterns' zijn ook zeer welkom!

  • Guest, wil je besparen op je domeinnamen? (ad)
  • Lijkt mij wel een goeie aanpak, waarom een deel van je werk niet slimmer aanpakken door gebruik te maken van object interfaces?
    Ik kan het verkeerd hebben maar de code van Volomike zou perfect gebruik kunnen maken van deze interface functionaliteit waardoor je net die 'hooks' makkelijker kan realiseren en scheiden van elkaar.


    Ik zie het dan als 1 class(plugin) met 1 interface(pluggable), de interface die is uitbreidbaar met jouw modulaire functies en de class extends die interface waardoor je vrij bent in je class om om het even welke handeling uit te voeren met interface functies inbegrepen. je kan wel enkel public functions aanmaken in een interface. en geen construct, destruct o.i.d.


    http://php.net/manual/en/language.oop5.interfaces.php

  • In welk opzicht zou dat werk uit handen nemen of voordeliger zijn? Zou de interface in jouw voorbeeld dan ook leeg zijn? Dat je die dan extend met de plugin, of zie ik dat verkeerd?

  • Ja, en hoeft niet persee leeg te zijn. Ik zie Volomike zijn code voor de class Pluggable makkelijk in een interface passen en overigens de class plugin grotendeels hetzelfde die uiteraard pluggable interface extends. (Class Plugin extends Pluggable, volomike doet het wel omgekeerd)
    Wat je altijd kan doen is de functies onderin het script een deel uit laten uitmaken van de pluggable interface, zo kan je er nog iets vrijer mee werken zowel binnen als buiten je plugin class :)
    Bedoelde dan ook dat in de eerste zin met makkelijker uitbreidbaar aangezien het een beetje vanzelf spreekt om die functionaliteiten over te laten aan de interface zonder dat je deze in plain php hoeft samen te stellen en zonder dat je base class plugin hiervoor hoeft te veranderen.


    De interface pluggable zou op die manier gewoon al jouw voorziene modules/functionaliteiten kunnen bevatten die de plugin class dan netjes kan verwerken (setten/getten?) of gebruiken.

  • Zou je dat misschien kunnen illustreren met een code voorbeeld? Want de Class Plugin extends of implements dan Pluggable? Ben nu zelf aan het expirementeren met jouw idee. Zal als ik er zou uitkom de code plaatsen.


    Edit: Implements it is. Een class kan een interface natuurlijk niet extenden.

  • Ja excuseer inderdaad! Dom van me..
    Ik ga ook dadelijk afsluiten hier met mijn laatste taakjes en kom ik terug op dit onderwerp :)


    Had allesinds al vaker dev talks gevolgd betreffende het onderwerp, niet specifiek plugin gericht maar algemeen voor het efficiënter en dynamischer koppelen van zaken. :)
    Veel van die talks vooral de php gerichte hadden het ook dikwijls over die object interfaces.


    Moet ook eerlijk zijn dat tot voor jouw bericht ik hier ook nog vrij weinig heb rond ontwikkeld maar zal zeker eens een demotje trachten samen te stellen zo dadelijk ;)


    Toch nog geen tijd gevonden tot nu zal voor deze namiddag zijn sorry!

  • Om vast te kunnen stellen of de gekozen oplossingsrichting juist is is het misschien handig om ons te vertellen wat je precies probeert te bereiken.


    Nu zeg je min of meer "ik heb een hamer gekozen, hoe moet ik deze gebruiken" terwijl de daadwerkelijke klus die je probeert uit te voeren het snoeien van de heg is.


    Zoals een van de reacties op SO ook opmerkt:

    Citaat

    I would ask for you to give more information of the nature of php app your writing, And how you see plugins fitting in.

  • Om vast te kunnen stellen of de gekozen oplossingsrichting juist is is het misschien handig om ons te vertellen wat je precies probeert te bereiken.


    Nu zeg je min of meer "ik heb een hamer gekozen, hoe moet ik deze gebruiken" terwijl de daadwerkelijke klus die je probeert uit te voeren het snoeien van de heg is.


    Zoals een van de reacties op SO ook opmerkt:

    In mijn optiek ben ik toch vrij duidelijk. Ik heb research gedaan, maar vind teveel informatie om er echt wegwijs uit te worden. Een van de gevonden design patterns heb ik naar voren gehaald, omdat deze in mijn ogen het best is voor wat ik wil.


    Wat wil ik dan juist? Ik ben op zoek naar een manier om plugins in een ongeschreven script te implementeren. Het uiteindelijke doel is om zoveel mogelijk vrijheid te behouden. Ik wil dus functionaliteiten toe kunnen voegen die ik misschien helemaal niet had bedacht, m.a.w. voorbedachte hooks lijken mij geen oplossing. Mijn vraag was dan ook:


    Citaat van Victor

    Heeft iemand een mening hierover? Waarom dit bijvoorbeeld bad practise is of juist een goede strategie. Andere 'patterns' zijn ook zeer welkom!


    Hoe specifiek moet ik worden als ik een abstract iets wil maken?

  • Je kunt code niet eindeloos abstract houden. Op een gegeven moment moet deze iets concreets doen. En dan moet je tot op zekere hoogte vastleggen hoe iets werkt en wat iets doet / kan doen m.a.w. je zult een aantal ontwerpbeslissingen moeten nemen die dit vastleggen, je offert altijd "vrijheid" op naarmate je applicatie concreter wordt (specifiekere zaken doet).


    Je case is op dit moment veel te algemeen. Je wilt iets maken dat modulair is en schaalbaar met als uiteindelijk doel dat iets (onder andere?) forward compatible is. Uhm, sorry dat ik het zo zeg, maar dat is eigenlijk gewoon de manier waarop je in het algemeen (object georiënteerde) code zou moeten schrijven?


    Op een gegeven moment moet je de stap abstract > concreet maken anders zal je code nooit iets concreets doen.


    Wat versta jij precies onder plugins (hoe zou dit in de praktijk eruit moeten zien)? Om die vraag te kunnen beantwoorden is het ook wel handig als je weet waarvoor je de plugins precies schrijft? In wat voor behoefte voorzien deze? Er bestaat niet zoiets als een universeel programmeer recept (er zijn nu eenmaal verschillende oplossingen voor verschillende vraagstukken, is ook de reden dat er meerdere design patterns bestaan), noch zijn plugins per definitie de oplossing voor jouw specifieke probleem, wat deze ook moge zijn.

  • Hoe ik het nu voor me zie, maar dit is verder dus nog allemaal ongeschreven, is dat ik als het ware een soort basis CMS heb van waaruit ik plugins kan inladen om de functionaliteiten uit te breiden. Deze plugins zijn packages met een standaard opzet en dependencies, etc.
    Zo kan ik voor ieder project andere plugins aankruisen en hoef ik deze er dus niet in te programmeren. Voor het ene project zou ik een userlogin willen hebben en voor het ander juist een betalingsysteem.
    Ik wil de basis ook echt tot de basis beperken, zodat ik qua plugins alle vrijheid behoud. Zo zou ik graag ook de basis cms zelf nog willen kunnen aanpassen met de plugins. (E.g. functies toevoegen als gebruikers beheren, etc.)


    Iets duidelijker?

  • Is voor wat je nu wilt doen het extenden van classes en/of het hebben van een soort van "core" en "application" directory (laatstgenoemde directory wordt eerst gecontroleerd op classes) niet afdoende? Classes zijn van zichzelf al prima uitbreidbaar mits je je bedient van protected (en niet van final)?


    En wie zou dit aan moeten kunnen passen/uit moeten kunnen breiden, en in hoeverre mag dit programmeerbaar zijn? Je zou ook gewoon hele sobere core-modules kunnen hebben, wat sowieso wel een goed idee is om je codebase een beetje klein te houden.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!