Questions sur la POO dans MQL5 - page 23

Nouveau commentaire
 
Vladimir Simakov:
Je vous montrerai plus tard ce soir. Maintenant, depuis mon téléphone.

OK

Ce n'est pas un problème de supprimer l'héritage de l'interface, vous pouvez hériter d'une classe de base, mais à mon avis il y aura une confusion dans le code - il sera plus difficile de comprendre quelle méthode sera appelée, et avec cette structure de code - "OOP Patterns - Behavior Patterns - Strategy".

Je suis toujours et garanti d'avoir un constructeur dans chaque stratégie, il semble que ces constructeurs ne sont pas encore nécessaires.... mais je laisse cette possibilité, elle n'est pas superflue.

ZS : la classe de base elle-même pour toutes les stratégies est assez compacte aussi, à ce propos :

class CStrategy: public IStrategy
{
protected:
   SSettingsForOrder  m_setting;
   COrder *m_order;
   void RunStrategy();
   double CalcLot();
   double GetPrice(); 
};

Jusqu'à présent, j'aime que la structure du code soit lisible et logique, et la chose la plus importante "dans tous ces gestes" est de faire une sorte de prototype, qui permettra d'ajouter rapidement des stratégies lui-même et de les tester.

J'avais déjà tout écrit en principe, mais je n'aime pas le code - j'ai écrit des fonctions de service (pour ouvrir un ordre, calculer les lots, etc.) dans un style procédural et ensuite j'ai écrit de petites classes avec la logique et les appels de ces fonctions de service et j'ai décidé de le rendre aussi bon que possible))).

 
Igor Makanu:

OK

Ce n'est pas un problème de supprimer l'héritage de l'interface, vous pouvez hériter d'une classe de base, mais à mon avis il y aura une confusion dans le code - il sera plus difficile de comprendre quelle méthode sera appelée, et avec cette structure de code - "OOP pattern - Patterns of behavior - Strategy".

Je suis toujours et garanti d'avoir un constructeur dans chaque stratégie, il semble que ces constructeurs ne sont pas encore nécessaires.... mais je laisse cette possibilité, elle n'est pas superflue.

ZS : la classe de base elle-même pour toutes les stratégies est assez compacte aussi, à ce propos :

Jusqu'à présent, j'aime que la structure du code soit lisible et logique, et la chose la plus importante "dans tous ces gestes" est de faire une sorte de prototype, qui permettra d'ajouter rapidement des stratégies lui-même et de les tester.

J'avais déjà tout écrit en principe, mais je n'aime pas le code - j'ai écrit des fonctions de service (pour ouvrir un ordre, calculer les lots, etc.) dans un style procédural et ensuite j'ai écrit de petites classes avec la logique et les appels de ces fonctions de service et j'ai décidé de le rendre aussi bon que possible))).

//+------------------------------------------------------------------+
class CStrategy
{
protected:
   int x;
public:
   CStrategy(int _x):x(_x){}
   virtual void Algorithm()=0;};
//+------------------------------------------------------------------+
class CStrategy_01:public CStrategy
{
public:
   CStrategy_01():CStrategy(1) {Print(__FUNCTION__);}
   void Algorithm()                 {Print(__FUNCTION__,", x = ",x);       } };
//+------------------------------------------------------------------+
class CStrategy_02:public CStrategy
{
public:
   CStrategy_02():CStrategy(2) {Print(__FUNCTION__);}
   void Algorithm()                 {Print(__FUNCTION__,", x = ",x);       } };
//+------------------------------------------------------------------+
class Context
{
private:
   CStrategy         *s;
public:
   Context(CStrategy* _strategy):s(_strategy) { Print(__FUNCTION__);}
   ~Context()                       { delete s;                            }
   void              GetStrategy()  { s.Algorithm();                       } };
//+------------------------------------------------------------------+
Context c1(new CStrategy_01);
Context c2(new CStrategy_02);
//+------------------------------------------------------------------+
void OnStart()
{  c1.GetStrategy();
   c2.GetStrategy(); }

Ça me semble mieux.

 
Vladimir Simakov:

C'est mieux comme ça pour moi.

essentiellement la même chose, mais pas dans les règles ! ))))

ZS : J'ai quand même vissé l'interface, laissez-la, c'est purement pour le spectacle !

 
Igor Makanu:

essentiellement la même chose, mais pas dans les règles ! ))))

ZS : De toute façon, j'ai mis l'interface en place, c'est purement pour le spectacle !

Juste dans le style des pros.)))
 
Vladimir Simakov:
Juste dans le style des plus.)))

peu de gens utilisent C#, ou plutôt tous les programmeurs d'applications sont passés à C#, et seuls les grands développeurs de logiciels utilisent C#

tous les exemples en C# passent par des interfaces, il est donc clair qu'elles sont inutiles .... Je ne veux pas me lancer dans une diatribe, mais on peut tout écrire sans interface, le concept, le style... mais le concept, le style et autres brouillards cérébraux me disent que c'est ainsi que Microsoft avait l'habitude d'écrire des exemples en C# - il suffit de s'asseoir et de les écrire de cette façon aussi !

)))

 
Igor Makanu:

peu de gens utilisent C#, ou plutôt tous les programmeurs d'applications sont passés à C#, et seuls les grands développeurs de logiciels utilisent C#

tous les exemples en C# passent par des interfaces, il est donc clair qu'elles sont inutiles .... Je ne veux pas me lancer dans une diatribe, mais on peut tout écrire sans interface, le concept, le style... mais le concept, le style et autres brouillards cérébraux me disent que c'est ainsi que Microsoft avait l'habitude d'écrire des exemples en C# - il suffit de s'asseoir et de l'écrire de cette façon aussi !

)))

Déplacé parce qu'il est peu pratique d'écrire sur les avantages de .NET, et que Sharp a été conçu à l'origine comme un langage pour dotnet. C'est mon opinion personnelle, au début j'ai écrit des plus sur .NET, ça semblait maladroit.

Bien que... ils ont ajouté beaucoup de choses aux nouveaux pros, peut-être que c'est plus amusant.

 
Alexey Volchanskiy:

Nous avons changé de langage parce que pluses n'est pas pratique à écrire sur .NET, et que Sharp a été développé à l'origine comme un langage pour dotnet. C'est mon avis subjectif, une fois que j'ai écrit en plus sous .NET, je suis resté avec une impression de maladresse.

Bien que... ils ont ajouté beaucoup de choses aux nouveaux pros, peut-être que c'est plus amusant.

Je suis en train d'écrire un formulaire Windows pour une tâche, j'ai touché à c++/cli et j'ai décidé de ne pas l'utiliser et d'imprimer c#.
 
Vladimir Simakov:
Je suis en train d'écrire un formulaire Windows pour une tâche, j'ai touché à c++/cli et j'ai décidé de l'oublier et d'imprimer c#.

Oui, c'est un ordre de grandeur plus facile sur le sharpe. Et la vitesse est presque la même, c'est sans compter que les pros gagnent d'un facteur et demi.

 
Vladimir Simakov:
Je suis en train d'écrire un formulaire Windows pour une tâche, j'ai touché à c++/cli et j'ai décidé de ne pas l'utiliser et d'imprimer c#.

J'ai essayé de toucher les clientes au début de l'année ... J'ai été satisfait pendant 2 jours, la logique inhumaine de qui a fait cette cli - la syntaxe est compliquée, tout n'est pas pratique, il ya très peu d'informations avec des exemples, imho ou pur C ++ ou C # - google tout ce que vous voulez, la syntaxe est claire - en conséquence, vous prenez et écrire

 
Igor Makanu:

J'ai essayé de toucher les clientes au début de l'année ... La syntaxe est compliquée, tout n'est pas pratique, il y a très peu d'informations avec des exemples, imho - soit C++ pur ou C# - tous les désirs sont googlés, la syntaxe est claire - finalement vous obtenez et vous écrivez

Sharp est né aux alentours de l'an 2000 et n'en était qu'à ses balbutiements, mais les plus ont régné, si bien qu'ils ont fait le pont entre C++ et Dotnet pour le populariser. Au fait, Sharp a été créé par des développeurs Delphi et C++Builder, je me suis demandé à l'époque combien de concepts communs il y avait. Prenez les mêmes propriétés, les mêmes événements.

1...161718192021222324252627282930...96
Nouveau commentaire