Una domanda per gli esperti di OOP. - pagina 52

Nuovo commento
 

Ho guardato attraverso il mio nuovo prisma, un ibrido di OOP e Kernel, i sistemi di oggetti descritti nei programmi, e mi è quasi scoppiato il cervello. Prima di tutto, ho dato una nuova occhiata ai miei sistemi GUI. Attraverso tutti questi oggetti-parametri, oggetti-stati, oggetti-eventi e gestori. Dato che la GUI e la sua tecnologia mi sono familiari, tutto sembrava abbastanza chiaro, ma il sistema è molto complesso. Una massa di parametri, mappature e gestori. Sono giunto alla conclusione che tali sistemi non possono sorgere da soli. E la selezione naturale non ha alcun potere qui.

Ecco perché:

Ogni parametro può avere n numero di parametri derivati. Diciamo: un cambiamento di X può generare infiniti parametri derivati dai valori di quell'X in qualsiasi momento.

Ogni parametro derivato deve avere un gestore e un collegamento ad altri parametri. Nessun parametro esiste da solo. Il link è obbligatorio.

L'accoppiamento può essere diverso, e di conseguenza può apparire una varietà di gestori-filtri, correttori, trasduttori.

Gli eventi che possono essere considerati significativi per i sistemi sono indefinitamente molti. Ognuno ha le sue proprietà, i suoi collegamenti e i suoi gestori. Le variazioni sono innumerevoli.

Così, senza un concetto, nessun sistema può nascere. (Molto probabilmente).

Non è chiaro come si sia originata la vita sulla Terra...

 

Ecco un altro esempio:

Consideriamo un sistema per spostare una finestra con controlli su un grafico.

  • Prendiamo due parametri - x e y - dall'oggetto "cursore". Da essi, create due oggetti parametro derivati che memorizzeranno la differenza tra i valori attuali e passati di x e y. (Gli oggetti parametro non sono solo variabili, sono oggetti con proprietà proprie).
  • Creiamo un oggetto Handler per gli oggetti Parametro che (1) gestirà i valori x e y, recuperando la loro differenza tra i valori attuali e passati all'evento di gestione della finestra, che è scritto nelle proprietà dell'Handler, (2) scriverà la differenza nei parametri derivati allo stesso evento.
  • Creare un Link Object tra gli oggetti parametro derivati e gli oggetti parametro x,y di ogni oggetto finestra, che sarà usato per passare i valori ad essi.
  • Dopo Object-binder, creiamo un altro oggetto Handler, che dovrebbe prendere il valore da object-parameters x e y di ogni oggetto finestra e aggiungere ad esso un valore che va sul binder.

Così, con questo sistema, possiamo cambiare le coordinate di una finestra e dei suoi oggetti nel momento in cui la sua maniglia viene afferrata dal cursore. Per spostare il tutto, abbiamo bisogno di associare il tutto alle funzioni del gestore ObjectSetInteger che cambiano la posizione dell'oggetto MT sul grafico.

Questa è un'implementazione di una sola funzione GUI collegando blocchi di sistema speciali - Parametri oggetto, Gestori oggetto, ecc.

Costruire un tale sistema nel Kernel, non è un po' più facile (o forse anche più difficile) che scrivere codice normale senza trasformare tutto in un Oggetto. Ma continuerò a scavare...


ZS. Ho dimenticato di aggiungere che per spostare la finestra, dobbiamo anche "costruire" un Oggetto Evento, che blocca la maniglia della finestra e il movimento del cursore. E questo oggetto evento, collegatelo al gestore dell'oggetto dei valori x,y del cursore (che scrive la differenza nei parametri derivati), e funzionerebbe solo su segnale di questo evento.

E per ogni oggetto evento, è necessario creare un gestore di oggetti e legarlo ad esso.

Ogni object-handler ha le sue proprietà e i valori che usa quando lavora con parametri o eventi. Pertanto, ci deve essere un modello, o vi impantanerete a creare tutto).

 
Реter Konow:

Ecco un altro esempio:

Consideriamo un sistema per spostare una finestra con controlli su un grafico.

  • Prendiamo due parametri - x e y - dall'oggetto "cursore". Da essi, create due oggetti parametro derivati che memorizzeranno la differenza tra i valori attuali e passati di x e y. (Gli oggetti parametro non sono solo variabili, sono oggetti con proprietà proprie).
  • Creare un oggetto Handler per gli oggetti Parametro che (1) gestirà i valori x e y, recuperando la loro differenza tra i valori attuali e passati all'evento di gestione della finestra, che viene scritto nelle proprietà dell'Handler, (2) scriverà la differenza nei parametri derivati allo stesso evento.
  • Creare un Link Object tra gli oggetti parametro derivati e gli oggetti parametro x,y di ogni oggetto finestra, che sarà usato per passare i valori ad essi.
  • Dopo Object-binder, creiamo un altro oggetto Handler, che dovrebbe prendere il valore da object-parameters x e y di ogni oggetto finestra e aggiungere ad esso un valore che va sul binder.

Così, con questo sistema, possiamo cambiare le coordinate di una finestra e dei suoi oggetti nel momento in cui la sua maniglia viene afferrata dal cursore. Per spostare il tutto, abbiamo bisogno di associare il tutto alle funzioni del gestore ObjectSetInteger che cambiano la posizione dell'oggetto MT sul grafico.

Questa è un'implementazione di una sola funzione GUI collegando blocchi di sistema speciali - Parametri oggetto, Gestori oggetto, ecc.

Costruire un tale sistema nel Kernel, non è un po' più facile (o forse anche più difficile) che scrivere codice normale senza trasformare tutto in un Oggetto. Ma continuerò a scavare...


ZS. Ho dimenticato di aggiungere che per spostare la finestra, dobbiamo anche "costruire" un Oggetto Evento, che blocca la maniglia della finestra e il movimento del cursore. E questo oggetto evento, collegatelo al gestore dell'oggetto dei valori x,y del cursore (che scrive la differenza nei parametri derivati), e funzionerebbe solo su segnale di questo evento.

E per ogni oggetto evento, è necessario creare un gestore di oggetti e legarlo ad esso.

Ogni object-handler ha le sue proprietà, e i suoi valori sono usati da esso quando lavora con parametri o eventi. Pertanto, ci deve essere un modello, o vi impantanerete a creare tutto questo).

Difficile. Ingiustificatamente difficile.
L'oggetto principale di una forma, all'interno del quale si trovano altri oggetti di questa forma, è l'unico che riceve coordinate. Cambiando qualsiasi coordinata si cambia la posizione dell'oggetto principale del modulo. Agli altri oggetti in quella forma vengono semplicemente passate le coordinate relative che determinano la loro posizione all'interno della forma. Tutti gli oggetti hanno il loro ordine nella forma, e sono riordinati in quell'ordine. Ogni oggetto ha una lista di ciò che contiene al suo interno. Il riferimento all'elenco dei contenuti permette di comandare ogni contenuto ad un offset. Così, dando un comando di spostamento all'oggetto modulo, la catena viene automaticamente passata a spostare tutto il contenuto del modulo. Cioè, solo la forma è compensata, e tutto il resto è automaticamente compensato. Non abbiamo bisogno di dare ad ogni oggetto modulo un comando di offset da solo.
Lo facciamo per un solo oggetto. Tutti gli altri lo ripeteranno. Non importa quanto sia complesso un oggetto form, un singolo comando di offset sarà passato a tutti i contenuti di quel form in una valanga.
Tutto viene fatto solo una volta. E poi tutto sarà fatto in una catena.
 
Artyom Trishkin:
Complicato. Ingiustificatamente complicato.
L'oggetto principale di una forma, all'interno del quale si trovano gli altri oggetti di questa forma, è l'unico che riceve coordinate. Cambiando qualsiasi coordinata si cambia la posizione dell'oggetto principale del modulo. Agli altri oggetti nella forma vengono semplicemente passate le coordinate relative che determinano la loro posizione all'interno della forma. Tutti gli oggetti hanno il loro ordine nella forma, e sono riordinati in quell'ordine. Ogni oggetto ha una lista di ciò che contiene al suo interno. Il riferimento all'elenco dei contenuti permette di dare ad ogni contenuto un comando di offset. Così, dando un comando di spostamento all'oggetto modulo, la catena viene automaticamente passata a spostare tutto il contenuto del modulo. Cioè, solo la forma è compensata, e tutto il resto è automaticamente compensato. Non dobbiamo dare ad ogni oggetto modulo un comando di offset da solo.
Lo facciamo per un solo oggetto. Tutti gli altri lo ripeteranno. Non importa quanto sia complesso un oggetto form, un singolo comando di offset sarà passato all'intero contenuto di quel form in una valanga.
Tutto viene fatto solo una volta. E poi tutto sarà fatto in una catena.

Proprio così.

Il binding tra i parametri derivati che contengono la differenza x,y del cursore e gli oggetti modulo (che sono nella catena) ha un gestore al centro che può eseguire un collegamento seriale ai parametri x,y di ogni oggetto modulo. Cioè, legare i parametri tramite il gestore della connessione seriale permette di sostituire il legame di ogni oggetto modulo con parametri derivati che passano valori di differenza x,y. Ci stavo anche pensando.

Nella mia GUI, lo spostamento della finestra è implementato all'interno della funzione che fa quanto segue:

(1) Controllore di eventi per l'evento click della maniglia della finestra

(2) evento Move cursor

(3) Calcolo della differenza tra le coordinate del cursore attuale e quelle del cursore passato

(4) Scorrere gli oggetti della finestra e cambiare le loro coordinate regolando la differenza nella posizione del cursore.

(5) Chiamare ObjectSetInteger per spostare l'oggetto МТ della forma della finestra (canvas) lungo il grafico della distanza data.


Quindi, l'implementazione all'interno della funzione è corretta. L'implementazione attraverso Object Handlers, Object Parameters e Object Bindings sembra imbarazzante su questo sfondo. Ma, scaviamo dentro...

 
Реter Konow:

Questo è corretto.

La mappatura tra i parametri derivati che contengono la differenza x,y del cursore e gli oggetti modulo (che sono nella catena) ha un gestore nel mezzo che può eseguire una connessione seriale ai parametri x,y di ogni oggetto modulo. Cioè, legare i parametri tramite il gestore della connessione seriale permette di sostituire il legame di ogni oggetto modulo con parametri derivati che passano valori di differenza x,y. Ci stavo anche pensando.

Nella mia GUI, lo spostamento della finestra è implementato all'interno della funzione che fa quanto segue:

(1) Controllore di eventi per l'evento click della maniglia della finestra

(2) evento Move cursor

(3) Calcolo della differenza tra le coordinate del cursore attuale e quelle del cursore passato

(4) Scorrere gli oggetti della finestra e cambiare le loro coordinate regolando la differenza nella posizione del cursore.

(5) Chiamare ObjectSetInteger per spostare l'oggetto МТ della forma della finestra (canvas) lungo il grafico della distanza data.


Quindi, l'implementazione all'interno della funzione è corretta. L'implementazione attraverso Object Handlers, Object Parameters e Object Bindings sembra imbarazzante su questo sfondo. Ma, scaviamo dentro...

Sì, perché non c'è bisogno di fare questi gestori separati dall'oggetto. La classe che restituisce le coordinate del cursore può essere resa statica - sarà disponibile per qualsiasi classe nel programma, e ottenere le coordinate e rispondere ad esse dovrebbe essere implementato in ogni oggetto. Ma solo l'oggetto principale del modulo dovrebbe chiamare questi gestori. Poi per tutti gli altri oggetti di forma è sufficiente specificare nuove coordinate e ridisegnare. All'interno dell'oggetto modulo c'è una lista di tutti i suoi oggetti. L'oggetto form ha definito il cambiamento delle sue coordinate - imposta nuovi valori alle sue coordinate, passa attraverso la sua lista di oggetti e chiama i metodi per impostare le coordinate di ogni oggetto nella sua lista. Allo stesso tempo, ogni oggetto successivo fa la stessa cosa quando le sue coordinate cambiano - guarda attraverso la sua lista di oggetti e ordina loro di cambiare le loro coordinate. Gli oggetti nelle liste sono disposti nell'ordine in cui sono disegnati (sequenza Z). In altre parole, ogni oggetto ha il proprio metodo per cambiare le coordinate, ma è implementato nello stesso modo - guarda attraverso la lista di tutti gli oggetti "amici" e chiama lo stesso metodo per ognuno di loro. Così, chiamando questo metodo una volta per l'oggetto principale del modulo, avviamo automaticamente un cambio di coordinate per tutti gli oggetti del modulo. Dopo che tutti gli oggetti "propri" dell'oggetto modulo sono stati elaborati, viene invocato il metodo redraw chart dell'oggetto modulo, che è lo stesso per tutti gli oggetti modificati.

 
Artyom Trishkin:

...

Questa è la visione OOP standard del meccanismo di movimento delle finestre. Ve ne mostrerò uno diverso. Per fare questo, libera la tua mente per un secondo e segui semplicemente il mio pensiero.

  1. Immaginate una matrice di array. Le dimensioni sono indefinite. Forse è infinito, forse no. Non importa.
  2. La matrice è inizializzata con degli zeri. Gli zeri rappresentano il vuoto. Cioè, la matrice è vuota.
  3. Nel vuoto della matrice è apparso qualcosa di diverso dal vuoto. È uno zero sostituito da un valore. Non importa cosa sia.
  4. Vediamo questo valore nella matrice vuota e diciamo "questo è un parametro". Cioè, non il valore stesso - ma la cella in cui è apparso. La cella viene onorata con il titolo e chiamata parametro, cioè la "capacità" che contiene il valore.
  5. Il parametro esige immediatamente la sua definizione. È come se dicesse: "Sono un parametro e ho una personalità! Dove sono le mie proprietà?". E non abbiamo altra scelta che aggiungere al parametro le sue proprietà, che sono anch'esse parametri con i loro propri valori. Li mettiamo accanto e abbiamo una catena - un parametro e le sue proprietà. Diciamo "abbiamo creato un oggetto-parametro!
  6. Poi, il parametro "dice": "Dove sono gli altri parametri?! Perché sono l'unico?". E poi creiamo qualche altro parametro nel vuoto della matrice, in modo che il "primogenito" non si annoi. Naturalmente, ognuno dei nuovi parametri dichiara la sua individualità e richiede proprietà come suoi portatori. Così crescono catene di parametri, tra i quali ci sono i "primogeniti" e le loro proprietà. Noi diciamo: "Abbiamo creato degli oggetti parametrici!
  7. Ora nel vuoto della matrice abbiamo diversi parametri con catene delle loro proprietà. Ma ognuno di loro "urla" l'insensatezza della propria esistenza. Ognuno di loro è solo. Poi, decidiamo di collegare i parametri in modo che non si "annoino". Per fare questo, creiamo dei parametri speciali che servono come legami tra altri parametri. Sono anche costituiti da catene di proprietà. Ora, i parametri primogeniti sono legati l'uno all'altro da una concatenazione di parametri. Tutti sono felici! Noi diciamo: "Abbiamo creato degli oggetti legati a dei parametri!
  8. Ma, poi si scopre che i primari dei parametri vogliono comunicare e trasferire valori tra di loro attraverso i binding, ma i binding prevedono il trasferimento di valori (linguaggio dei parametri), ma non prevedono la traduzione. Ed essendo soli, i parametri capiscono solo la loro lingua, il che significa che c'è una "barriera linguistica" tra i parametri e richiedono che noi la risolviamo.
  9. Per risolvere il problema della "comunicazione dei parametri" non avevamo abbastanza mappature, avevamo bisogno di una traduzione. Questo significa che i valori passati tra i parametri devono essere convertiti, tenendo conto delle proprietà di ogni parametro. Alcuni di loro capiscono i valori nell'intervallo 1-10; altri capiscono (-5) - (-105). Alcuni operano con numeri frazionari, altri con potenze. Pertanto, concludiamo che abbiamo bisogno di "traduttori", cioè di gestori di valori che tengano conto delle proprietà dei parametri. Creiamo degli oggetti Handler speciali e li inseriamo nelle mappature dei parametri. Gli oggetti Value Handler "traducono" i valori passati tra i parametri usando le proprietà dei parametri che passano e ricevono, e le proprie proprietà. Noi diciamo: "Abbiamo creato gli oggetti Handler! Ora i parametri possono comunicare liberamente!".
  10. I parametri del primogenito comunicavano e comunicavano e si sono stancati. Stanco di questo. Poi hanno deciso che avrebbero comunicato solo in occasioni speciali - beh, quando uno di loro ottiene un valore incredibile. Ma, come si è scoperto, avevamo bisogno di tenere d'occhio il valore, come un bambino, senza sosta. I parametri del primogenito ci hanno chiesto di pensare a un "sistema di monitoraggio" che segnalasse variazioni insolite in modo che non si preoccupassero. Così, abbiamo fatto uno stampo dei valori a cui dovremmo reagire e vi abbiamo aggiunto un gestore speciale, che ha dato come risultato un "oggetto evento". L'abbiamo collegato ad ogni parametro e iniziano a comunicare tra di loro usando i segnali degli Event Objects. Così, abbiamo creato "Oggetti-eventi".

Questa è la fine del racconto...

Abbiamo guardato la matrice dall'esterno e siamo rimasti a bocca aperta! "Abbiamo creato un sistema di oggetti!)

ZS. Notate che tutto può essere creato in una matrice-array. E l'array-matrice è il Nucleo. E le entità in esso - gli oggetti reali. E parametri, ed eventi, e legami, e proprietà, e gestori. Ci sono innumerevoli sistemi che si possono costruire nel Kernel a partire da queste cose di base.

 

Una finta continuazione...

11. In qualche modo i parametri del primogenito hanno deciso di seguire una moda. Hanno scoperto che c'è una fiera delle proprietà da qualche parte nella matrice, e un certo spazio nella novità. Si dice che abbia tre proprietà. Le "dimensioni" sono chiamate. Queste proprietà hanno una gamma presumibilmente infinita di valori, e come bonus danno un altro "parametro-tempo". I parametri sono arrivati alla fiera e hanno preso le proprietà x,y,x_size,y_size. Dicono che vogliono fare un guscio nello spazio. E hanno preso colore. Sono tornati e hanno iniziato a vestire le nuove proprietà. Hanno modellato e modellato degli involucri spaziali finché non si sono stancati. Sono cresciuti immensamente, poi sono crollati... Poi si sono colorati e si sono rilassati. Cominciarono a pensare a cosa fare dopo. E poi hanno guardato la casella delle proprietà del tempo. Vediamo di cosa si tratta... L'hanno aperta, l'hanno attaccata a se stessi, ma non hanno calcolato i valori e in un attimo è evaporata nel vuoto. Dopo tutto, il tempo è un parametro con il quale bisogna stare molto attenti...

 
Реter Konow:

Una finta continuazione...

11. In qualche modo i parametri del primogenito hanno deciso di seguire una moda. Hanno scoperto che c'è una fiera della proprietà da qualche parte nella matrice, e un certo spazio nella novità. Si dice che abbia tre proprietà. Le "dimensioni" sono chiamate. Queste proprietà hanno una gamma di valori presumibilmente infinita, e come bonus danno un altro "parametro-tempo". I parametri sono arrivati alla fiera e hanno preso le proprietà x,y,x_size,y_size. Dicono che vogliono fare un guscio nello spazio. E hanno preso colore. Sono tornati e hanno iniziato a vestire le nuove proprietà. Hanno modellato e modellato degli involucri spaziali finché non si sono stancati. Sono cresciuti immensamente, poi sono crollati... Poi si sono colorati e si sono rilassati. Cominciarono a pensare a cosa fare dopo. E poi hanno guardato la casella delle proprietà del tempo. Vediamo di cosa si tratta... L'hanno aperta, l'hanno attaccata a se stessi, ma non hanno calcolato i valori e in un attimo è evaporata nel vuoto. Dopo tutto, il tempo è un parametro a cui bisogna fare molta attenzione...

E i primi dieci non erano seri?

Io, per esempio, non posso leggere senza ridere.

 
Artyom Trishkin:

...

Tutta questa "obiettività" è molto confusa, non sei d'accordo... Bisogna fare attenzione. Nikolai Semko aveva ragione sulla vicinanza tra genio e schizofrenia. È possibile "impazzire". Ci sono cose che è meglio non capire. Alcune porte devono essere sempre chiuse alla nostra Coscienza. Come diceva un film, - "il parassita più pericoloso è un'idea. Una volta nel cervello, è impossibile tirarlo fuori". La matrice di cui parlavo è pericolosa per la Mente. È facile perdersi in esso e perdersi per sempre. Facciamo attenzione.)))

 
La rappresentazione dei sistemi in Matrix dà una nuova prospettiva sulle loro strutture, ma non ho visto alcun accenno a facilitare la creazione di sistemi. Per non parlare di qualsiasi "autosviluppo". È dannatamente interessante guardare i sistemi in questo modo, ma non più di questo. Non vedo alcuno sviluppo personale o anche solo un accenno di esso. Pertanto, lasciamo il divino a Dio. L'autosviluppo dei sistemi non può essere realizzato né con l'approccio OOP standard, né con il mio.
1...4546474849505152535455
Nuovo commento