OOP vs programmazione procedurale - pagina 14
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Puoi farmi un esempio di questi compiti di tipo singolo, che è meglio non fare senza OOP?
Senza OOP si può risolvere, ma con OOP è più veloce, te l'ho detto...
Per esempio, un pattern può contenere da 0 a 100 pattern di candele, da 0 a 30 indicatori diversi e da 1 a 5 segnali diversi in ognuno di essi... Così, abbiamo 1 classe, e possiamo impostare con il costruttore che la prima istanza conterrà 23 modelli di questo tipo e 2 indicatori con 1 segnale ciascuno... La seconda istanza conterrà altri 12 modelli e altri 8 indicatori... Poi impostiamo la condizione che entrambe le istanze devono dare un segnale di apertura a non più di 4 barre di distanza l'una dall'altra ...
Tutta questa roba si fa in 5 secondi se i segnali dei modelli e tutto il resto è descritto nella classe... E ci possono essere tutte le combinazioni di tutto questo che vuoi, e anche senza un cliente, basta ottimizzare tutto questo automaticamente nell'ottimizzatore e cercare le condizioni favorevoli per entrare... L'ottimizzatore può ampliare il numero di istanze e le proprietà di ciascuna di esse... bene, ecc.)
Questo non è l'argomento principale.
Non esiste un analogo del polimorfismo nella programmazione procedurale.
È strano che durante tutta la mia pratica, dato che ero un completo novizio della programmazione e lo sono ancora in parte, non ho mai trovato necessario usare il polimorfismo... Questo deve essere il mio destino.
(L'inferno sa perché...))
Senza OOP si può risolvere, ma con OOP è più veloce, te l'ho detto...
Per esempio, un pattern può contenere da 0 a 100 pattern di candele, da 0 a 30 indicatori diversi e da 1 a 5 segnali diversi in ognuno di essi... Così, abbiamo 1 classe, e possiamo impostare con il costruttore che la prima istanza conterrà 23 modelli di questo tipo e 2 indicatori con 1 segnale ciascuno... La seconda istanza conterrà altri 12 modelli e altri 8 indicatori... Poi impostiamo la condizione che entrambe le istanze devono dare un segnale di apertura a non più di 4 barre di distanza l'una dall'altra ...
Tutta questa roba si fa in 5 secondi se i segnali dei modelli e tutto il resto è descritto nella classe... E ci possono essere tutte le combinazioni di tutto questo che vuoi, e anche senza un cliente, basta ottimizzare tutto questo automaticamente nell'ottimizzatore e cercare le condizioni favorevoli per entrare... L'ottimizzatore può ampliare il numero di istanze e le proprietà di ciascuna di esse... ecc.)
Tutta questa debacle del GOP è su scala universale.
Dopo tutto, bisogna avere tanto talento per spingere una cosa del genere in tutto il mondo.
E niente ferma gli apologeti.
Se si prendono gli apologeti locali. Proprio sotto il loro naso c'è il manuale del linguaggio MQL. Guardiamo le sezioni. Solo tre sezioni sono dedicate ai dati e tutto il resto descrive le AZIONI: programma, operazioni di array, conversioni di dati.....
Può essere che si tratti di un linguaggio μl che non è conforme alle "idee d'avanguardia"?
Prendiamo un sistema software molto più grande: R.
Contiene più di 10.000 pacchetti, ognuno dei quali contiene funzioni - queste sono azioni, non oggetti.
Per come la vedo io, tutti questi apologeti dell'OOP di origine locale e mondiale non capiscono nulla di programmazione, cioè: il valore (semantica) di qualsiasi dato è una funzione, un'azione che elabora questo dato. Hanno scritto int. Il significato di questi caratteri è determinato da un insieme di comandi del processore, che sa come eseguire l'AZIONE con questa variabile.
Poi, passiamo alle classi.
Se prendiamo R, per il quale le classi fanno parte del linguaggio.
Una funzione immette un oggetto di qualche classe - l'uscita è un oggetto di solito un'altra classe. Il significato dei campi di input-output è determinato unicamente dalla funzione che gestisce il tutto. E se la funzione non accetta una certa classe, questa classe non è utile a questa funzione. Ecco perché la documentazione di ogni pacchetto è esattamente la stessa di quella di µl: azioni e funzioni sono elencate. E i collegamenti tra funzioni in un pacchetto, o con funzioni in un altro pacchetto, sono determinati dal nome della classe con cui la particolare funzione lavora.
Di nuovo. In R, gli oggetti possono avere una complessità arbitraria e possono effettivamente essere molto complessi. Ma il valore di ogni campo di un oggetto di una certa classe è interamente determinato dalla funzione che genera quell'oggetto.
Questo è particolarmente ovvio per coloro che hanno scritto compilatori (e io l'ho fatto). Viene scritta una sequenza di codice. Cosa fa questo codice? Qual è il significato di questo codice? Il significato del testo nel linguaggio sorgente di qualsiasi linguaggio di programmazione sarà determinato dal codice eseguibile che il compilatore crea, che alla fine sarà percepito dal processore. Il compilatore di una lingua troverà il significato delle righe scritte, ma un altro no, cioè le righe scritte non hanno significato per quest'altra lingua.
Quindi: il significato di un oggetto è sempre una funzione, un'azione che è in grado di prendere dei dati in entrata come guida per l'azione, e generare in uscita una certa lista di campi, il cui valore è determinato unicamente da questa funzione.
Konov ha cercato di spiegare sopra che dobbiamo passare dalle AZIONI. È necessario trattare le azioni, e gli oggetti che collegano queste azioni devono essere trattati più tardi, quando le azioni sono definite. Ma la chiarezza e l'efficienza del codice deriva puramente da quanto bene siamo riusciti a organizzare l'intera gerarchia delle AZIONI e la loro interazione.
I sostenitori dell'OOP dicono: creiamo oggetti. Ma qual è il significato dei campi oggetto se non definiamo azioni su questi campi?
Come viene implementato il modello che contiene i modelli? È una funzione o un array o qualcos'altro? Come sono scritti i modelli stessi?
sì, di solito sono descritti, non è questo il punto...
Un altro esempio... una classe è come una biblioteca con libri, e una copia è un carrello... Su un carrello si possono mettere libri a scelta della biblioteca... ... e cercare qualcosa di più redditizio...) Biblioteca e 1 carrello possono essere fatti senza OOP, e quando stiamo parlando di un gran numero di carrelli, è meglio farlo con OOP...
Questo è l'unico argomento a favore dell'OOP nello sviluppo che ora accetto.
Non dovresti accettarlo.
L'ultima squadra in cui ho lavorato aveva circa 300 persone. Il carico di lavoro totale per l'intero progetto del programma è di circa 1500 anni-uomo. Organizzare una tale squadra per lavorare insieme non aiuterà nessun OOP. Per questo, c'erano altri approcci, che prevedevano la suddivisione dell'intero problema in fasi e l'attenta regolazione di tutto e di tutti in ogni fase. C'erano dei GOST che lo descrivevano. Nella programmazione, era l'USSD (Unified System of Program Documentation). In termini di intensità del lavoro, la codifica stessa ha richiesto circa il 20% del lavoro.
Non ascoltate i sostenitori dell'OOP. Siete sulla strada giusta. Anche il fatto di non unire due variabili in un'unica struttura - non si vede il profitto di una tale fusione
Un altro esempio più semplice, che è sulla superficie... Generatore di EA in MetaEditor... Chiunque, anche se non sa programmare, può mettere insieme un EA contenente un numero enorme di indicatori e condizioni in 10 secondi )))) E tutto questo è OOP )))
Non parliamo del generatore, perché ho deciso di non bestemmiare per 2 mesi )))
Compagni sviluppatori di MQ, ho molto rispetto per voi. Dico sul serio.
E capisco le ragioni per creare questi costruttori. Capisco anche perché tutti questi costruttori scoreggiano nel vuoto.
Sì, può essere visto come una sorta di esempio per studiare MQL5, ma in nessun modo come un punto di partenza per un vero robot di trading.
Non dovresti accettarlo.
L'ultima squadra in cui ho lavorato aveva circa 300 persone. Il carico di lavoro totale per l'intero progetto del programma è di circa 1500 anni-uomo. Organizzare una tale squadra per lavorare insieme non aiuterà nessun AOP. Per questo, c'erano altri approcci, che prevedevano la suddivisione dell'intero problema in fasi e l'attenta regolazione di tutto e di tutti in ogni fase. C'erano dei GOST che lo descrivevano. Nella programmazione, era l'USSD (Unified System of Program Documentation). In termini di input di lavoro, la codifica stessa ha preso circa il 20% dell'input di lavoro.
Non ascoltate i sostenitori dell'OOP. Siete sulla strada giusta. Anche il fatto di non unire due variabili in un'unica struttura non rende molto
San-Sanych, recentemente sono stato contattato da un cosiddetto progager che è riuscito persino a vendere qualcosa nel mercato.
Mi ha detto che ho cercato di incollare alcuni programmi e ho avuto un errore di compilazione, per cui mi ha mandato la sua colla. Ha promesso di pagarmi.
Ho dato un'occhiata e sono malato, 59 errori di compilazione.
Un sacco di variabili globali come n, c, m.
Tutti in conflitto tra loro.
E il ragazzo è sicuro che ha solo bisogno di qualche ritocco e può lanciarlo nel mercato.
...
Secondo la mia comprensione, tutti questi apologeti di OOP di origine locale e mondiale non capiscono nulla di programmazione, cioè: il valore (semantica) di qualsiasi dato è una funzione, un'azione, che elabora questo dato. Hanno scritto int. Il significato di questi caratteri è determinato da un insieme di comandi del processore, che sa come eseguire l'AZIONE su questa variabile.
...
in memoria
Non dovresti accettarlo.
L'ultima squadra in cui ho lavorato aveva circa 300 persone. Il carico di lavoro totale per l'intero progetto del programma è di circa 1500 anni-uomo. Organizzare una tale squadra per lavorare insieme non aiuterà nessun OOP. Per questo, c'erano altri approcci, che prevedevano la suddivisione dell'intero problema in fasi e l'attenta regolazione di tutto e di tutti in ogni fase. C'erano dei GOST che lo descrivevano. Nella programmazione, era l'USSD (Unified System of Program Documentation). In termini di intensità del lavoro, la codifica stessa ha richiesto circa il 20% del lavoro.
Non ascoltate i sostenitori dell'OOP. Siete sulla strada giusta. Anche il fatto di non unire due variabili in una struttura non mostra alcun profitto
Tali programmi sono ora scritti da una persona in tre giorni.