Logische Operatoren als Aufzählungstyp

[bernau]

Wir sind mal wieder beim Thema "Rad nicht neu erfinden".

Ich möchte einer Funktion mehrere Werte als Array übergeben und diese sollen logisch verknüpft werden. Die Verknüpfungsart soll als Parameter übergeben werden.

Beispiel

Delphi-Quellcode:

result1 := meineFunktion(loOr,[Value1,Value2,Value3]);
result2 := meineFunktion(loAnd,[Value1,Value2,Value3]);

Ich kann natürlich loOr oder loAnd usw. selber definieren.

Delphi-Quellcode:

type
  TLogicalOperators = (loOr, loAnd, loXor, loNOr, loNAnd, loNXor);

Aber bei meinem Glück ist dieser Aufzählungstyp schon irgenwo definiert.

Jemand eine Ahnung wo das definiert sein könnte?

[Sherlock]

Dein Delphi sollte wissen, wo es schon definiert wurde. Spontan würde ich einen der fraglichen Bezeichner markieren und über Refactor-> Unit suchen die vorherige Deklaration ermitteln. andererseits dürfte es einfacher sein, die Biester umzubenennen.

Sherlock

[Der schöne Günther]

Nicht dass ich wüsste, vermutet hätte ich so etwas in

Delphi-Quellcode:

System.Math

oder

Delphi-Quellcode:

System.Types

. Aber da finde ich nichts.

[bernau]

Zitat:

Zitat von Der schöne Günther (Beitrag 1283905)

Nicht dass ich wüsste, vermutet hätte ich so etwas in

Delphi-Quellcode:

System.Math

oder

Delphi-Quellcode:

System.Types

. Aber da finde ich nichts.

Da habe ich auch schon geschaut.

Ich werde es dann selber definieren.

[bernau]

Zitat:

Zitat von Sherlock (Beitrag 1283885)

Dein Delphi sollte wissen, wo es schon definiert wurde. Spontan würde ich einen der fraglichen Bezeichner markieren und über Refactor-> Unit suchen die vorherige Deklaration ermitteln. andererseits dürfte es einfacher sein, die Biester umzubenennen.

Sherlock

Wie gesagt. Ich weis nicht, ob es überhaupt definiert ist. Die Bezeichner im Beispiel hatte ich mir ausgedacht. Da ich aber kein Paralleluniversum entwickeln will, dachte ich, daß ich mal so in die Runde frage.

[himitsu]

Auch wenn ich nicht glaube, daß es NOr, NAnd und NXor irgendwo im Delphi geben wird,
kann man doch einfach mal in den Delphi-Quellcodes danach suchen lassen?

Delphi-Quellcode:

([a-z_]+nor)

+ nur ganze Wörter :stupid:

[Neutral General]

Ich denke nicht dass es sowas schon gibt aber ganz ehrlich gesagt würde ich mir für so ein kleines Enum nicht so viele Gedanken oder sogar so einen Thread machen.
Du hast dir jetzt minuten- oder vllt sogar stundenlang (was ich nicht hoffe^^) Gedanken gemacht und einen relativ langen Beitrag geschrieben um herauszufinden ob du dir diesen 1-Zeiler möglicherweise sparen kannst:

Delphi-Quellcode:

TLogicalOperators = (loOr, loAnd, loXor, loNOr, loNAnd, loNXor);

:P :wink:

Selbst wenn du später (durch Zufall) herausfinden solltest dass es sowas schon gibt sollte das duch Refactoring im Zweifelsfall schnell umgestellt sein ;)

[Mavarik]

Wie wäre es mit einem lokalen Typen der Klasse?

[Dejan Vu]

Man kann zwei Listen miteinander verknüpfen und -soweit ich mich erinnere- einen Verknüpfungsoperator mit angeben. Ich meine, die heißen 'loAnd' (nur, was in beiden ist) 'loOr' etc. ('lo'=ListOperation). Obwohl, da bin ich mir nicht so sicher, ich kann mich aber an loXor erinnern.

Wieso führst Du überhaupt einen Enum ein? Schreib doch einfach die paar Methoden separat? Oder mach es mit einzelnen Klassen. Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Wieso führst Du überhaupt einen Enum ein? Schreib doch einfach die paar Methoden separat? Oder mach es mit einzelnen Klassen. Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Operator overloading?

[Dejan Vu]

Mavarik, deine Bemerkung ist mir zu minimalistisch. Bitte (ich bin ein einfacher Mann): Subjekt, Prädikat, Objekt. ;-)

Oder willst Du Operatoren für die Arrays einführen?

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1283910)

Auch wenn ich nicht glaube, daß es NOr, NAnd und NXor irgendwo im Delphi geben wird,
kann man doch einfach mal in den Delphi-Quellcodes danach suchen lassen?

Delphi-Quellcode:

([a-z_]+nor)

+ nur ganze Wörter :stupid:

Habe ich gemacht. Aber nichts gefunden. Aber es ist ja wie mit Google. Der Suchbegriff der eingegeben wird, ist meist der Falsche. ;-)

[bernau]

Zitat:

Zitat von Neutral General (Beitrag 1283916)

Du hast dir jetzt minuten- oder vllt sogar stundenlang (was ich nicht hoffe^^) Gedanken gemacht und einen relativ langen Beitrag geschrieben....

Ne ne. Kurz drüber nachgedacht, gesucht, nichts gefunden und hier geschrieben. Natürlich kann ich auf die Schnelle den Type selber definieren. Aber es hat mich trotzdem interessiert.

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Wieso führst Du überhaupt einen Enum ein? Schreib doch einfach die paar Methoden separat? .... Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Ist auch ein Argument.

[bernau]

Danke erst mal allen zusammen. Frage ist für mich erst mal beantwortet.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283927)

Mavarik, deine Bemerkung ist mir zu minimalistisch. Bitte (ich bin ein einfacher Mann): Subjekt, Prädikat, Objekt. ;-)

Oder willst Du Operatoren für die Arrays einführen?

ok dann nochmal:

ein

Delphi-Quellcode:

result2 := meineFunktion(loAnd,[Value1,Value2,Value3]);

Kann ich doch auch schreiben als

Delphi-Quellcode:

Result2 := Value1 and Value2 and Value3;

Dann muss ich "nur" noch für meinen Value Typen die entsprechende Operator Classe

Delphi-Quellcode:

BitwiseAnd(a: Typ; b: Typ): Ergebnistyp

definieren und schon kann ich wieder wunderschönen Clean-Code schreiben...

Mavarik

[Dejan Vu]

Klar, aber er hat vielleicht ein ganzes Array und möchte das dynamisch machen...

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1283945)

Klar, aber er hat vielleicht ein ganzes Array und möchte das dynamisch machen...

Richtig.

[Stevie]

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Wieso führst Du überhaupt einen Enum ein? Schreib doch einfach die paar Methoden separat? Oder mach es mit einzelnen Klassen. Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Hättest du das nicht geschrieben, hätte ich es jetzt getan :thumb:
Guckstu das

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1283948)

Zitat:

Zitat von Dejan Vu (Beitrag 1283945)

Klar, aber er hat vielleicht ein ganzes Array und möchte das dynamisch machen...

Richtig.

???

Delphi-Quellcode:

result2 := meineFunktion(loAnd,[Value1,Value2,Value3]);

Sieht mir nicht Dynamisch aus, sondern wie variable Parameter Anzahl...

Aber egal DU must ja wissen was Du brauchst...

[bernau]

Zitat:

Zitat von Mavarik (Beitrag 1283960)

Zitat:

Zitat von bernau (Beitrag 1283948)

Zitat:

Zitat von Dejan Vu (Beitrag 1283945)

Klar, aber er hat vielleicht ein ganzes Array und möchte das dynamisch machen...

Richtig.

???

Delphi-Quellcode:

result2 := meineFunktion(loAnd,[Value1,Value2,Value3]);

Sieht mir nicht Dynamisch aus, sondern wie variable Parameter Anzahl...

Aber egal DU must ja wissen was Du brauchst...

Das hier war jetzt ein Beispiel. Könnte aber auch folgendes machen

Delphi-Quellcode:

result2 := meineFunktion(loAnd,EinDynArrayWelches200WerteHabenKann);

[bernau]

Zitat:

Zitat von Stevie (Beitrag 1283953)

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Wieso führst Du überhaupt einen Enum ein? Schreib doch einfach die paar Methoden separat? Oder mach es mit einzelnen Klassen. Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Hättest du das nicht geschrieben, hätte ich es jetzt getan :thumb:
Guckstu das

Den Enum wollte ich einführen, da ich die Logische Operation Dynamisch ermitteln wollte.

Delphi-Quellcode:

Procedure Irgendetwas;
var
  lOperator:TLogicalOperator;
  lMeinArray:TDoubleDynArray;
begin
  lOperator:=GibMirDenOperator;
  FuelleMeinArray(lMeinArray);
  MeineFunktion(lOperator,lMeinArray);
  
  lOperator:=GibMirEinenAnderenOperator;
  FuelleMeinArrayMitAnderenWerten(lMeinArray);
  MeineFunktion(lOperator,lMeinArray);
end;

Würde ich den Operator nicht in "MeineFunktion" verwenden, würde es ja so aussehen:

Delphi-Quellcode:

Procedure Irgendetwas;
var
  lOperator:TLogicalOperator;
  lMeinArray:TDoubleDynArray;
begin
  lOperator:=GibMirDenOperator;
  FuelleMeinArray(lMeinArray);
  case loperator of
    loAnd:MeineFunktionAnd(lMeinArray);
    loOr:MeineFunktionOr(lMeinArray);
  end;
  
  lOperator:=GibMirEinenAnderenOperator;
  FuelleMeinArrayMitAnderenWerten(lMeinArray);
  case loperator of
    loAnd:MeineFunktionAnd(lMeinArray);
    loOr:MeineFunktionOr(lMeinArray);
  end;
end;

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Das hatte ich ganz übersehen. Kannst du mir das mal genauer erklären, weshalb man ein Case nicht benutzen sollte.

[Stevie]

Zitat:

Zitat von bernau (Beitrag 1283977)

Zitat:

Zitat von Dejan Vu (Beitrag 1283919)

Dann verzichtest Du auf dein 'case'-Statement, was in einer sauberen Methode ohnehin nichts zu suchen hat (sagen die Puristen).

Das hatte ich ganz übersehen. Kannst du mir das mal genauer erklären, weshalb man ein Case nicht benutzen sollte.

Schau dir das Video an, was ich verlinkt habe, viel besser kann man das nicht erklären.

[bernau]

Ja. Kurz. 40Min. Andere Sprache (C++).....

Wenn man so etwas in 3-4 Sätzen zusammenfassen könnte, ist das bestimmt um den Überblick zu erhalten besser.

Die Details kann man dann ja im Video anschauen.

[Stevie]

Zitat:

Zitat von bernau (Beitrag 1283987)

Ja. Kurz. 40Min. Andere Sprache (C++).....

Wenn man so etwas in 3-4 Sätzen zusammenfassen könnte, ist das bestimmt um den Überblick zu erhalten besser.

Die Details kann man dann ja im Video anschauen.

Java, nich C++ 8-)

Du hast zwar den case in dem aufrufenden Code vermieden, aber nun wird deine Routine, der du die Operation übergibst zu ner Monsterfunktion, die mehrere Operationen kann. Warum nicht 2 verschiedene Funktionen?

Nun mag nicht übermorgen jemand mit ner neuen Logischen Operation, die er entdeckt hat, um die Ecke kommen, aber kennt bestimmt jeder case of und 1, 2, 3 sind behandelt und huch, da hat man ja noch Fall 4 vergessen, wird hinzugefügt und muss nun überall wo man mal nen case auf diesen enum oder was gemacht hat, nachgepflegt werden. Und eh man sich versieht, hat man ne zighundert Zeilen Methode, die opBrötchenbacken, opKaffeekochen und opStaubsaugen kann. Also 3 verschiedene Methoden.

Und da kommt das Zauberwort Polymorphie ins Spiel, da kann ich mir eine Basisklasse (oder auch ein Interface) bauen, was mir meine Operation (oder auch Strategie) abbildet.

Wie man da hin kommt, kann unterschiedlich sein. Ich persönlich find die Kombination von arrays und enums herrlich, da knallts nämlich direkt beim Kompilieren, wenn jemand mal einen neuen Wert hinzugefügt hat und nicht alle cases gefunden und angepasst hat (kennt man ja, case of ... else raise exception.Create('unbehandelter Fall!') end :wall:).


Ich blas das Beispiel aber nun auch gar nicht unnötigerweise mit OOP auf sondern bleib mal bei der prozeduralen Programmierung,
da lässt sich das Prinzip nämlich auch anwenden:

Delphi-Quellcode:

type
  TArrayOperation = procedure(const values: TDoubleDynArray);
  TLogicalOperator = (loAnd, loOr);

procedure AndDings(const values: TDoubleDynArray);
begin
  // ...
end;

procedure OrDings(const values: TDoubleDynArray);
begin
  // ...
end;

const
  ArrayOperations: array[TLogicalOperator] of TArrayOperation = (
    AndDings,
    OrDings
  );

Procedure Irgendetwas;
var
  MeineFunktion: TArrayOperation;
  lMeinArray: TDoubleDynArray;
begin
  MeineFunktion := GibMirDieOperation;
  FuelleMeinArray(lMeinArray);
  MeineFunktion(lMeinArray);

  MeineFunktion := GibMirEineAndereOperation;
  FuelleMeinArrayMitAnderenWerten(lMeinArray);
  MeineFunktion(lMeinArray);
end;

In der Irgendetwas Prozedur hast du nun überhaupt nix mehr mit dem enum am Hut und sagst einfach nur, ich brauche eine Operation, gib die mir, damit ich sie aufrufen kann. Und das komplette Mapping ist in diesem Fall hardcoded und kann vom Compiler geprüft werden (in Fällen wo das dynamisch ist, würde sich ein Dictionary anbieten, wo man seine strategien registriert).

Das Beispiel mit der Polymorphie und wie man dadurch auf cases in Klassen verzichten kann, kannst du dir ja dann in Ruhe anschauen (auch wenns Java is :twisted:).

[Dejan Vu]

Ich wollte mit Klassenfabriken kommen, aber so ist das schön leichtgewichtig.

Eine Class Factory wäre vielleicht ein wenig oversized für die kleine Geschichte, aber als Übung vielleicht nett
(Kann kein Delphi mehr, daher bitte kleine Fehler entschuldigen).

Delphi-Quellcode:

Type
  ILogicalArrayCompressor = interface
    function Execute (array : TSomeArray);
  end;

  TAndArrayCompressor = class (ILogicalArrayCompressor)
  public function Execute (array : TSomeArray);
  end;
    
  TOrArrayCompressor = class (ILogicalArrayCompressor)
  public function Execute (array : TSomeArray);
  end;

  TArrayCompressorFactory = class
    class function Create (logicalOperator : TLogicalOperator) : ILogicalArrayCompressor;
  end;

class function TArrayCompressorFactory.Create (logicalOperator : TLogicalOperator) : ILogicalArrayCompressor;
begin
  case logicalOperator of 
   laOr : result := TOrArrayCompressor.Create();
   laAnd : result := TAndArrayCompressor.Create();
// Add new operators here
   else raise ArgumentException.Create('Unknown logical Operator');
 end;
End;
---
Function TUserClass.Calculate (logicalOperator : TLogicalOperator; SomeArray : TSomeArray) : Integer;
Begin
  result := TArrayCompressorFactory.Create(logicalOperator).Execute(SomeArray);
End;

Hä? Eben meint der Typ doch, 'case' ist Müll, und dann klatscht er das doch rein? Ja. 'Case' ist sollte vermieden werden, außer in Klassenfabriken (da ist das legitim). Sagen andere Puristen. Wie schön, wenn sich Softwaretechniker so einig sind :lol:

Das Schöne an so einer Methode (oder der von Stevie) ist doch die: Der Anwender hat ein Array und eine Operation (egal welche) und will, das die Arrayelemente entsprechend verknüpft/verdichtet werden. Welche Operationen es gibt, ist im wurscht.

Wenn Du das so umsetzt, kannst Du die Anwenderklasse zu machen, d.h. Du musst sie nicht mehr anfassen, bloß weil eine neue logische Operation hinzugekommen ist. Das bedeutet aber auch, das Du keinen Bockmist mit der Klasse (aus Versehen!) machen kannst (weil Du sie noch nicht einmal neu kompilierst). Sie läuft, ist getestet und der Quellcode ist im Tresor. Du erweiterst trotzdem die Mächtigkeit der Klasse.

Natürlich musst Du den Code anfassen, wenn ein logischer Operator dazukommt. Aber die Änderungen sind viel simpler und bergen vor allen Dingen nicht die Gefahr, Code in der Nähe aus Versehen zu zerballern oder kaputt zu optimieren (ein beliebtes Hobby).

Also ich find das praktisch.

[DeddyH]

Wenn sich die Klassen/Interfaces in der Factory registrieren, kann diese das schön in z.B. einem Dictionary ablegen. Damit entfällt dann auch die Case-Abfrage, es wird einfach im Dictionary nach dem passenden Interface/der Klasse gesucht und bei Fund die entsprechende Instanz zurückgegeben. Dafür müsste es im Forum auch Beispiele geben, ich bin nur gerade zu faul zum Suchen.

[bernau]

@Stevie: Das sieht erst mal sehr interessant aus. Leuchtet mir ein, daß man bei einer Erweiterung des Aufzählungstyp der Compiler eine Fehlermeldung gibt und man nichts vergessen kann. Muss ich mal probieren.

Allerdings kann ich mir vorstellen, daß das Debuggen nicht so schön ist. Bei "GibMirDieOperation" bekomme ich normalerweise den Aufzählungstyp zurück und der wird mir im Debugger angezeigt. Bei der deiner Funktion bekomme ich ja nicht den Namen der Procedure angezeigt sondern den Pointer. Denke ich.

@Dejan Vu: Ist wirklich etwas oversized und auch in deinem Fall weis ich nicht, ob es wirklich angenehm zu debuggen ist. Und mit interfaces stehe ich sowiso auf dem Kriegsfuß. Aber egal. Ich schaue es mir mal an.

Danke

[Stevie]

Zitat:

Zitat von Dejan Vu (Beitrag 1284012)

Hä? Eben meint der Typ doch, 'case' ist Müll, und dann klatscht er das doch rein? Ja. 'Case' ist sollte vermieden werden, außer in Klassenfabriken (da ist das legitim). Sagen andere Puristen. Wie schön, wenn sich Softwaretechniker so einig sind :lol:

Pff, wer braucht schon case... haste ja den gleichen Müll dann, dass du erst zur Laufzeit irgendwo merkst dass dort nen Operator nicht behandelt wird. :)

Delphi-Quellcode:

  TBaseArrayCompressor = class(TInterfacedObject, ILogicalArrayCompressor)
  public
    procedure Execute(arr: TSomeArray); virtual; abstract;
  end;

  TBaseArrayCompressorClass = class of TBaseArrayCompressor;

  TAndArrayCompressor = class(TBaseArrayCompressor)
  public
    procedure Execute(arr: TSomeArray); override;
  end;

  TOrArrayCompressor = class(TBaseArrayCompressor)
  public
    procedure Execute(arr: TSomeArray); override;
  end;

  TArrayCompressorFactory = class
    class function Create(logicalOperator : TLogicalOperator) : ILogicalArrayCompressor;
  end;

class function TArrayCompressorFactory.Create (logicalOperator : TLogicalOperator) : ILogicalArrayCompressor;
const
  CompressorClasses: array[TLogicalOperator] of TBaseArrayCompressorClass = (
    TOrArrayCompressor, TAndArrayCompressor);
begin
  Result := CompressorClasses[logicalOperator].Create;
end;

Dasselbe würde auch mit einer class procedure funktionieren, sofern die array compressor Klassen stateless sind. Unnötig, die dann zu instanzieren.

Zitat:

Zitat von bernau (Beitrag 1284017)

@Stevie: Das sieht erst mal sehr interessant aus. Leuchtet mir ein, daß man bei einer Erweiterung des Aufzählungstyp der Compiler eine Fehlermeldung gibt und man nichts vergessen kann. Muss ich mal probieren.

Allerdings kann ich mir vorstellen, daß das Debuggen nicht so schön ist. Bei "GibMirDieOperation" bekomme ich normalerweise den Aufzählungstyp zurück und der wird mir im Debugger angezeigt. Bei der deiner Funktion bekomme ich ja nicht den Namen der Procedure angezeigt sondern den Pointer. Denke ich.

Debugger sind schlaue Kerlchen, der löst das richtig auf (ist ja nicht nur Pointer sondern nen Prozedurzeiger) und zeigt dir dann in den lokalen Variablen:

Delphi-Quellcode:

MeineFunktion  MyUnit.AndDings

.