PowerShell & Scripting

PowerShell-Klassen

Allgemeine Infos

Seit Version 5.0 hat PowerShell eine eigene Syntax für Klassen und Enums. Eine Klasse beschreibt einen Typ mit Eigenschaften, Methoden und Konstruktoren, jede Instanz trägt eigene Werte. Klassen unterstützen Vererbung von genau einer Basisklasse, statische Mitglieder und die Implementierung von .NET-Interfaces.

Einsatzbereiche sind klassenbasierte DSC-Ressourcen, typisierte Datenstrukturen in größeren Modulen, eigene Validierungsattribute (abgeleitet von ValidateArgumentsAttribute) und IValidateSetValuesGenerator für dynamische ValidateSet-Werte.

Abgrenzung zu [pscustomobject]: Ein PSCustomObject ist ein flexibler Datencontainer ohne festen Typ und ohne Methoden. Klassen lohnen sich, wenn Du Typprüfung, Methoden oder Vererbung brauchst.

Funktionsweise & Details

Aufbau und Besonderheiten:

  1. Definition mit class Name { [string]$Eigenschaft; Name() {} [void] Methode() {} }. Methoden müssen einen Rückgabetyp angeben, ohne Rückgabe [void].
  2. Instanzen entstehen mit [Name]::new() oder per Typumwandlung aus einer Hashtable.
  3. hidden blendet Mitglieder aus Ausgabe, Get-Member und Tab-Vervollständigung aus, macht sie aber nicht privat. Methoden sind immer öffentlich.
  4. Klassen aus Modulen stehen erst nach using module zur Verfügung. Import-Module und #Requires laden nur Funktionen, Aliase und Variablen.
  5. Einmal geladene Klassen lassen sich in einer Sitzung nicht entladen oder neu laden, nach Änderungen ist eine neue Sitzung nötig.

Weitere Einschränkungen: keine Konstruktorverkettung, keine Attribute oder Standardwerte an Methodenparametern, kein ValidateScript an Eigenschaften, keine Interfaces in Skriptcode definierbar. Für ForEach-Object -Parallel gibt es seit PowerShell 7.4 das Attribut NoRunspaceAffinity.

Vorteile & Nutzen

  • Typsicherheit: Eigenschaften haben feste Typen, falsche Werte fallen bei der Zuweisung auf
  • Kapselung: Daten und zugehörige Methoden liegen zusammen, statt über lose Funktionen verteilt zu sein
  • Grundlage für klassenbasierte DSC-Ressourcen, die auch der DSC-v3-Adapter Microsoft.DSC/PowerShell ausführt
  • Erweiterbarkeit: Eigene Validierungsattribute und ValidateSet-Generatoren lassen sich nur über Klassen bauen

Praxisbeispiel

Ein Systemhaus mit 50 Mitarbeitenden pflegt ein Modul, das Kundenumgebungen inventarisiert. Bisher lieferten die Funktionen PSCustomObjects mit wechselnden Eigenschaftsnamen, was Berichte unzuverlässig machte. Das Team definiert Klassen für Server, Lizenz und Kunde mit festen Eigenschaften und einer Methode für den Gesundheitsstatus. Die Skripte, die das Modul nutzen, binden es mit using module ein. Berichte haben seitdem ein stabiles Format.

Worauf sollte man achten?

  • Für einfache Datensätze reicht [pscustomobject], Klassen erst einsetzen, wenn Methoden, Vererbung oder Typprüfung nötig sind
  • Bei der Entwicklung für jeden Test eine neue Sitzung starten, weil geänderte Klassen sonst nicht neu geladen werden
  • hidden nicht als Schutz für Kennwörter verstehen, ConvertTo-Json gibt auch versteckte Eigenschaften aus
  • Klassen, die in ForEach-Object -Parallel genutzt werden, mit NoRunspaceAffinity kennzeichnen (ab 7.4)

Fazit

PowerShell-Klassen bringen Struktur in größere Module und sind Pflicht für eigene DSC-Ressourcen. Für kleine Skripte bleibt [pscustomobject] die einfachere Wahl.

Weiterführende Links

Verwandte Artikel