Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿En qué consisten los "apéndices"?
En los lenguajes de aplicación.
Parte 2.
En la primera parte hemos hablado de los componentes del Objeto, pero en esta parte consideraremos sus relaciones entre sí. Los propios componentes se denominarán convencionalmente"Protobloques", porque no son objetos completos, sino que representan algunas entidades "de construcción" que forman parte de todos los objetos y sistemas. Permítanme recordarles su lista inicial:
Además del "cuerpo" paramétrico de Forma, Estado, Evento y Proceso, añadiremos una función manejadora (llamémosla simplemente "manejadora") cuya tarea es "transferir" valores desde su protobloque al conjunto paramétrico del Objeto. Por ejemplo: una etiqueta tiene 5 parámetros en una función constructora y este conjunto es su "cuerpo" paramétrico. Supongamos que hemos inventado un nuevo estado y lo hemos escrito como diferentes valores de los parámetros iniciales, y en el momento en que necesitamos mover la Etiqueta a un nuevo estado, necesitamos llamar a una función que los transfiera desde la estructura paramétrica del Estado al "cuerpo" paramétrico de la Etiqueta. En pocas palabras, este manejador inicializa los parámetros del objeto con los valores de su proto-bloque. En el caso de Process y Form, funciona un principio similar con la transferencia de valores al cuerpo del objeto, pero la implementación es diferente. Pero para procesarun Evento no necesitamos transferir los valores - necesitamos comprobarlos, así que una declaración de condición servirá como manejador.
Hay muchos manejadores en mi concepto y merecen una clasificación separada, pero complicaría demasiado la presentación y por lo tanto los tocaré superficialmente, dividiéndolos a grandes rasgos en varios grupos:
Esta no es en absoluto una lista completa y los nombres de los tipos de manipuladores son arbitrarios, pero la división de su especialización, en general, tiene este aspecto.
La siguiente adición al concepto, después de las funciones de manejo, sería"Módulos". Es lógico suponer que los proto-bloques creados deben ser almacenados y organizados en algún lugar, y también es fácil adivinar, que sería óptimo separar el almacenamiento de los proto-bloques de diferentes tipos para evitar confusiones y permitir a los manipuladores "navegar" fácilmente a través de los contenidos crecientes del Objeto. De ahí que creemos "almacenes" o, como es más bonito,"Módulos" de protobloques. Para los Estados, Procesos, Eventos y Formas del objeto se crearán sus propios módulos en los que estarán los proto-bloques:
El cuarto punto -de "enlazar" protobloques de diferentes tipos- se basa precisamente en su "inclusión estructural" entre sí, de la que hablé en la primera parte -El proceso incluye a los Estados,... El evento incluye el Estado,... Un proceso incluye Eventos,... Un Estado puede incluir un Formulario, y así sucesivamente... Por ejemplo, si construimos un modelo de eventos en un módulo separado, entonces su jerarquía de condiciones contendrá Eventos que se almacenan en el módulo 'Event', y estos Eventos a su vez contienen Estados que se almacenan en el módulo States. De este modo, no sólo creamos una forma eficiente de almacenar y utilizar los protobloques, sino que también implementamos su "inclusividad estructural" simplemente conectándolos entre sí con enlaces entre los módulos. Cambiando arbitraria o cuidadosamente los enlaces, podemos crear nuevos protobloques a partir de los existentes, así como cambiar el modelo de eventos o de lógica en el "comportamiento" del Objeto. Cambiando las relaciones a nivel del modelo lógico (que a su vez se almacenará en su módulo) podemos cambiar completamente el programa, y al hacerlo, no tenemos que reescribir nada en el código. Aquí es donde veo las ventajas de la partición modular de protobloques.
Eso es todo por ahora. A continuación, pasaré a los modelos de eventos y lógicos y consideraré cómo se construyen.
Pregunte si algo no está claro o es interesante.
¿Para qué sirve el concepto?
Este concepto es un intento de pasar al siguiente nivel de programación, que en mi opinión será "construir" (en lugar de escribir) sistemas funcionales por el propio ordenador, en lugar de por los humanos. El software podrá crear programas.
Ahora hay una red neuronal entrenada en código githab, pero no me refiero a eso en absoluto.
Este concepto es un intento de pasar al siguiente nivel de programación, que en mi opinión será "construir" (en lugar de escribir) sistemas funcionales por el propio ordenador, en lugar de por los humanos. El software podrá crear programas.
Ahora hay una red neuronal entrenada en código githab, pero no me refiero a eso en absoluto.
Hola Peter.
Además de la POO también existe el DDD(diseño dirigido por el dominio)
Sólo para mantenerte informado.
Hola Peter.
Además de la POO, existe el DDD(Domain-driven design)
Para que lo sepas.
Estás confundiendo lo cálido y lo suave.
Estás confundiendo lo cálido y lo suave.
¿Dónde está la señal, hermano?
¿Dónde está la señal, hermano?