Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Derzeit möchte ich VS-Formular zu .dll zu MT5 auf eine einfache Weise )))) anhängen. - Ich möchte die Schaltflächenklick-Handler in einer Klasse verpacken und sie durch Traversieren eines Zeiger-Arrays von Handler-Funktionen aufrufen, und ich möchte im Haupt-EA-Code die Möglichkeit haben, die gleichen Funktionsnamen wie in VS zu schreiben, d. h. button2_Click() ....button2_Click()
SZY: Dies ist einEOP-Problem))))
Nichts für ungut, aber es erinnert mich sehr daran:
- Automatische Strukturen innerhalb einer dynamischen OOP zu schaffen ist Unsinn
Stapelobjekte: myclass obj; ist also Unsinn? Dann bin ich ein Handicapper :)
Objekte stapeln: myclass obj; ist also Unsinn? Also, ich bin ein Handwerker :)
Es gibt alle Arten von Aufgaben. Man kann sich lange in Rhetorik üben, wenn man keine konkreten Aufgaben beschreibt, kann man sich alles Mögliche einfallen lassen...
Ja, "stapelbare" (automatische?) Objekte sind grundsätzlich unsinnig. Meiner bescheidenen Meinung nach, die keineswegs die Wahrheit ist und schon gar nicht in letzter Instanz...Sie wollen ein Objekt, das die Hauptfunktion von OOP - die Eigenschaft der Polymorphie- nicht erfüllt? Sie werden einer solchen Variablen kein Objekt mit unterschiedlichen Eigenschaften je nach Inhalt zuweisen. Sie können dieser "Variablen" in der Liste überhaupt kein anderes Objekt zuordnen. Wozu braucht man überhaupt Objekte? Ist es nicht besser, stattdessen Strukturen zu verwenden? Vielleicht, weil µl-Strukturen keine Referenzen auf sich selbst zurückgeben können... Und mit ihnen beginnt eine dunkle Geschichte mit ständiger Schöpfung, Zerstörung, Selbstkopie usw.
Wie man ohne Polymorphismus leben kann ... Und wenn ich sage, dass wir in >90% der Fälle ohne Polymorphismus auskommen können? Nehmen wir das "SOLID-Abhängigkeitsinversionsprinzip": Wenn wir anständige Progger sind, sollten wir überall Abstraktionen und virtuelle Methoden schaffen (was natürlich einen hohen Overhead mit sich bringt). C#-Kenner würden etwas wie dieses https://pro-prof.com/forums/topic/dependency-inversion-principle schreiben . Oder wir könnten Vorlagen nehmen und etwas schreiben wie:
public:
void activate();
void deactivate();
};
template <typename T>
class Button {
Button(T& switchable)
: _switchable(&switchable) {
}
void toggle() {
if (_buttonIsInOnPosition) {
_switchable->deactivate();
_buttonIsInOnPosition = false;
} else {
_switchable->activate();
_buttonIsInOnPosition = true;
}
}
private:
bool _buttonIsInOnPosition{false};
T* _switchable;
}
int main() {
Lamp l;
Button<Lamp> b(l)
b.toggle();
}
Button ist auch detailunabhängig, ohne all den Polymorphismus und die Schnittstellen. Polymorphismus hat seine eigene Nische, aber die ist viel enger, als man sagt.
ZS: Nun, niemand verbietet es:
ZS: Nun, niemand verbietet es:
Niemand verbietet alle Arten von Krücken und Schematismus, aber warum? Zum Beispiel: Es wird lustig sein, wenn sich dein Auto-Objekt plötzlich selbst zerstört, wenn du es am wenigsten erwartest, nicht wahr?
Niemand verbietet das Erfinden von Krücken und Schematismus, aber warum? Zum Beispiel: Es wird lustig sein, wenn sich Ihr Auto-Objekt plötzlich selbst zerstört, wenn Sie es am wenigsten erwarten, nicht wahr?
Denn ein Stack-Objekt ist viel schneller als ein Objekt in einem Heap(Speicherzuweisung). Selbstzerstörung? - Das ist etwas Neues :). Aber manchmal ist das natürlich notwendig - die Anzahl der Objekte ist z.B. erst zur Laufzeit bekannt.
ZS: Sie mögen sich anders wohler fühlen, das ist eine persönliche Angelegenheit.
Der Sinn von OOP ist nicht, die von Ihnen gewählte Methode des Tastendrucks zu verwenden, die Sie genauso gut durch Templates oder Funktionszeiger implementieren können, sondern einfach auf jedes Objekt des Systems Methoden anzuwenden, wie z.B. eine Liste, die es erlauben, sich selbst in Listenstrukturen zu organisieren und beliebige Selektionen zum richtigen Zeitpunkt zu erstellen, ohne Krücken wie CArrayObj, etc. und die damit verbundene Mühe, Methoden wie Select, Query, Compare, Sort, etc. zu überladen. (und sogar Klonen/Kopieren, wenn jedes Objekt ohne Ihre Mitwirkung entscheiden kann, ob es in eine Liste/Array kopiert werden soll oder nicht, und wenn es kopiert werden soll, wie).
Ich schrieb - Polymorphismus hat seine eigene Nische, ich bin nicht streiten. Aber die Praxis zeigt (zumindest bei mir persönlich), dass das nicht so wichtig ist. Es ist viel wahrscheinlicher, dass ich Probleme mit Vorlagen löse.