Fare un progetto in crowdsourcing su Canvas - pagina 24
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
Se due programmatori con la stessa esperienza e intelligenza sono in competizione, creandograndi progetti simili. Ma il primo usa solo funzioni, mentre il secondo usa funzioni e classi. Sicuramente la vittoria sarà per il secondo. Ma, ripeto, se si tratta di un progetto voluminoso, quest'ultimo lo renderà più veloce perché ci saranno meno bug e più ordine. E il prodotto del secondo sarà più leggibile, mantenibile e più facilmente aggiornabile e integrabile. Questo non è nemmeno il mio imho, è solo una dichiarazione di fatto. È più facile scavare una buca con una pala che con una cazzuola. Se tu implementassi il tuo meccanismo non solo sulle funzioni ma anche sulle classi, diventerebbe più efficiente. Questo è il mio imho.
Cominciamo con la questione della necessità delle classi nell'implementazione di grandi meccanismi. Una classe è una shell per un insieme di alcune funzioni, e un "grande meccanismo" è un blocco di codice che implementa un insieme di compiti. Nella mia implementazione, un "grande meccanismo" è quasi sempre una funzione molto grande e un insieme di piccole funzioni che la servono. Il cosiddetto "motore". Se lo riempite di funzioni di servizio in una classe, non cambierà nulla, e se lo riempite in classi diverse, l'accesso tra loro diventerà più complicato e l'efficienza del meccanismo si abbasserà.
Se la dimensione del meccanismo aumenta, dovete ottimizzare il suo codice o dividere la funzionalità in file. Non è abbastanza? Inoltre, l'ottimizzazione periodica del codice in un blocco porta a miracoli di efficienza. È costantemente compresso e richiede sempre più funzioni per essere implementato. Cioè, il numero di funzioni diminuisce al contrario. Sono generalizzati in un blocco, il cui codice è costantemente migliorato. Questa è una strada diretta verso l'efficienza .
Inoltre, se rendiamo globali le variabili importanti, saranno visibili ovunque nel meccanismo, e sarà facile lavorare con loro, e se definiamo scope per loro, si creerà un compito superfluo dal punto di vista dell'efficienza del meccanismo. Di nuovo, complicazione dell'accesso. Creare oggetti di classe, e così via... La tendenza a frammentare il meccanismo in un gran numero di funzioni rovina non solo l'efficienza, ma anche l'universalità dei blocchi di codice. Si scopre che ogni compito concreto ha bisogno di una funzione separata, e l'universalità dei blocchi di codice semplicemente non viene migliorata. Cresce anche il numero di chiamate e di parametri passati. Questo non contribuisce all'efficienza del meccanismo, ma questa tendenza è in realtà promossa da OOP.
OOP è più efficiente quando un progetto è gestito da un team di programmatori. In questo caso non potete farne a meno. Anche se, se ci pensi, puoi trovare un modo per farne a meno anche qui...
Ma naturalmente, queste sono tutte parole. In pratica, proverei rapidamente ciò di cui sto parlando.
Nikolai Semko:
E, Peter, ho dato una rapida occhiata al tuo codice e mi sono reso conto che stai usando canvas al massimo (anche se non la classe CCanvas, ma chi se ne frega). Allora perché tutte queste domande sulla tela e perché sto cercando di spiegare tutte queste cose qui? :)).
)))), sono un po' sorpreso dalle tue spiegazioni sui principi di disegno dei kanvas. Ti ho già detto e mostrato che tutto nei miei kanvas è disegnato)). (Beh, quasi tutto. :))
Iniziato questo argomento perché non riesco a capire perché finora nessuno non ha disegnato lo stesso pulsante come il mio. Dopo tutto, e nelle tue parole è facile.
))), sono stato anche un po' sorpreso dalla tua spiegazione dei principi del disegno su tela, perché ti ho già detto e mostrato che tutto è disegnato)). (Beh, quasi tutto. :))
Iniziato questo argomento perché non riesco a capire perché finora nessuno ha disegnato lo stesso pulsante come il mio. Dopo tutto, e nelle tue parole è facile.
Se non avete visto, non significa che nessuno tranne voi non può farlo. È solo così insignificante che non hai nemmeno bisogno di postarlo - troppo insignificante un evento - creare solo un pulsante - per postare il suo codice, non perché sei il migliore ;)
Siete tutti in competizione, e giustamente, Anatoly - con i mulini a vento.
Se non l'avete visto, questo non vuol dire che nessuno tranne voi sia in grado di farlo. È solo così insignificante che non c'è bisogno di postarlo - un evento troppo insignificante - solo la creazione di un pulsante - per postare il suo codice, non perché sei il migliore ;)
Siete tutti in competizione, e giustamente, con i mulini a vento.
Calmati, Artem. Ho già capito che non ti piaccio. A quanto pare, anche molti altri su questa risorsa. Forse è giustificato, ma è troppo cambiare la propria personalità di punto in bianco quando si parla di questioni tecniche.
Sono tranquillo, cosa ti fa pensare il contrario?
Piace/disprezza una persona - non è un forum tecnico per discutere. Tu sei neutrale per me - niente di più. Allo stesso modo, come per il resto di noi, mi sembra.
Ma perché tu non sia citato nello stile di "ah-ah-ah..., è quel Don Chisciotte..., mi ricordo, mi ricordo...", devi fare almeno qualcosa di utile.
Lei può fare o non fare quello che vuole - è un suo diritto e nessuno lo mette in discussione. Nessuno ha bisogno della tua parola qui - dovresti darla a te stesso in primo luogo ;)
L'atmosfera è molto amichevole - la gente ti dice quanto sia bello usare OOP in alcune situazioni, un uomo sta crocifiggendo davanti a te, cercando di aiutarti in qualcosa, codificando per te per mostrarti, per renderlo più comprensibile. Ma si scopre - dalle tue stesse parole - che non ne hai nemmeno bisogno - semplicemente non sai con chi altro competere, e cerchi di sfidare le persone "debolmente".
E quello che mi sembra anche - non sei perché hai deciso di non scrivere e non studiare OOP, che hai pesato tutto e capito che tu, usando la programmazione procedurale, scrivi codice molto migliore e ottimizzato (come l'hai presentato a tutti qui), ma semplicemente perché non ci capisci niente, e hai inventato una scusa, che hai annunciato a tutti, sostenendola con parole e sfida "credi solo a chi mi batte".
Ricordate la battuta su "Elusive Joe"?
...
Ricordate la battuta su "Elusive Joe"?
Assolutamente d'accordo.
L'inafferrabile paroliere/filosofo... :-) la stessa merda di "Joe", solo nell'"altra mano"... :-)
Cominciamo con la questione della necessità delle classi nell'implementazione di grandi meccanismi. Una classe è un guscio per un insieme di funzioni, e un "grande meccanismo" è un blocco di codice che implementa un insieme di compiti. Nella mia implementazione, una "Grande Macchina" è quasi sempre una funzione molto grande e un insieme di piccole funzioni che la servono. Il cosiddetto "motore". Se lo riempite di funzioni di servizio in una classe, non cambierà nulla, e se lo riempite in classi diverse, l'accesso tra loro diventerà più complicato e l'efficienza del meccanismo si abbasserà.
Se la dimensione del meccanismo aumenta, dovete ottimizzare il suo codice o dividere la funzionalità in file. Non è abbastanza? Inoltre, l'ottimizzazione periodica del codice in un blocco porta a miracoli di efficienza. È costantemente compresso e richiede sempre più funzioni per essere implementato. Cioè, il numero di funzioni diminuisce al contrario. Sono generalizzati in un blocco, il cui codice è costantemente migliorato. Questa è una strada diretta verso l'efficienza .
Inoltre, se rendiamo globali le variabili importanti, saranno visibili ovunque nel meccanismo, e sarà facile lavorare con loro, e se definiamo scope per loro, si creerà un compito superfluo dal punto di vista dell'efficienza del meccanismo. Di nuovo, complicazione dell'accesso. Creare oggetti di classe, e così via... La tendenza a frammentare il meccanismo in un gran numero di funzioni rovina non solo l'efficienza, ma anche l'universalità dei blocchi di codice. Si scopre che ogni compito concreto ha bisogno di una funzione separata, e l'universalità dei blocchi di codice semplicemente non viene migliorata. Cresce anche il numero di chiamate e di parametri passati. Questo non contribuisce all'efficienza del meccanismo, ma questa tendenza è in realtà promossa da OOP.
OOP è più efficiente quando un progetto è gestito da un team di programmatori. In questo caso non potete farne a meno. Anche se, se ci pensi, puoi trovare un modo per evitarlo anche qui...
Ma naturalmente, queste sono tutte parole. In pratica, proverei rapidamente ciò di cui sto parlando.
Peter, è solo che prima programmavo solo con funzioni e ragionavo quasi nello stesso modo in cui lo fai tu ora, e poi quasi per forza (perché la forza dell'abitudine è incredibile) ho iniziato a programmare con le classi. Ora posso confrontare i due stati, mentre tu, che non hai provato ad applicare le classi, non puoi. Senza offesa. Mi ricorda un'altra situazione. Sono vegetariano da molti anni ormai. E con invidiabile regolarità ci sono persone che non sono mai state vegetariane e cercano di rinfacciarmi le proteine, gli aminoacidi essenziali ecc. Dico loro: non siamo in condizioni uguali, io ero un mangiatore di carne e ora sono vegetariano, quindi posso confrontare queste due condizioni in termini di pratica. Tu non lo sei e la tua conoscenza è solo teorica che non ha niente a che vedere con la pratica.
Non perdete il vostro tempo - padroneggiate l'OOP.
Sei completamente bandito da questo forum, amico mio. :)) Incluso me. :( Non disperare - ciò che non ci uccide ci rende più forti. Io credo in te!!! :))
Non sprecate il vostro tempo - padroneggiate l'OOP.
Sei completamente bandito da questo forum, amico mio. :)) Anch'io. :( Non disperare - ciò che non ci uccide ci rende più forti. Io credo in te!!! :))
Cominciamo con la questione della necessità delle classi nell'implementazione di grandi meccanismi. Una classe è un guscio per un insieme di funzioni, e un "grande meccanismo" è un blocco di codice che implementa un insieme di compiti. Nella mia implementazione, una "Grande Macchina" è quasi sempre una funzione molto grande e un insieme di piccole funzioni che la servono. Il cosiddetto "motore". Se lo riempite di funzioni di servizio in una classe, non cambierà nulla, e se lo riempite in classi diverse, l'accesso tra loro diventerà più complicato e l'efficienza del meccanismo si abbasserà.
Se la dimensione del meccanismo cresce, è necessario ottimizzare il suo codice o dividere la funzionalità in file. Non è abbastanza? Inoltre, l'ottimizzazione periodica del codice in un blocco porta a miracoli di efficienza. È costantemente compresso e richiede sempre più funzioni per essere implementato. Cioè il numero di funzioni diminuisce al contrario. Sono generalizzati in un blocco, il cui codice è costantemente migliorato. Questa è una strada diretta verso l'efficienza .
Inoltre, se rendiamo globali le variabili importanti, saranno visibili ovunque nel meccanismo, e sarà facile lavorare con loro, e se definiamo scope per loro, si creerà un compito superfluo dal punto di vista dell'efficienza del meccanismo. Di nuovo, complicazione dell'accesso. Creare oggetti di classe, e così via... La tendenza a frammentare il meccanismo in un gran numero di funzioni rovina non solo l'efficienza, ma anche l'universalità dei blocchi di codice. Si scopre che ogni compito concreto ha bisogno di una funzione separata, e l'universalità dei blocchi di codice semplicemente non viene migliorata. Cresce anche il numero di chiamate e di parametri passati. Questo non contribuisce all'efficienza del meccanismo, ma questa tendenza è in realtà promossa da OOP.
OOP è più efficiente quando un progetto è gestito da un team di programmatori. In questo caso non potete farne a meno. Anche se, se ci pensi, puoi trovare un modo per evitarlo anche qui...
Ma naturalmente, queste sono tutte parole. In pratica, proverei rapidamente ciò di cui sto parlando.
E c'è qualcosa in questo. Alan Kay, il creatore di OOP, aveva in realtà un'idea molto diversa da quella che si intende oggi per OOP. È ancora più simile alla vostra visione. Ho l'idea di creare un progetto con un nucleo e servizi che lo chiamano per alcune funzionalità. E la comunicazione tra gli elementi avverrà solo attraverso eventi-messaggi. Non appena si invia un event-request con i dati, si riceve l'event-reply con il risultato. Non c'è eredità, polimorfismo o inclusione.
A proposito, con questo approccio il multithreading è più facile da organizzare perché tutti gli elementi per definizione lavorano indipendentemente l'uno dall'altro.
C'è qualcosa in esso. Alan Kay, il creatore di OOP, aveva un'idea diversa da quella che si intende oggi per OOP. È ancora più simile alla vostra visione. Ho l'idea di creare un progetto con un nucleo e servizi che lo chiamano per alcune funzionalità. E la comunicazione tra gli elementi avverrà solo attraverso eventi-messaggi. Non appena si invia un event-request con i dati, si riceve l'event-reply con il risultato. Non c'è eredità, polimorfismo o inclusione.
A proposito, con questo approccio, il multithreading è più facile da organizzare, perché tutti gli elementi lavorano per definizione indipendentemente l'uno dall'altro.