[PowerShell] Variabelen aanroepen van "parent?" objecten

[Hemmen]

Stel ik heb onderstaande classes.

Een Project object bevat een Environment object die op zijn beurt weer 1 of meerder VirtualMachine objecten bevat.

Stel ik wil in een functie van de VirtualMachine class variabelen aanroepen van het "parent" project en de "parent" environment objecten. Hoe doe ik dat? Of moet ik dat als argumenten meegeven als ik het VM object aanmaak?

PowerShell:

Class Project {
    // ...
    [Environment] $environment

    Project ($name, $environmentName) {
        // ...
        $this.environment = [Environment]::New($this.environmentName, $this.name)
    }

}

Class Environment {
    // ...
    [VirtualMachine[]] $virtualMachines = $()

    Environment ($name, $projectName) {
        // ...
        foreach ($vm in $config.VirtualMachines) {
            $this.virtualMachines += [VirtualMachine]::New($vm)
        }
    }
}

Class VirtualMachine {
    // ...

    VirtualMachine ($vm) {
        // ...
    }
}

// ...

[ Voor 69% gewijzigd door RobIII op 03-11-2020 14:19 . Reden: 100+ regels irrelevante code verwijderd. ]

[RobIII]

Wil je je voortaan, als je code post, beperken tot enkel relevante(!) code? Ik heb net 100+ regels code verwijderd om je topicstart een beetje leesbaar te maken

Hemmen schreef op dinsdag 3 november 2020 @ 14:04:
Stel ik wil in een functie van de VirtualMachine class variabelen aanroepen van het "parent" project en de "parent" environment objecten. Hoe doe ik dat? Of moet ik dat als argumenten meegeven als ik het VM object aanmaak?

Wat had je zelf al geprobeerd? Je kunt aan een methode toch gewoon een object meegeven? Over het algemeen (uitzonderingen daargelaten) weten objecten niets van hun parents of überhaupt 't bestaan ervan.

[ Voor 64% gewijzigd door RobIII op 03-11-2020 14:22 ]

[Hemmen]

Beste Roblll,

Bedankt voor je reactie. Je hebt gelijk. Ik was al bezig met het verwijderen van regels maar je was me net voor.

Ik dacht aan onderstaande constructie. Dus het "parent" object meegeven aan het "child" object maar ik weet niet of dat een nette manier van programmeren is:

code:

$this.virtualMachines += [VirtualMachine]::New($vm, $this)

[RobIII]

Hemmen schreef op dinsdag 3 november 2020 @ 14:24:
Ik dacht aan onderstaande constructie. Dus het "parent" object meegeven aan het "child" object maar ik weet niet of dat een nette manier van programmeren is

Zoals ik zei: het kan. Maar het is niet heel gebruikelijk en meestal geen goed idee. Hier is iemand die 't wel mooi samenvat.

Ik zou de parent gewoon meegeven aan de method van de child.

[ Voor 6% gewijzigd door RobIII op 03-11-2020 14:29 ]

[Hemmen]

Hoi Roblll,

Ik begrijp je antwoord niet helemaal. Je quote mijn oplossing als niet gebruikelijk maar ik geef in mijn voorbeeld toch de parent mee aan de method van het child object?

[Oon]

Hemmen schreef op dinsdag 3 november 2020 @ 14:41:
Hoi Roblll,

Ik begrijp je antwoord niet helemaal. Je quote mijn oplossing als niet gebruikelijk maar ik geef in mijn voorbeeld toch de parent mee aan de method van het child object?

Het probleem zit hier in het ontwerp, niet de oplossing. Je child afhankelijk maken van de parent is (vaak) geen goed idee. Ook krijgt je child dan toegang tot andere objecten via de parent, wat mogelijk tot andere 'lekken' kan leiden.

De oplossing zelf is in principe niks mis mee, in veel talen heb je hier een parent property voor maar in PowerShell zou je inderdaad de parent zichzelf mee moeten laten geven. De vraag is dan vooral of je dit nodig hebt; hebben deze child objecten de hele parent nodig, of alleen wat metadata die je ook specifiek mee kan geven, waarmee je deze afhankelijkheid en toegang tot de grotere scope oplost?

[ Voor 6% gewijzigd door Oon op 03-11-2020 14:47 ]

[RobIII]

Hemmen schreef op dinsdag 3 november 2020 @ 14:41:
maar ik geef in mijn voorbeeld toch de parent mee aan de method van het child object?

Nu ben ik geen powershell expert, maar je geeft volgens mij de parent mee aan de constructor van je child. Dat is weliswaar (een soort van) een method, maar wel een hele speciale. Waarom zou je de parent niet meegeven aan de eigenlijke method (bijv. child. doSomething("foo", $this) oid). De child een referentie laten "vasthouden" naar de parent is doorgaans geen goed idee.

[Hemmen]

Oon schreef op dinsdag 3 november 2020 @ 14:46:
[...]


Het probleem zit hier in het ontwerp, niet de oplossing. Je child afhankelijk maken van de parent is (vaak) geen goed idee. Ook krijgt je child dan toegang tot andere objecten via de parent, wat mogelijk tot andere 'lekken' kan leiden.

De oplossing zelf is in principe niks mis mee, in veel talen heb je hier een parent property voor maar in PowerShell zou je inderdaad de parent zichzelf mee moeten laten geven. De vraag is dan vooral of je dit nodig hebt; hebben deze child objecten de hele parent nodig, of alleen wat metadata die je ook specifiek mee kan geven, waarmee je deze afhankelijkheid en toegang tot de grotere scope oplost?

Oon schreef op dinsdag 3 november 2020 @ 14:46:
[...]


Het probleem zit hier in het ontwerp, niet de oplossing. Je child afhankelijk maken van de parent is (vaak) geen goed idee. Ook krijgt je child dan toegang tot andere objecten via de parent, wat mogelijk tot andere 'lekken' kan leiden.

De oplossing zelf is in principe niks mis mee, in veel talen heb je hier een parent property voor maar in PowerShell zou je inderdaad de parent zichzelf mee moeten laten geven. De vraag is dan vooral of je dit nodig hebt; hebben deze child objecten de hele parent nodig, of alleen wat metadata die je ook specifiek mee kan geven, waarmee je deze afhankelijkheid en toegang tot de grotere scope oplost?

In de VirtualMachine class wil ik een methode maken om een VM aan te maken. Om de VM aan te kunnen maken heb ik diverse velden nodig uit zowel het project object als het Environment object. Dat was de reden om het zo te doen. Ik zou natuurlijk al deze benodigde velden los mee kunnen geven aan de specifieke methode.

Ik begrijp jullie standpunt. Ik ga eens bedenken hoe ik dit beter op kan lossen in het ontwerp. Bedankt!

[Oon]

Lastig om hier objectief op te reageren omdat het toch wel een beetje gevoel/voorkeur is, maar zou het aanmaken van een VM niet in eerste instantie buiten het VM-object zelf moeten gebeuren?

Als ik de structuur goed begrijp lijkt het me dat je de VM klaar zet in de Environment, vanuit daar de nodige informatie meegeeft aan het VM object, en deze dan zelf z'n ding laat doen. Er zou hier nooit een call terug naar boven nodig moeten zijn.

Ik zou dan in ieder geval de data meesturen en niet de parent zelf, en dan in de child een functie maken om deze te updaten. Wanneer deze data dan in de parent geüpdatet wordt kun je die update doorgeven aan alle child objecten, in plaats van dat de child objecten iedere keer naar de parent gaan kijken.

[Hemmen]

Oon schreef op dinsdag 3 november 2020 @ 15:03:
Lastig om hier objectief op te reageren omdat het toch wel een beetje gevoel/voorkeur is, maar zou het aanmaken van een VM niet in eerste instantie buiten het VM-object zelf moeten gebeuren?

Als ik de structuur goed begrijp lijkt het me dat je de VM klaar zet in de Environment, vanuit daar de nodige informatie meegeeft aan het VM object, en deze dan zelf z'n ding laat doen. Er zou hier nooit een call terug naar boven nodig moeten zijn.

Ik zou dan in ieder geval de data meesturen en niet de parent zelf, en dan in de child een functie maken om deze te updaten. Wanneer deze data dan in de parent geüpdatet wordt kun je die update doorgeven aan alle child objecten, in plaats van dat de child objecten iedere keer naar de parent gaan kijken.

Dus in de Environment class een method maken createVm() ?

[Oon]

Hemmen schreef op dinsdag 3 november 2020 @ 15:10:
[...]


Dus in de Environment class een method maken createVm() ?

Ja zoiets krijg je dan inderdaad. Daar kun je dan een VM object uit laten rollen dat je in de parent bij kan houden voor evt. updates.
Als het object eenmaal aangemaakt is moet die zelf z'n werk kunnen doen (of mbv zijn eigen children) en mocht de parent niet meer bestaan dan zou dit geen probleem moeten zijn.

[Hemmen]

Oon schreef op dinsdag 3 november 2020 @ 15:12:
[...]


Ja zoiets krijg je dan inderdaad. Daar kun je dan een VM object uit laten rollen dat je in de parent bij kan houden voor evt. updates.
Als het object eenmaal aangemaakt is moet die zelf z'n werk kunnen doen (of mbv zijn eigen children) en mocht de parent niet meer bestaan dan zou dit geen probleem moeten zijn.

Dus zoiets:

code:

Class Environment {
    [string] $EnvName
    [VirtualMachine[]] $virtualMachines = $()

    CreateVms ($VirtualMachines) {
        foreach ($vm in $VirtualMachines) {
            $vm.Create($this.EnvName)
        }
    }
}

Class VirtualMachine {
    $name
    $type

    Create ($EnvName) {
        // ...
            Alle acties die de VM daadwerkelijk creeren in de juiste Environment
        // ...
    }
}

Eerst had ik alle code voor het creeeren van de VM in de functie CreateVms gezet maar dat lijkt me niet de juiste plek dus heb ik die code verplaatst naar de methode Create in de class VirtualMachine. Dit is beter toch?

[ Voor 3% gewijzigd door Hemmen op 03-11-2020 16:07 ]

[Oon]

Hemmen schreef op dinsdag 3 november 2020 @ 16:06:
[...]


Dus zoiets:

code:

...

Eerst had ik alle code voor het creeeren van de VM in de functie CreateVms gezet maar dat lijkt me niet de juiste plek dus heb ik die code verplaatst naar de methode Create in de class VirtualMachine. Dit is beter toch?

Ik vind het wel een nette oplossing ja. Als nu het Environment object niet meer bestaat dan blijft het VM object wel gewoon bestaan, en het VM object heeft geen toegang tot bijvoorbeeld andere VM objecten via het Environment object.
Het enige risico dat ik nu nog voorzie is verdwaalde VM objecten (als resultaat van een niet-bestaand Environment object), maar de oplossing daarvan zou heel erg afhankelijk zijn van de praktische toepassing

[Hemmen]

Oon schreef op dinsdag 3 november 2020 @ 16:20:
[...]

Ik vind het wel een nette oplossing ja. Als nu het Environment object niet meer bestaat dan blijft het VM object wel gewoon bestaan, en het VM object heeft geen toegang tot bijvoorbeeld andere VM objecten via het Environment object.
Het enige risico dat ik nu nog voorzie is verdwaalde VM objecten (als resultaat van een niet-bestaand Environment object), maar de oplossing daarvan zou heel erg afhankelijk zijn van de praktische toepassing

Dat is niet zo relevant voor deze toepassing.