Rappresentazione di un oggetto nella programmazione. - pagina 9

Nuovo commento
 
JRandomTrader #:

In cosa sono scritte le "appendici"?

Nei linguaggi applicativi.

 

Parte 2.

Nella prima parte abbiamo parlato dei costituenti dell'Oggetto, ma in questa parte guarderemo le loro relazioni reciproche. I componenti stessi saranno convenzionalmente chiamati"Proto-blocchi", perché non sono oggetti a pieno titolo, ma rappresentano alcune entità "costruttive" che fanno parte di tutti gli oggetti e sistemi. Lasciate che vi ricordi la loro lista iniziale:

  • Parametro - una rappresentazione nominata e numericamente compressa di un certo insieme strutturale o valore.
  • Un insieme di proprietà - la lista dei parametri inclusi nell'Oggetto.
  • Funzione costruttore- Un algoritmo che riproduce un oggetto sulla base di una lista di parametri.
  • Shape- Combina un tipo di insiemi appartenenti a un Oggetto, che esistono in due o tre dimensioni.
  • Stati-"punti di rottura" significativi nell'esistenza dell'oggetto, valori di parametri a cui l'oggetto passa al cambiamento delle condizioni ambientali o nel processo di esecuzione indipendente di un programma .
  • Eventi - cambiamenti significativi nell'Oggetto stesso o nei suoi dintorni.
  • Processi - varie sequenze di cambiamento di stati dell'oggetto (o degli oggetti), risultanti dalcambiamento delle condizioni dell'ambiente esterno o dall'esecuzione indipendente di un programma.

Oltre al "corpo" parametrico di Form, State, Event e Process, aggiungeremo una funzione handler (chiamiamola semplicemente "handler") il cui compito è quello di "trasferire" valori dal suo proto-blocco all'insieme parametrico dell'Oggetto. Per esempio: un'etichetta ha 5 parametri in una funzione costruttrice e questo insieme è il suo "corpo" parametrico. Supponiamo di aver inventato un nuovo stato e di averlo scritto come diversi valori dei parametri iniziali, e nel momento in cui abbiamo bisogno di spostare l'etichetta in un nuovo stato, dobbiamo chiamare una funzione che li trasferisca dalla struttura parametrica dello Stato al "corpo" parametrico dell'etichetta. In parole povere, questo gestore inizializza i parametri Object con i valori del suo proto-blocco. Per Process e Form, un principio simile funziona con il trasferimento del valore al corpo dell'oggetto, ma l'implementazione è diversa. Ma per elaborareun Evento non abbiamo bisogno di trasferire i valori - abbiamo bisogno di controllarli, quindi una dichiarazione di condizione andrà bene come gestore.

Ci sono molti gestori nel mio concetto e meritano una classificazione separata, ma questo complicherebbe troppo la presentazione e quindi li toccherò superficialmente, dividendoli approssimativamente in diversi gruppi:

  • "Trasportatori" - Gestori che trasferiscono valori da un proto-blocco a un Oggetto (per esempio da uno Stato, Forma, Processo ai parametri di destinazione di un Oggetto).
  • "Bound" - Gestori che cambiano i valori dei parametri vincolati (dipendenti) nel sistema (ad esempio - una traiettoria parabolica di movimento implica un cambiamento sincrono dei valori delle coordinate e questo è implementato da un gestore x,y vincolato). Le dipendenze nelle relazioni dei parametri possono essere espresse da formule, o definite da condizioni incluse nel corpo del gestore.
  • "Assemblatori" - Gestori che "costruiscono" nuovi proto-blocchi "spacchettandoli" dal corpo parametrico dell'oggetto e salvandoli con i valori attuali importanti, o "clonando" altri proto-blocchi, parzialmente o completamente, e facendo le modifiche necessarie alle copie. In questo processo, strutture tabulari o gerarchiche sono formate dai proto-blocchi, che sono disposti all'interno di speciali "moduli" in cui sono memorizzati.
  • "Modular" - Gestori di diversi tipi di moduli in cui sono memorizzati i proto-blocchi. *(I "moduli" dei proto-blocchi saranno descritti più avanti).

Questa non è affatto una lista completa e i nomi dei gestori sono arbitrari, ma la divisione della loro specializzazione, in generale, si presenta così.


La prossima aggiunta al concetto dopo le funzioni di gestione sarebbe"Moduli". È logico assumere che i proto-blocchi creati devono essere immagazzinati e organizzati da qualche parte, ed è anche facile intuire che sarebbe ottimale separare l'immagazzinamento dei proto-blocchi di tipi diversi per evitare confusione e permettere ai gestori di "navigare" facilmente attraverso i contenuti crescenti dell'oggetto. Quindi, creiamo dei "magazzini" o, come è ancora più bello, dei"Moduli" di proto-blocchi. Per gli Stati, i Processi, gli Eventi e le Forme dell'oggetto saranno creati i propri moduli in cui saranno i proto-blocchi:

  1. Conservato in modo ordinato.
  2. Moltiplicare.
  3. Recupera dai gestori secondo necessità.
  4. Collegamento a proto-blocchi in altri moduli.

Il quarto punto - di "collegare" proto-blocchi di tipo diverso si basa precisamente sulla loro "inclusione strutturale" l'uno nell'altro, di cui ho parlato nella prima parte - Process includes States,... L'evento include Stato,... Un processo include Eventi,... Uno Stato può includere una Forma, e così via... Per esempio, se costruiamo il nostro modello di eventi in un modulo separato, allora la sua gerarchia di condizioni conterrà Eventi che sono memorizzati nel modulo 'Event', e questi Eventi a loro volta contengono Stati che sono memorizzati nel modulo States. In questo modo, non solo creiamo un ordine efficiente di immagazzinamento e utilizzo dei proto-blocchi, ma implementiamo anche la loro "inclusività strutturale" semplicemente connettendoli l'uno all'altro tramite collegamenti tra i moduli. Cambiando arbitrariamente o ponderatamente i collegamenti, possiamo creare nuovi proto-blocchi da quelli esistenti, così come cambiare l'evento o il modello logico nel "comportamento" dell'oggetto. Cambiando le relazioni a livello del modello logico (che a sua volta sarà memorizzato nel suo modulo) si può cambiare completamente il programma, e così facendo, non dobbiamo riscrivere nulla nel codice. È qui che vedo i vantaggi del partizionamento modulare proto-blocco.

Questo è tutto per ora. In seguito, passerò ai modelli di eventi e logici e considererò come sono costruiti.

Fate domande se qualcosa non è chiaro o interessante.


 
A cosa serve il concetto?
 
Aliaksandr Hryshyn #:
A cosa serve il concetto?

Questo concetto è un tentativo di passare al prossimo livello di programmazione, che a mio parere sarà "costruire" (piuttosto che scrivere) sistemi funzionali dal computer stesso, piuttosto che dagli umani. Il software sarà in grado di creare programmi.

Ora c'è una rete neurale addestrata sul codice githab, ma non è affatto quello che intendo.

 
C'è una cosa che non riesco a capire, ho impostato dei valori per la linea di tendenza ObjectCreate(...), la linea non appare sullo schermo. Per favore aiutatemi, come visualizzare un oggetto?
 
Реter Konow #:

Questo concetto è un tentativo di passare al prossimo livello di programmazione, che a mio parere sarà "costruire" (piuttosto che scrivere) sistemi funzionali dal computer stesso, piuttosto che dagli umani. Il software sarà in grado di creare programmi.

Ora c'è una rete neurale addestrata sul codice githab, ma non è affatto quello che intendo.

Ciao Peter.
Oltre a OOP c'è DDD(Domain-driven design)
Solo per tenervi informati.

 
Nikolai Semko #:

Ciao Peter.
Oltre all'OOP, c'è il DDD(Domain-driven design)
Solo perché tu lo sappia.

Stai confondendo il caldo e il morbido.

 
Andrei Trukhanovich #:

Stai confondendo il caldo e il morbido.

Anche tu stai confondendo il caldo con il freddo
 
Vladimir Baskakov #:

Dov'è il segnale, fratello?

 
Andrei Trukhanovich #:

Dov'è il segnale, fratello?

Dov'è il tuo?
1234567891011121314151617
Nuovo commento
Motivazione: