Il POF per gli scolari. - pagina 3

Nuovo commento
 
Koldun Zloy:

Pensavo che questo fosse ovvio anche con un piccolo numero di punti. Se ce ne sono migliaia e compongono forme più complesse, il vantaggio sarà ancora maggiore.

Avete mostrato la "tecnica sintattica" di scrivere dati e lavorare con essi. Queste sono tecniche, non il concetto di OOP. In problemi semplici, è più conveniente lavorare con gli array che scavare entità di ogni struttura e classe, non è chiaro perché siano stipati nella soluzione.

Esiste una nozione come: efficienza del meccanismo.

L'OOP in compiti semplici riduce l'efficienza e la leggibilità. Hai bisogno di un martello per martellare i chiodi e non importa se ha un display con un contatore di pugni e un misuratore di forza.

 
Реter Konow:

Avete mostrato la "tecnica sintattica" di scrivere dati e lavorare con essi. Queste sono tecniche, non il concetto di OOP. In compiti semplici, è più conveniente lavorare con gli array che costruire entità da ogni struttura e classe, non è chiaro perché siano stipati nella soluzione.

Esiste una nozione come: efficienza del meccanismo.

L'OOP in compiti semplici riduce l'efficienza e la leggibilità. Per piantare i chiodi, hai bisogno di un martello, e non importa se ha un display con un contatore di pugni e un misuratore di forza.

Nel mio esempio, la leggibilità è molto migliore e l'efficienza è altrettanto buona.

Non so cosa sia il "concetto OOP".

Sono un programmatore, non un filosofo.

 
Koldun Zloy:

Nel mio esempio, la leggibilità è molto migliore e l'efficienza è altrettanto buona.

Non so quale sia il concetto di OOP.

Sono un programmatore, non un filosofo.

Il trasferimento di tecniche di sintassi OOP a piccoli problemi crea entità inutili nella soluzione.

Prima devi imparare a fare soluzioni efficienti con una sintassi minima e "obiettività". Guarda gli algoritmi che lavorano con il colore. Non c'è niente di superfluo. Meccanismi nudi. Cioè, martelli e chiodi. E quando le cose diventano più complesse, passate al concetto di "Oggetto", "Classe"...

Questo è quello che farei io. Ma non mi metterò sulla tua strada.

 
Реter Konow:

Il trasferimento di tecniche di sintassi OOP a piccoli problemi crea entità inutili nella soluzione.

Prima devi imparare a fare soluzioni efficienti con una sintassi minima e "obiettività". Guarda gli algoritmi che lavorano con il colore. Non c'è niente di superfluo. Meccanismi nudi. Cioè, martelli e chiodi. E quando le cose diventano più complesse, passate al concetto di "Oggetto", "Classe"...

Questo è quello che farei io. Ma non mi metterò sulla tua strada.

In questo thread, sto chiedendo esempi concreti, non ragionamenti astratti. Cosa ha fatto la strutturaPOINT contro di lei?

Anche tu non mi disturbi. Questo thread è anche per te.

 
Koldun Zloy:

Cambia qualcosa?

La sintassi cambia.

obj.val=1; o obj.val(1);

e viceversa:

x=obj.val; o x=obj.val();

 
Dmitry Fedoseev:

La sintassi cambia.

obj.val=1; o obj.val(1);

e viceversa:

x=obj.val; o x=obj.val();

Comunico con chi sa come non essere scortese.

E tu vattene al diavolo.

 
Koldun Zloy:

Comunico con persone che sanno come non essere scortesi.

E tu, vattene.

Sei fuori strada?

Già... ai membri non piace proprio essere immersi nelle loro stesse stronzate.


TheXpert:
essenzialmente no.

Ed ecco il punto: a loro piace anche leccarsi l'un l'altro.

--

Ora, immagina se avessi detto quelle cose su un getter e un setter...

--

Koldun Zloy, rinomina il topic in "schoolboy LLC da schoolboy".

 
Koldun Zloy:

In questo thread, sto chiedendo esempi concreti, non ragionamenti astratti. Qual è il vostro problema con la strutturaPOINT?

Anche tu non mi dai fastidio. Questo thread è anche per te.

Ok, passiamo al codice.

Quale compito è stato fissato? - Per memorizzare le coordinate dei punti. Per cosa? - Per un accesso rapido.

La struttura POINT e le sue istanze sono entità inutili nella soluzione se il compito è solo quello di accedere rapidamente ai dati. Guardate come è più facile avere accesso tramite una matrice:

int Points[2][10]; //Объявляем в глобальной области.
//---------------------
//цикл по точкам для вычесления расстояний между ними:
//---------------------
for(int i = 0; i < 9; i++)
  {  
   int x_dist = Points[0][i + 1] - Points[0][i];
   int y_dist = Points[1][i + 1] - Points[1][i];
  }
//--------------------------

Dici di non essere un filosofo, ma la "struttura" è un concetto filosofico e la sua presenza nella soluzione deve essere giustificata.

 
Реter Konow:

Ok, passiamo al codice.

Qual era l'obiettivo? - Per memorizzare comodamente le coordinate dei punti. Per cosa? - Per l'accesso rapido.

La struttura POINT e le sue istanze sono entità inutili nella soluzione se il compito è solo quello di accedere rapidamente ai dati. Guardate come è più facile avere accesso tramite una matrice:

Dici di non essere un filosofo, ma la "struttura" è un concetto filosofico e la sua presenza nella soluzione deve essere giustificata.

È solo scomodo - devi sapere quale elemento ha x e quale ha y. Quando si usa la struttura, però, tutto è chiaro, e si eliminano gli errori e si riduce la quantità di codice.

 
Dmitry Fedoseev:


Ora immaginate se avessi dato quella sciocchezza su un getter e un setter.

Che cos'è il gibberish? Aprite la definizione di getter e leggete:

Unmetodospeciale per recuperare dati che sono direttamente limitati

Ma il meccanismo con cui i dati privati possono essere recuperati può essere diverso. In C# è un modo, in C++ e MQL è un altro. Ma questo non priva i metodi della definizione "getter".
12345678910...18
Nuovo commento
Motivazione: