Variablen aus Funktioneiner Klasse in anderer Klasse auslesen

[Slater]

Hallo Zusammen,

lange ist es her. Habe mal wieder eine Frage. Ist es möglich Variablen einzeln aus einer Funktion einer vererbten Klasse in einer anderen Klasse einer Funktion auszulesen oder ist das so in php nicht vorgesehen?

In etwa so:

 <?php    class Test {        public function color() {          $value1 = 'blue';          $value2 = 'red';      }     }    class Irgendwas extends Test  {      public function paint() {          /*Hier sollen die Variablenen $value1 und $value2 einzeln ausgegeben werden, nicht zusammen.*/        }  }    ?>

Besten Dank für eure Hilfe.

[hellbringer]

Variablen die in einer Funktion erstellt werden existieren nur innerhalb der Funktion und nicht außerhalb. Aber warum verwendest du keien Objekteigenschaften?

[tomBuilder]

trotzdem könnte man sich an zeilenumbrüche gewöhnen Slater

ein beispiel in der eine variable in einer funktion hardcoded zugewiesen wird macht so auch keine sinn finde ich.

[jspit]

Aber warum verwendest du keien Objekteigenschaften?

Ganz einfaches funktionsfähiges Beispiel dafür:

class Test
{
  protected  $value1 = 'blue';          
  protected  $value2 = 'red';      
}

class Irgendwas extends Test
{
  public function paint() : array
  {
    return [
      $this->value1,
      $this->value2
    ];          
  }  
}

$cIregendwas = new Irgendwas;
echo implode(', ',$cIregendwas->paint());
// blue, red 

Funktionen sollten vorzugsweise Werte zurückgeben und nichts per echo ausgeben. Im Beispiel wird ein Array geliefert.

tomBuilder Solche simple Beispiele zu liefern die auch noch Sinn machen ist echt schwer. Vererbung passt hier auch nicht so richtig.

[tomBuilder]

Ich wollte TE dazu bringen werte über argumente in der Methode zu setzen, sowie über return wieder zurückzugeben, wie man das so macht bin funktionen.
aber so ist es auch einleuchtend finde ich jspit
ich verlinke mal:
https://www.peterkropff.de/site/php/getter_setter.htm

[Slater]

Ok, vielen Dank für die vielen Hinweise. Hintergrund meiner Frage ist einfach folgender:

Ich möchte gern weg von der prozessualen Ebene, objektorientiert programmieren und gern Logik und Design trennen. Wenn ich angenommen irgendwelche Werte aus einer DB hole und dann an bestimmten Stellen z. B. einer Tabelle ausgeben möchte, dachte ich ich mir. Ich kann doch die Abfrage in einer Funktion einer Klasse erledigen. Dann die Parameter in einer Funktion einer weiteren Klasse Design übergeben und dann aus geben.

Oder zweites Beispiel:

Ich habe einen Schnittstelle zu irgend einem Zahlungsdienst, möchte Kontodaten meines Accounts abfragen, wo ich auch wieder mehrere Werte zurück bekomme, welche ich ebenfalls in ein Design stecken möchte.

@jsplit: Vielen Dank. Deinen Ansatz kenne und habe ich im Vorfeld schon mal versucht, wenn ich dort aber dann beispielsweise auf eine Schnittstelle zugreifen möchte, funktioniert das nicht.

Ich habe einfach spät angefangen objektorientiert zu arbeiten und am Anfang alles prozessual gemacht. Jetzt möchte ich mich gern umstellen, weil auch Projekte größer werden. Von daher entschuldigt meine teils vielleicht idiotischen Fragen.

[tomBuilder]

versuch es doch mal wie oben angeutet mit der übergabe durch argumente.

, wenn ich dort aber dann beispielsweise auf eine Schnittstelle zugreifen möchte, funktioniert das nicht.

funktioniert nicht, geht es konkreter ?

Ich habe einen Schnittstelle zu irgend einem Zahlungsdienst, möchte Kontodaten meines Accounts abfragen, wo ich auch wieder mehrere Werte zurück bekomme, welche ich ebenfalls in ein Design stecken möchte.

du möchstet irgendwo irgendwas über ne rest api abfrgagen.

definiere einen service welcher die abfragen macht,

das reine request response geschäft, was du ja für alle restapi sachen nutzen kannst, erledigt ein anderer service, welcher bpsw über constructor injection übergeben wird.

wo genau hackt es ?

[rkr]

Prinzipiell solltest du bei deinem Design immer versuchen auf DI bzw. IoC zu setzen, wenn du OOP richtig machen willst. Außer zwei Klassen stehen tatsächlich in einer intuitiven "ist Subtyp von"-Beziehnung. Und das ist eher selten tatsächlich der Fall.

Heißt, wenn du eine Klasse planst, dann ist "extends" und "protected" immer erst mal die letzte Wahl. "Es wäre aber praktisch, wenn ich so und so direkt auf Variablen zugreifen könnte" ist nur sehr selten ein gutes Argument.
Besser ist, wenn eine Klasseninstanz über sog. Constructor-Injection einer anderen Klassen-Instanz zur Verfügung gestellt wird:

<?php
interface Colors {
   /** @return string */
   public function getBlue();
   /** @return string */
   public function getRed();
}

class ThemeColors implements Colors {
   /** @inerhitDoc */
   public function getBlue() {
      return 'skyblue';
   }

   /** @inerhitDoc */
   public function getRed() {
      return 'darkred';
   }
}

class Painter {
   public function __construct(private Colors $colors) {}

   public function paint() {
      yield $this->colors->getBlue();
      yield $this->colors->getRed();
   }
}

$painter = new Painter(new ThemeColors);
foreach($painter->paint() as $color) {
   printf("%s\n", $color);
}

Man muss jetzt nicht zu jeder Klasse auch ein Interface bereitstellen. Das kann man aber leicht nachholen, falls man bei einer Klasse zunächst nicht vorgesehen hat, dass es auch Alternativen geben könnte. In diesem Beispiel hätte die Klasse "ThemeColors" zunächst "Colors" heißen können, bevor man gemerkt hat, dass man doch unterschiedliche Sets von Farben braucht.

So ein Design hat folgende Konsequenzen:

• Deine Klassen werden insgesamt wiederverwendbarer, weil dein Code hauptsächlich gegen Interfaces arbeitet und nicht mehr auf einer konkreten Implementation aufsetzt.
  • Dafür muss man allerdings auch statische Aufrufe auf ein absolutes Minimum reduzieren. Das Schlüsselwort "static" ist damit abzulehnen, außer es gibt einen guten Grund es zu nutzen.
• Deine Code-Struktur wird insgesamt etwas oberflächlicher, was Tools wie PHPStan oder Psalm hilft, schneller durch deinen Code zu laufen.
• Unter DI tendiert eine Code-Struktur dazu, durchschaubarer zu werden, weil man lernt, dass das SRP und TDD zu mehr Entwicklungseffizienz führt.
  • Außerdem wird der Informationsfluss etwas klarer, weil man sich angewöhnt Information nach einer bestimmten Logik fließen zu lassen.
• Irgendwann am Anfang eines PHP-Aufrufs (also im Bootstrap) müssen alle Instanzen zusammengesteckt werden.
  • Wenn man das Dynamisch haben will, dann muss man auf einen DI-Container zurückgreifen, der das für einen macht. PHP-DI wäre so einer.
    • PHP-DI kann außerdem "Autowiring" - also das automatische Instanziieren von Klassen, bei denen alle Interfaces im Constructor sich auch via Autowiring instanziieren lassen. Sollte sich eine Abhängigkeit nicht automatisch instanziieren lassen, dann muss man in der Config von PHP-DI vermerken, wie man dieses Interface instanziiert.
    • Performance? Wenn du PHP7+ benutzt, dann mach dir darum keinen Kopf...
• Wenn dein Code sehr stark auf DI setzt, dann kannst du leichter auf einen App-Server wie Roadrunner aufsetzen.
• ... und alles, woran ich jetzt noch nicht gedacht habe ...