Mehrere Objekte oder mehrere Arrays

Ich schalte 4 Relays über verschiedene Sensoren. Momentan habe ich 4 Arrays für die Relays angelegt.
uint8_t relay_pin[4]; //GPIO
uint8_t relay_type[4]; //0=active LOW, 1 = active HIGH, 2 = ESP8266 WiFi Relay
String relay_name[4]; //Heating, Ventilation, Watering, Illumination
uint8_t relay_state[4]; //relay state (on or off)

Was verbraucht weniger Speicher und ist C++ like? Die Arrays so lassen oder eine Klasse Relay erstellen und dann im Sketch 4 Objekte Relay1, Relay2, Relay3, Relay4 konstruieren und deren Eigenschaften und Funktionen verwenden?

Da C++ u.A. eine OOP Sprache ist, könnte die Antwort klar sein.

Dann werde ich das mal tun und eine Lib schreiben.
Nachteil: Wieder ein Haufen Arbeit ;-(
Vorteil: Die Lib ist immer wieder in anderen Projekten verwendbar :wink:

Es ist nicht eine Frage des Speichers, sondern der Übersichtlichkeit. Natürlich sollte man hier Arrays aus Objekten verwenden

Du kannst es 'C' like :wink: machen und legst eine Struktur mit deinen 4 Variablen an, definierst dann ein 'Array of structs' und arbeitest ansonsten weitgehend so wie bisher.

Oder Du machst es OOP-mäßig und legst eine Klasse an, in der deine 4 Daten gekapselt sind. Dann definierst Du Methoden für den Zugriff auf die Daten bzw. für die Funktionalität deiner Relais.
Im Sketch kannst Du dann ein Array mit den 4 Objekten anlegen und die Relais über die Methoden steuern.

Die OOP-Variante wird wohl etwas mehr Speicher brauchen, ist aber für eine Wiederverwendbarkeit besser. Wenn Du die 'Schnittstelle' ( = die Methodenaufrufe ) gleich lässt, kannst Du klassenintern Anpassungen / Erweiterungen machen, ohne dass der Sketch davon was merkt. Beispiel: Wenn dir die Pins ausgehen, kannst Du die Relais dann über Schieberegister oder I2C ansteuern, und dein Sketch merkt nichts davon.

Die OOP-Variante wird wohl etwas mehr Speicher brauchen,

Das ist hier nicht zu erwarten.

Beispiel: Wenn dir die Pins ausgehen, kannst Du die Relais dann über Schieberegister oder I2C ansteuern, und dein Sketch merkt nichts davon.

Genau das ist die Crux. Die Klasse müsste beides können, Relais an GPIO's oder PCF857x.
Ist aber schon in Arbeit. Was soll man sonst bei dem Schit-Wetter machen.

Bei der Ausgabe über PCF857x hast Du ja einen Parameter mehr belegt (I2C-Adresse), der bei direkter Ausgabe 0 ist (Default). Wenn Du den als letzten Wert in der Initialisierungsliste/ im Konstruktor hast, kannst Du den bei normalen Pins weg lassen.

Daran kannst Du sie einfach unterscheiden.

Gruß Tommy

freddy64:
Genau das ist die Crux. Die Klasse müsste beides können, Relais an GPIO's oder PCF857x.

Womit wir dann bei Vererbung sind.

Eine Oberklasse die alle Variablen und Methoden enthält die für alle Varianten gleich sind. Die Ausgabe-Methode ist abstrakt/pure virtual und wird erst von den zwei Unterklassen implementiert. Unterklassen können dann auch zusätzliche Variablen und Konstruktoren enthalten, z.B. für die I2C Adresse

Alternativ könnte man auch eine Oberklasse haben die schon die GPIO Ausgabe implementiert. Die Methode macht man virtuell und überschreibt die in der PCF Unterklasse.

Mit Vererbung wäre der saubere Weg.

Man könnte aber auch in der Ausgabemethode unterscheiden, ob es eine I2C-Adresse >0 gibt und dann in die PCV-Variante verzweigen.

Gruß Tommy