Parlare dell'OLP nel salone - pagina 19

Nuovo commento
 

Volchanski, e puoi anche scriverti un argomento del coro chiamato "Do you need goto?".

 
Andrei:
Verilog

Beh, è una bella presa quella che hai). È per progettare circuiti elettronici.

 
o_o:

Volchansky, e scriviti un altro argomento di baccano "Hai bisogno di goto?".


Ho ragione di supporre che lei abbia sentimenti negativi? Perché?

 
Комбинатор:

Che differenza fa?

Hai bisogno di argomentare la tua affermazione (OOP fa schifo) - vai su Google, digita "OOP" e un paio di qualità negative, prendi un articolo e senza leggerlo, buttalo sul forum.

Vero o non vero - non importa. Non importa se lo sono o non lo sono. Se ci sono persone attente come te che si prenderanno la briga di leggerlo e controllarlo, possiamo lanciare un altro articolo nello stesso modo.

Sono un principiante in OOP, quindi ammetto con molta probabilità di non aver realizzato qualche serio svantaggio di OOP. Ho preso questo articolo come top perché mi sembrava una risorsa di programmazione seria. Forse non è così, ma nemmeno io sono un programmatore.

Di conseguenza, si dovrebbe probabilmente condurre uno studio sociologico (o psicologico) sul perché una parte della società (un individuo) sviluppa un'avversione quasi aggressiva e persistente verso certe cose.
 
George Merts:

Beh, neanche a me piacciono le ragazze... E molti altri... La solita cosa, Alexey, sono tutti animali, non tutti riescono ad addestrarli, quindi avrai un sacco di uomini invidiosi.

Ma è meglio che tu mi dica - dov'è il tuo corso? Darò un'occhiata anch'io...


Non ne hai bisogno, te l'ho mandato di persona.

 
fxsaber:

Un serio svantaggio dell'OOP è che qualcosa di complesso è difficile da progettare, cioè è molto difficile fare un'architettura che funzioni bene e si adatti senza stampelle, quindi il refactoring è molto, molto comune. Meno esperienza si ha nel design, più si può fare l'inferno. Il punto è che in OOP la struttura di un modello di oggetto normalmente progettato ha spesso poco in comune con gli oggetti reali (come li immaginiamo)

Poi dipende dal supporto di certi paradigmi da parte di certi linguaggi, in modo da poter parlare di "buono/cattivo", "applicabile/non applicabile"

Per esempio il gorilla di cui sopra con la banana non è un problema di OOP, è un problema di uso sconsiderato di gestori di pacchetti senza tracciamento delle dipendenze. Soprattutto sul web in questi giorni

 
fxsaber:

L'articolo mente!

Quando ho letto questa dichiarazione, sono diventato molto dubbioso. L'ho rapidamente girato per controllare che non fossi incasinato nella testa:

Ho evidenziato le linee che l'autore dell'articolo suggerisce di cambiare. Il risultato non è influenzato dalla loro sostituzione. Non ho letto il resto dell'articolo. Molto probabilmente, è stato fatto notare a questa sciocchezza dell'autore nei commenti.


L'articolo non mente. Ci sono funzioni virtuali, quindi tutto funziona come dice l'autore.

Ma spero che non lo prendiate come un argomento serio contro l'OOP.

I cambiamenti in una classe base possono essere grandi quanto si vuole, e aspettarsi che non influenzino il lavoro delle classi derivate è semplicemente stupido.

 
Koldun Zloy:

L'articolo non mente. Ci sono funzioni virtuali, quindi tutto funziona come scrive l'autore.

Ma spero che non pensiate che questo sia un argomento serio contro l'OOP.

Le modifiche alla classe base possono essere grandi quanto si vuole, e aspettarsi che non influenzino il lavoro delle classi derivate è semplicemente stupido.

Se virtuale, ha senso e l'autore è semplicemente incompetente nelle questioni e nelle sfide delle funzioni virtuali.

Inoltre, se doveva ottenere l'indipendenza, avrebbe dovuto fare

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}
Ma trovo che l'esempio sia buono per i principianti. Dovete capire cosa state facendo.
 
Комбинатор:

Un serio svantaggio dell'OOP è che qualcosa di complesso è difficile da progettare, cioè è molto difficile fare un'architettura che funzioni bene e si adatti senza stampelle, quindi il refactoring è molto, molto comune. Meno esperienza si ha nel design, più si può fare l'inferno. Il punto è che in OOP la struttura di un modello di oggetto normalmente progettato ha spesso poco in comune con gli oggetti reali (come li immaginiamo)

Poi dipende dal supporto di certi paradigmi da parte di certi linguaggi, in modo da poter parlare di "buono/cattivo", "applicabile/inapplicabile"

Per esempio il gorilla di cui sopra con la banana non è un problema di OOP, è un problema di uso sconsiderato di gestori di pacchetti senza tracciamento delle dipendenze. Soprattutto nel web in questi giorni.

Sì, ho incontrato alcune situazioni in cui l'architettura è stata scelta male. A volte era più facile riscrivere da zero piuttosto che modificare.

Nella codifica procedurale si può quasi sempre comporre l'architettura di un programma mentre si scrive il codice. Perché la libertà e la flessibilità sono totali, ma il crapshoot è enorme.

In OOP, invece, è consigliabile scrivere l'intera architettura sulla lavagna PRIMA di scrivere la prima riga di codice. Quando siete pronti, è molto facile scrivere il codice. E se l'architettura ha successo (qui solo l'esperienza e le capacità individuali aiutano), è altrettanto facile da perfezionare/estendere, anche se si è già dimenticato tutto del progetto.

 
Alexey Volchanskiy:

Beh, è una bella presa quella che hai). È per progettare circuiti elettronici.

Non solo.
1...121314151617181920212223
Nuovo commento