Spese generali per l'OLP - pagina 6
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
ma non funziona :-)
Ve lo dico - provate a farlo, è un sacco di codice feroce. La classe istanziabile "CFoo: public InterfaceCFoo" deve contenere il campo InterfaceCFoo *privateContext (fare una relazione 1:1), crearlo e cancellarlo tramite factory, delegare tutti i metodi e tradurre i riferimenti CFoo* this<->privateContext qua e là. Si tratta di "tramontare il sole a mano", cioè di sostituire l'eredità con la delega, e sul posto.
Creare attraverso la fabbrica e cancellare nel solito modo. Se avete bisogno di delega è determinato da come si suppone che il contenuto della libreria sia usato: se fornisce classi che fanno il lavoro da sole, allora non avete bisogno di delegare nulla - basta chiamare i metodi dell'interfaccia.
A proposito, in Android/Java c'è una cosa simile con le classi kernel - a causa della mancanza di ereditarietà multipla si deve inserire un delegato nell'oggetto e fare metodi wrapper per i suoi metodi. C'est la vie.
Ve lo dico - provatelo, è un sacco di codice feroce. La classe istanziabile "CFoo: public InterfaceCFoo" deve contenere il campo InterfaceCFoo *privateContext (fare una relazione 1:1), crearlo e cancellarlo via factory, delegare tutti i metodi e allo stesso tempo tradurre CFoo* riferimenti this<->privateContext qua e là. Si tratta di "tramontare il sole a mano", cioè di sostituire l'eredità con la delega, e sul posto.
E la lingua, una persona sobria non può capire di cosa stiamo parlando senza mezzo litro. :) E tutta questa roba OOP e tutta questa alfabetizzazione cinese è fatta per - fare un semplice scambio di dati, che è banalmente realizzato a livello procedurale...
L'OOP in sé non è da biasimare per l'esistenza di codificatori OOP viziosi. Non c'è niente di sbagliato nell'OOP in generale, sei completamente sbagliato nella tua opinione sull'OOP.
L'OOP in sé non è da biasimare per l'esistenza di codificatori OOP viziosi. Non c'è niente di sbagliato nell'OOP in generale, sei completamente sbagliato nella tua opinione sull'OOP.
Non conosci la sua storia.
Ripetuti divieti per sabotaggio diretto. Quindi non reagite alla sua bellicosa ignoranza.
In generale, non c'è niente di sbagliato nell'OOP; lei si sbaglia completamente nella sua opinione sull'OOP.
Vi darò alcune famose citazioni critiche da wiki su OOP da persone che per qualche motivo non sono chiamate ignoranti:
Come liberazione, citerò alcune famose citazioni critiche dalla wiki su OOP da persone, che per qualche ragione non sono chiamate ignoranti:
E tutti e tre: Stepanov nato nel 1950, Wirth nel 1934 e l'altrettanto antico Killea (il suo libro è stato pubblicato nel 1998) si vergogneranno molto di ripeterlo nel 2017.
Quello che hanno detto è stato così tanto tempo fa che è già imbarazzante da ricordare. I compilatori C++ erano almeno 2 ordini di grandezza più stupidi e più primitivi nelle ottimizzazioni. In effetti, non c'era una traccia di ottimizzazione. All'epoca (molto all'inizio degli anni novanta), io stesso scrivevo molto in assembler ed ero simile nel pensare: "C/C++ è lento".
Non sta a me condurre link sotto forma di citazioni spennate. Inoltre, sei già riuscito a mostrare la tua estrema ottusità e aggressiva ignoranza in questo thread.
Renat Fatkhullin:
Tanto più che sei riuscito già in questo thread a mostrare la tua estrema ottusità e aggressiva ignoranza.
Riassumiamo. Ecco la mia ipotesi principale sull'OOP: "OOP ha senso solo come un comodo involucro di testo o quando viene usato minimamente durante l'inizializzazione di runtime..." nel post #10.
Ed ecco un'opinione ragionata di un esperto indipendente con un'opinione simile e prove dettagliate a livello di codice.
http://rainman-rocks.livejournal.com/122876.html
"La conclusione finale di tutto questo è questa:
La ragione principale dell'efficacia della programmazione orientata agli oggetti è che contiene i mezzi per fornire modularità e dichiaratività. Sono la modularità e la dichiaratività gli strumenti che aumentano l'efficienza dello sviluppo - cioè "proiettili d'argento". È su questi che ci si deve concentrare quando si sceglie una metodologia. La sola OOP non dovrebbe essere l'obiettivo".
Per riassumere. Ecco la mia ipotesi di base sull'OOP: "L'OOP ha senso solo come un comodo involucro di testo o se usato minimamente nell'inizializzazione di runtime..." nel post #10.
Ed ecco un'opinione ragionata di un esperto indipendente con un'opinione simile e prove dettagliate a livello di codice.
http://rainman-rocks.livejournal.com/122876.html
"La conclusione finale di tutto questo è questa:
La ragione principale dell'efficacia della programmazione orientata agli oggetti è che contiene i mezzi per fornire modularità e dichiaratività. Sono la modularità e la dichiaratività gli strumenti che aumentano l'efficienza dello sviluppo - cioè "proiettili d'argento". È su questi che ci si deve concentrare quando si sceglie una metodologia. L'OOP in sé non dovrebbe essere l'obiettivo".
Mostrate i vostri progetti realizzati personalmente in modo che la vostra opinione sia accettata almeno in minima parte. Non puoi nemmeno capire il link citato - è solo un'ode all'OOP, incluso l'output.
Tutto il software è praticamente più del 90% scritto su OOP (non parlare di sciocchezze sui driver). Infatti è impossibile scrivere e poi mantenere un grande progetto senza OOP. E non si accettano parole su "solo un involucro" quando si tratta di affari. Lo sviluppo di software è stato a lungo un business ben consolidato e collaudato.
Coloro che si lamentano di OOP senza capire non sono consapevoli di ciò che fanno i moderni compilatori C++. Spesso non rimane nulla di OOP nel codice finale. Sto parlando di C++, ovviamente.
Mostrate i vostri progetti realizzati personalmente in modo che la vostra opinione sia accettata almeno in minima parte. Non puoi nemmeno capire il link citato - è solo un'ode all'OOP, compresa la conclusione.
Lasciate che vi dia un'altra citazione sull'idea principale di questo articolo affinché non ci siano dubbi su ciò che dice:
"Così, l'OOP, mentre cercava di sostituire la programmazione strutturata-procedurale, alla fine tornò a fare quasi la stessa cosa, ma solo in involucri di fantasia. Sorge una domanda: aveva un senso la manovra...".
Scusate, ma non capisco la logica e la relazione causa-effetto - perché avete bisogno di progetti realizzati affinché la propria opinione sia presa in minima considerazione. Di solito, in una discussione civile, è sufficiente il ragionamento e la ragionevole validità dell'opinione presentata.
Altrimenti, si arriva all'assurda conclusione che se una persona ha realizzato un progetto, allora tutte le sue dichiarazioni successive devono essere accettate da tutti inizialmente, anche se in realtà potrebbe non essere tutto liscio con il ragionamento o addirittura contraddire l'opinione di altri professionisti che hanno anche realizzato progetti.
Di nuovo, non è molto modesto vantarsi di qualcosa, perché fa male al karma.
Cioè, non ci sono progetti, quindi nessuna esperienza.
Allo stesso tempo, non si dimentica l'esperienza, cercando di tirare fuori i detti più vecchi di persone un tempo esperte(in termini di tempo). Dato che non avete la vostra esperienza, non capite che gli enunciati tolti non hanno funzionato molto tempo fa. Non hanno funzionato ed erano solo deliri propri di quel tempo. Questi deliri sono già imbarazzanti da ricordare.
Inoltre, non si capisce bene l'essenza di ciò che è scritto nei link citati. Tu strappi le parole e le interpreti male, anche se dice "OOP è meglio delle stampelle (e le stampelle sono un tentativo di emulare OOP senza OOP) e deve essere usato".