Parlare dell'OLP nel salone - pagina 10
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
Non c'è bisogno di imporre, ma è ovvio che in una forma procedurale la logica del codice è già visibile senza gesti extra, e ogni gesto di un programmatore assunto costa una tassa al datore di lavoro. Quindi, se un datore di lavoro è intelligente, non si farà ingannare dall'OOP, ma un programmatore intelligente può torcere una storia sull'OOP progressiva per ottenere più soldi da lui approfittando della sua bassa alfabetizzazione. :)
Ha!
C'è una logica di "nessuno sforzo in più" per andare in giro a piedi, ma per qualche motivo tutti vogliono prendere il trasporto. Si arriva al punto dell'idiozia - salgono in macchina, guidano per due chilometri fino a un centro fitness, e poi "fanno" cinque chilometri su un tapis roulant.
Parlando di programmazione, in DOS una finestra viene creata semplicemente scrivendo in un buffer video. Ma per creare una semplice finestra in Windows - è necessario registrare una classe finestra, crearla ed eseguire un ciclo di elaborazione dei messaggi - ma per qualche motivo, tutti fanno questi "passi in più".
Così è qui. l'OOP - non è scelto affatto per la "progressività", ma per i benefici che questa metodologia fornisce, e perché è alla fine più economico per il datore di lavoro. Perché avendo scritto qualcosa in stile procedurale non è possibile mantenerlo con la stessa efficienza di quello scritto in stile OOP.
Una buona illustrazione - il codice di Peter Konov - da un lato, un codice abbastanza normale orientato alle procedure, ma d'altra parte, per lavorare con esso bisogna sempre tenere a mente un sacco di informazioni sulla struttura del sistema, che personalmente non intraprenderò un tale compito anche per grandi cifre. Allo stesso tempo, SB scritto in stile OOP è molto facile da mantenere e cambiare. L'architettura degli oggetti nel pattern TC della Standard Library è molto più intricata che nel codice di Peter, tuttavia è molto più facile da capire e modificare.
Tutto il discorso su "uno stile procedurale senza lavoro extra" è solo fino al punto in cui si ha bisogno di scrivere una struttura davvero complessa, e soprattutto di apportarvi delle modifiche. Questo è il motivo per cui l'OOP è così diffuso: è più facile per i programmatori e più economico per i clienti. Anche se, per fare qualcosa di abbastanza semplice in esso richiede "gesti inutili". Semplicemente, nessuno ha bisogno di questo "semplice", tutti hanno bisogno di "complesso", che è meglio fare con l'uso di OOP.
P.S. E ancora non capisco, come lei (parliamo di "Lei") propone di limitare l'accesso alle funzioni, che non dovrebbero essere usate da nessuna parte senza modificatori di accesso OOP?
George Merts:
Perché se scrivete qualcosa in stile procedurale, non sarete in grado di mantenerlo con la stessa efficienza di qualcosa scritto in stile OOP.
P.S. E non ho ancora capito, come lei (parliamo di "lei") propone di limitare l'accesso alle funzioni, che non dovrebbero essere usate da nessuna parte senza modificatori di accesso OOP?No, no. È proprio il contrario.
È solo codice OOPeshe che è difficile da mantenere e modificare perché c'è un sacco di vari colpi di scena in esso che poi è più facile scrivere il codice ancora una volta. Infatti, si dice che lo scopo di OOP è quello di nascondere la logica, quindi l'hanno nascosta, e se improvvisamente è necessario aprirla, questo è un servizio a pagamento.
Function wrapper permette di nascondere le funzioni interne, ma se improvvisamente avete voglia di aggiungere questa funzione interna per quello che volete, potete nasconderla in una DLL, o il codice sorgente in un file separato, e il file nella directory più lontana, così non sarà trovato anche se ci provate, forse ci sono più opzioni per programmatori particolarmente scatenati. :)
No, non lo è. È proprio il contrario.
Il codice OOP è altrettanto difficile da mantenere e modificare, perché la logica è nascosta con un sacco di trucchi diversi, che poi è più facile riscrivere il codice. Infatti si dice che lo scopo di OOP è quello di nascondere la logica, quindi l'hanno nascosta, e se improvvisamente è necessario scoprirla, questo è un servizio a pagamento.
La funzione Wrapper permette di nascondere le funzioni interne, ma se improvvisamente volete aggiungere questa funzione interna per qualsiasi cosa, potete nasconderla in una DLL, o il codice sorgente in un file separato, e il file nella directory più lontana, in modo che al massimo il desiderio non possa essere trovato, forse ci sono opzioni per programmatori particolarmente furiosi. :)
Perché sarebbe "difficile da modificare" se la logica è nascosta? È per questo che la logica è nascosta, per impedire di modificare qualcosa dove non si può fare.
È solo nell'approccio procedurale che vuoi cambiare qualcosa, l'hai cambiato, e poi non capisci perché non funziona (o peggio - a volte ottieni errori incomprensibili). E nell'approccio OOP volete cambiarlo - e non avete accesso agli interni della classe. E se non c'è accesso, significa che è fatto per una ragione, c'è qualcosa di complicato lì, alcune condizioni implicite di utilizzo. Rispettivamente, se volete cambiare qualcosa, potete prendere proprio quella classe, ereditare la sua classe e cambiare lì ciò di cui avete bisogno, poiché avete già accesso ai metodi di protezione nel discendente.
E anche se si eredita, si può inciampare in un metodo o campo privato che non è disponibile nemmeno nel discendente, e ancora una volta, per una ragione, significa che questo campo non è destinato ad essere cambiato nemmeno nel discendente.
Parlando di "nascondere in DLL" - il problema è che si può nascondere solo TUTTO in una DLL. Non è una parte dell'oggetto. Ed è a questo che serve il modificatore di accesso, per nascondere solo una parte dell'oggetto. Questo è il motivo per cui tutto è concepito - per permettere al programmatore in ogni luogo del programma di avere accesso solo a ciò di cui ha bisogno, e niente "dall'alto" - questo permette di non avere paura che potrebbe accidentalmente cambiare non ciò di cui ha bisogno, ma potrebbe cambiare la parte, che è ammissibile per la modifica. Qual è lo scopo della DLL allora? Aprire il codice della DLL - allora viene aperto l'intero codice, non parti. Chiudi - di nuovo, tutti gli accessi sono chiusi.
Non so come limitare l'accesso in stile procedurale senza usare sezioni private-protette-pubbliche. E questa restrizione mi aiuta molto.
Perché sarebbe "difficile da modificare" se la logica è nascosta? La logica è nascosta in modo da non poter modificare nulla dove non si può.
È solo nell'approccio procedurale che vuoi cambiare qualcosa, l'hai cambiato, e poi non capisci perché non funziona (o peggio - a volte ottieni errori incomprensibili). E nell'approccio OOP volete cambiarlo - e non avete accesso agli interni della classe. E se non c'è accesso, significa che è fatto per una ragione, c'è qualcosa di complicato lì, alcune condizioni implicite di utilizzo. Rispettivamente, se volete cambiare qualcosa, potete prendere proprio quella classe, ereditare la sua classe e cambiare lì ciò di cui avete bisogno, poiché avete già accesso ai metodi di protezione nel discendente.
E anche se si eredita, si può inciampare in un metodo o campo privato che non è disponibile nemmeno nel discendente, e ancora una volta, per una ragione, significa che questo campo non è destinato ad essere cambiato nemmeno nel discendente.
Parlando di "nascondere in DLL" - il problema è che si può nascondere solo TUTTO in una DLL. Non è una parte dell'oggetto. Ed è a questo che serve il modificatore di accesso, per nascondere solo una parte dell'oggetto. Questo è il motivo per cui tutto è concepito - per permettere al programmatore in ogni luogo del programma di avere accesso solo a ciò di cui ha bisogno, e niente "dall'alto" - questo permette di non avere paura che potrebbe accidentalmente cambiare non ciò di cui ha bisogno, ma potrebbe cambiare la parte, che è ammissibile per la modifica. Qual è lo scopo della DLL allora? Aprire il codice della DLL - allora viene aperto l'intero codice, non parti. Chiudi - di nuovo, tutti gli accessi sono chiusi.
Non so come si possa limitare l'accesso in stile procedurale senza usare sezioni private-protette-pubbliche. E questa restrizione mi aiuta molto.
George, stai battendo di nuovo il tamburo )))) Questo non ha senso.
Georges, stai di nuovo menando il can per l'aia )))) Non ha alcun senso.
Forse, forse.
Ma tu sei un Casanova part-time... E sono un tutor part-time. Vedo che "il cliente non è perso". Così continuo a spiegare. Come "deformità professionale".
Forse, forse.
Ma tu sei il Casanova part-time... E sono un tutor part-time. Vedo che "il cliente non è perso". Quindi, continuo a spiegarmi. Come "deformità professionale".
Ne ho abbastanza dei Casanova. Hai inventato una favola e ci hai creduto tu stesso) come un bambino crede a Babbo Natale, per l'amor di Dio).
Non c'è bisogno di imporlo, ma è ovvio che nella forma procedurale la logica del codice si vede già senza gesti extra, e ogni gesto di un programmatore assunto costa al datore di lavoro.
La quantità di sforzo corporeo nel codice di procedura di cui sopra dovrà essere aumentata se è necessario apportare dei cambiamenti.
È possibile scrivere codice senza funzioni (procedure). Ma il coding alla fine ha smesso di essere scritto attraverso "colate di cemento" e ha iniziato a costruire da "mattoni". Da qui è nata la programmazione procedurale.
L'OOP è un altro passo nella scomposizione del lavoro complessivo in componenti più semplici.
La divisione del lavoro e, di conseguenza, la convogliazione della produzione di qualsiasi cosa creò la rivoluzione industriale, che portò all'industrializzazione dell'umanità.
Fatto a mano è "scrivere codice senza procedure".
Conveyor è "scrittura di codice procedurale", dove molti elementi del trasportatore dipendono dagli altri. Cioè, cambiare un elemento può richiedere di cambiarne un altro.
La "programmazione OOP" è una pipeline con una dipendenza ridotta tra gli elementi. Cioè, un elemento può essere sostituito da un altro e la conduttura ha meno probabilità di smettere di funzionare. Essere in grado di scomporre qualsiasi produzione in parti indipendenti, inserire standard, ecc. - è la produzione orientata agli oggetti (non la programmazione).
La programmazione stessa è un caso speciale di produzione. L'approccio OOP è un approccio di principio per produrre qualsiasi cosa. Pertanto, è molto stretto parlare di programmazione. OOP è stato applicato con successo PRIMA della sua comparsa nella programmazione.
Ne ho abbastanza dei Casanova. Hai inventato una favola e ci hai creduto tu stesso (come un bambino che crede a Babbo Natale, per l'amor di Dio).
Ti invidio, Lech!
Molto seriamente. Beh, lasciatemi il diritto a una piccola iperbole artistica...
Il numero di movimenti corporei nella...
О ! Ben detto.
Completamente solidale.
La quantità di sforzo corporeo nel codice di procedura di cui sopra dovrà essere maggiore se è necessario apportare modifiche.
In linea di principio, la quantità di sforzo corporeo in OOP non può essere inferiore, poiché tutte queste interfacce sono un overhead aggiuntivo, che spesso supera il costo della scrittura della logica stessa. E questo nonostante il fatto che qualsiasi funzione ha già un'interfaccia, cioè si propone di fare un'altra copertura, che è essenzialmente senza senso.
Allo stesso tempo, qualsiasi cambiamento nel codice, sia nell'interfaccia che nella funzione, diventa molto più complicato, poiché uno è agganciato all'altro, il che significa che abbiamo un aumento almeno quadratico del possibile numero di bug e dell'intensità del lavoro... È abbastanza ovvio, no?