Il mio approccio. Il nucleo è il motore. - pagina 137
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
Peter, hai davvero frainteso qualcosa sull'applicazione dell'OOP.
Nikolai, stai costruendo HIERARCHY o creando meccanismi di disegno?
Se costruisci l'HIERARCHY (non ti interessa il disegno), allora è chiaro perché hai bisogno di OOP ovunque.
Se state creando un meccanismo di disegno che funziona sulla base di UNA classe, allora non avete bisogno di Class stessa.
Classe, - dalla parola Classificazione. La classificazione è una divisione per attributi. La classe è un derivato di Classificazione. Se c'è una Classe, allora non c'è Classificazione.
Quindi la classe, in questo caso, è una stronzata astratta. Non ha senso.
...
Si ha l'impressione che l'OOP stesso vada avanti rispetto al meccanismo che dovrebbe servire. Cioè, il meccanismo deve tendere all'integrità, quindi al minor numero dei suoi blocchi. Ma OOP costringe questi blocchi a moltiplicarsi per qualsiasi motivo. Il risultato è che la struttura dei meccanismi è a pezzi e non funzionano bene. E si sviluppano anche peggio.
...
Beh, forse dovresti studiare almeno un po' l'OOP invece di fantasticarci sopra? Tu non fantastichi nemmeno, stai delirando.
Nikolai, ti è mai venuto in mente che il tuo amore per l'OOP non è giustificato da quasi nulla se non da ragioni astratte?
Diciamo che se tu stessi creando meccanismi giganteschi con questa OOP, sarebbe chiaro perché ne hai bisogno così tanto. Giustifichi specificamente perché hai bisogno di OOP. Ma si creano meccanismi relativamente piccoli. Non c'è abbastanza codice per trarre conclusioni su svantaggi e vantaggi di questo o quell'approccio. Ma tu continui a parlare di OOP comunque. Mentre OOP è solo uno strumento e non ha senso da solo. Cioè se non c'è nessun meccanismo da fare, OOP non è necessario. Ma se c'è un meccanismo, dovrebbe essere abbastanza serio da richiedere OOP durante la sua creazione.
La maggior parte di coloro che si battono per l'OOP non fanno nulla di serio. Fanno solo piccole cose. Tuttavia, la loro fede in OOP è incrollabile. Altri che fanno meccanismi molto più seri sono molto meno propensi a gridare la grandezza di OOP. Alcuni si esprimono anche con critiche (ci sono state un paio di volte).
Quindi, la sua argomentazione deve essere sostenuta dalla pratica, non solo dalla teoria. Io, per esempio, posso discutere dei vantaggi di OOP nello sviluppo di GUI con Anatoly, perché possiamo confrontare le soluzioni e le loro sfumature nella pratica. Ma, con te, non posso dispiegare il mio argomento perché non lo capisci. Lo farai, ma non lo capirai (senza offesa). Anatoly, al contrario, può capirlo molto bene. La differenza di esperienza nella creazione di meccanismi globali è la ragione principale dell'incomprensione.
SZY. Come praticante vi dirò questo: l'approccio deve essere tale da massimizzare il potenziale del cervello di un particolare programmatore. Ho trovato un tale approccio per me stesso.
Le fantasie sull'OOP stanno diventando sempre più selvagge...
La serietà del lavoro è determinata dal risultato, non dal numero di anni trascorsi.
Ahimè, non è una sciocchezza.
Il disegno su tela non richiede un wrapper di classe. Una lista di funzioni è sufficiente. Non avete bisogno di diritti di accesso al metodo per disegnare. E tu lo sai. Ma voi negate questo fatto. Stai negando l'ovvio.
Sì, per mangiare una banana bisogna sbucciare la buccia. Ma se una mucca ha le corna, allora tutti quelli che hanno le corna sono mucche.
Beh, non ci sono molte persone così da queste parti. Probabilmente sono uno di loro. Anche se non è per insegnarvi. Solo per sentire una risposta sensata. Perché, quando si disegna, ci si riferisce alle funzioni della classe attraverso gli oggetti, se si usa solo UNA classe?
Poiché le funzioni di disegno sulla tela si riferiscono solo al disegno sulla tela e nient'altro, quindi non c'è motivo di tenerle in un contenitore separato, ecco perché sono raccolte in una classe. Ma non lo capireste comunque.
Nikolai, stai costruendo HIERARCHY o creando meccanismi di disegno?
Se costruisci l'HIERARCHY (non ti interessa il disegno), allora è chiaro perché hai bisogno di OOP ovunque.
Se state creando un meccanismo di disegno che funziona sulla base di UNA classe, allora non avete bisogno di Class stessa.
Classe, - dalla parola Classificazione. La classificazione è una divisione per attributi. La classe è un derivato di Classificazione. Se c'è una Classe, allora non c'è Classificazione.
Quindi la classe, in questo caso, è una stronzata astratta. Non ha senso.
Cosa c'entra la gerarchia? OOP fa un uso esteso dell'ereditarietà... ...e un altro mucchio di fantasia dilagante...
...e la ciliegina sulla torta:
Ho avuto un progetto simile con un altro software piuttosto costoso, e ho anche implementato l'idea usando dei workaround (per non comprare moduli aggiuntivi).
Ho avuto un progetto simile su un altro software speciale piuttosto costoso, anche implementato l'idea da workaround (in modo da non comprare moduli aggiuntivi), ha funzionato, ma con alcuni clienti è finito in un punto morto e il tempo è stato sprecato
Ma era un campo completamente diverso, era facile trovare clienti