Rappresentazione di un oggetto nella programmazione.

 

Questo argomento sarà di interesse per coloro che si preoccupano delle questioni di programmazione globale.

La domanda che mi tormenta è "perché il ben noto modello Object è nel canone standard dei concetti OOP?"Cioè, un Oggetto è un'entità che le persone descrivono a parole ogni volta che pronunciano la parola. Con l'avvento della programmazione, il tentativo di descrivere l'Oggetto tramite il codice era logicamente collegato e fu inventata una tecnologia speciale per farlo, ma ecco la domanda: perché solo uno? Come se la prima lingua sostituisse completamente le altre e non le lasciasse evolvere. Questo è impossibile nei tempi antichi, ma possibile nell'era del globalismo e della propaganda. E così è successo - una rappresentazione dell'Oggetto ha conquistato il mondo e ha bloccato le direzioni di altre idee.

Avrei accettato la concezione standard dell'Oggetto molto tempo fa, se (come filosofo) non avessi avuto qualche lamentela a riguardo.

  1. Prima di tutto, una prefazione: un passo evolutivo nella programmazione è stato fatto quando è stata affermata la tesi principale - la programmazione prende "oggetti" come base e qualsiasi programma dovrebbe logicamente rompersi in essi. Cioè, non scriviamo più algoritmi (sequenze di operazioni), ma creiamo "entità". Gli algoritmi, invece, li mettiamo nella loro struttura in modo che diventino parte di un "insieme" complessivo di interazioni. Perché? - È più efficiente in questo modo. MA, ecco la domanda: dov'è il concetto filosofico "ufficialmente registrato" dell'Oggetto? Ahimè, a tutt'oggi non esiste, né può esistere.

Questo significa che gli autori del concetto di OOP hanno agito arbitrariamente, facendo affidamento sull'"infallibilità" delle loro nozioni filosofiche.

2. Ecco alcune delle mie affermazioni:

(1) Perché il concetto standard non ha uno strumento " Lo stato di"? Gli oggetti non hanno stati? Uno stato può essere descritto in una struttura, ma questo è scomodo. Il concetto standard non è progettato per lavorare con gli stati degli oggetti. Per esempio: creo una struttura speciale, elenco i parametri dell'oggetto, ne copio una parte (parametri selezionati), nomino questa parte come stato e scrivo dei valori che corrispondono a qualche stato dell'oggetto. Poi lo collego alla struttura principale dell'oggetto.

(2) Non esiste uno strumento di"evento". Voglio dire, un Evento "aleggia" nel concetto standard, ma non può essere descritto come un'enumerazione, una classe o una funzione. Una semplice descrizione di un evento nella programmazione sarebbe utile. Per esempio: descriverlo come una struttura, ma in esso puntare a stati "di fondo" dell'ambiente e degli oggetti, e puntare a un cambiamento chiave, che è il trigger per iniziare una catena di altri cambiamenti. Di nuovo - OOP non è affilato per la descrizione concisa degli eventi e offre di descriverli in un mucchio di condizioni, che non hanno nome e si trovano "ovunque".

(3) Inoltre, un parametro non è un oggetto indipendente. Infatti - è l'oggetto più importante, che può essere modellato e qualsiasi sistema può essere assemblato dalle sue copie e modifiche. Non lo fa...

Potrei continuare all'infinito, ma il mio messaggio è chiaro: costruite la vostra OOP e forse inventerete qualcosa di molto più figo, perché nessuno ha provato a farlo seriamente prima di voi. E il concetto standard è una visione soggettiva, non fisica o matematica e può essere modificato)).

Документация по MQL5: Константы, перечисления и структуры / Состояние окружения
Документация по MQL5: Константы, перечисления и структуры / Состояние окружения
  • www.mql5.com
Константы, перечисления и структуры / Состояние окружения - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 

c'è un design pattern chiamato stato

c'è un modello di osservatore

C'è il modello della bicicletta. È il modello preferito di Peter.
 

Sia C# che Delphi hanno proprietàhttps://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties

e gli ewent non sono un espediente per molto tempo

ma, secondo me, un altro argomento sulle parole di una canzone piuttosto buona "Fairy" - YazheVik .... Tu vai e io sono una fata! ....

 
In generale, quando si definisce l'Oggetto, si deve definire anche il Soggetto, altrimenti questa è una descrizione incompleta del mondo, inoltre nelle concezioni filosofiche più moderne c'è il Traiettoria con uno statuto relazionale indipendente come legame intermedio/legame tra l'Oggetto e il Soggetto.
 

Peter, che arriva di nuovo dalla parte sbagliata. Perché lo stato dovrebbe essere uno strumento? Lo Stato era ed è, non è andato da nessuna parte, è ancora più primordiale di tutto il resto. E sì - un evento non è uno stato, quindi non è descritto ma registrato.

 

Реter Konow:

...ma dov'è il concetto filosofico "ufficialmente registrato" dell'Oggetto? Ahimè, a tutt'oggi non esiste, né può esistere. ...

Perché non si basa affatto sulla filosofia. L'Oggetto nella programmazione non è qualcosa di sublime, mistico o qualsiasi altra cosa che si possa immaginare. È semplicemente un amalgama di funzioni e variabili.

 
Реter Konow:

Questo argomento sarà di interesse per coloro che si preoccupano delle questioni di programmazione globale.

Mi sto chiedendo: "perché il modello a oggetti comunemente noto nel concetto standard di OOP è un canone?".

Perché le prime due grandi O vengono prima. Poiché il concetto è orientato agli oggetti, sono l'essenza del concetto. Allo stesso modo che nel concetto di programmazione procedurale le procedure sono il punto principale, in SQL le query sono il punto principale, ignorando come vengono eseguite, e così via. L'essenza, non il canone. La canonizzazione di OOP con la sua opposizione ad altri approcci è attivamente impegnata in questo forum, ecco perché c'è una tale impressione.

 

Invece di reinventare la vostra bicicletta, dovreste studiare la teoria dei tipi e praticare la sua applicazione alla programmazione in linguaggi funzionali (ad esempio Haskel).

Per una comprensione dei fondamenti filosofici e logici, potete leggere Bertrand Russell.

 
Реter Konow:

Questo argomento sarà di interesse per coloro che si preoccupano delle questioni di programmazione globale.

Bla bla bla.

Tutto questo non ha niente a che vedere con l'OOP o la programmazione.

Meglio chiamarlo "Quanti oggetti possono stare sulla punta di un ago?

 
Vladimir:

Perché ci sono due O maiuscole in primo luogo. Poiché il concetto è orientato agli oggetti, essi sono l'essenza principale del concetto. Proprio come nel concetto di programmazione procedurale il punto principale sono le procedure, in SQL il punto principale sono le query, ignorando il modo in cui vengono eseguite, ecc. ecc. L'essenza, non il canone. La canonizzazione di OOP con la sua opposizione ad altri approcci è attivamente impegnata in questo forum, ecco perché c'è una tale impressione.

Ho fatto una domanda: "perché c'è un solo standard per descrivere e costruire oggetti"?
Avete deciso che la mia domanda è "perché l'OOP è canonico?
L'orientamento a oggetti nella programmazione struttura, scala e implementa i compiti. Non c'è dubbio. Ma perché il formato è lo stesso?
 
Dmitry Fedoseev:

Perché non si basa affatto sulla filosofia. L'oggetto della programmazione non è qualcosa di nobile o mistico o qualsiasi altra cosa a cui si possa pensare. È semplicemente un amalgama di funzioni e variabili.

Qui è dove non si può fare a meno di un concetto filosofico. Unire semplicemente funzioni e variabili senza seguire un progetto ben pensato dell'oggetto? Ci vengono dati certi strumenti: classi, strutture, modificatori di accesso... ma potrebbero esserci altri strumenti... per esempio stato, campionamento, mappatura... perché no? Il mio punto è che il formato OOP e il toolkit possono avere versioni...
E in certi casi, una versione diversa del formato di descrizione dell'oggetto può essere più efficace.