Interesante visión de la OLP - página 2
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
Qué reacción tan destructiva ante el tema y qué discusión tan destructiva. Dígame un seguidor de la programación procedimental cómo evitar la "espaguetización" en la POO, cómo parsear y si tiene sentido utilizar el "espagueti" de otro.
Al fin y al cabo, lo que resulta es que la POO sirve sobre todo para la legibilidad y la programación en equipo, es decir, para los grandes proyectos. Un Asesor Experto que negocia un símbolo a su gráfico con el control del riesgo máximo del saldo / fondos en la cuenta, bueno, no puede ser llamado un gran proyecto - es suficiente y más rentable en la memoria / velocidad - la programación de procedimiento.
Preguntas:
- desventajas/desventajas de la POO (como imperativo) desde la experiencia personal
- desventajas/desventajas de la PF (como declarativa) a partir de la experiencia personal.
Y una opinión sobre las perspectivas es, por supuesto, interesante, especialmente en la dirección de la computación paralela. No veo que tenga sentido tocar el tema de la cuántica.
Tengo que ver de dónde viene, no entiendo para nada lo del spargeting.
Una buena característica de cualquier código es tener funciones tan cortas como sea posible. Será mejor que tengas más.
Por ejemplo, la mitad de las propiedades OOP son cosas que querríamos separar para la usabilidad - por ejemplo, separar un número de funciones en un grupo y darles sus propias variables que vivirían en su espacio de nombres).
Como estamos trabajando con una "clase" de tipo de almacenamiento, podemos claramente predefinir todas las variables para darles un determinado tipo....
es conveniente crear una API externa. Se puede trabajar con la referencia de la clase (8 bytes) cuando se trabaja - se utiliza muy a menudo.
Ejemplo: Todo tipo de listas de nodos enlazados y demás.
// Aquí escribí sólo las peculiaridades que veo, está claro que no tiene sentido escribir sobre la posibilidad y propiedades de los métodos protegidos y otras cosas.... eso es solo azúcar.
Propiedades de FP es lo que nos gustaría hacer en algún lugar, después de algo, por ejemplo, nos gustaría hacer una nueva función sobre la marcha en la función - dividir la función actual, que utilizaría algunas de las variables actuales de nuestra función. Para pasar su ejecución a otra función - resulta que sólo pasamos la función retrasada, el cálculo que aún no se ha producido - sólo como un trozo de código....
De hecho, esto es muy conveniente.
Esto deja la propiedad de desenrollar el código completo porque de hecho sabemos claramente qué función tenemos - lo que es probable que sea más rápido en el cálculo que OOP. Puedes organizar transferencias bastante inteligentes de cálculos de una función a otra - también la función recuerda completamente el entorno de las variables llamadas de la función pasada - lo cual es muy genial (aunque en realidad es sólo guardar las variables declaradas del ámbito externo). FP, por otro lado, puede establecer la dirección de una función y almacenarla en un array como una clase - aunque no es particularmente útil.
Facilidad para escribir código para acciones retardadas, todo tipo de funciones asíncronas, cálculos paralelos
Permítanme explicar mis preocupaciones basándome en el artículo citado y en el propio concepto de determinismo. ¿Qué es lo que me asusta de la "espaguetización" (la complejidad del propio código y la tarea de encontrar errores de cálculo)? Entonces, ¿en qué hace hincapié el artículo: en los valores "basura" de las variables o en los retornos no deterministas de las funciones?
Construyo/entreno redes neuronales de mi estructura de variables(evolucionan). Y para ellos es muy crítico que la "basura" en valores salga de la nada.
Como en el artículo: pisas el pedal del freno y al pedal le importas un bledo. Está en uso. Y si en la fase inicial de construcción (selección automática de la arquitectura) y entrenamiento de su red neuronal es posible la "basura", ¿cómo se construye/entrena?
¿Cómo evitar al máximo la "basura" (el no determinismo) en la POO?
Permítanme explicar mis preocupaciones basándome en el artículo citado y en el propio concepto de determinismo. ¿Qué es lo que me asusta de la "espaguetización" (la complejidad del propio código y la tarea de encontrar errores de cálculo)? Pues bien, en eso se centra el artículo: en los valores "basura" de las variables o en los retornos no deterministas de las funciones.
Construyo/entreno redes neuronales de mi propia estructura de variable(s). Y para ellos es muy crítico que la "basura" en valores salga de la nada.
Como en el artículo: pisas el pedal del freno y al pedal le importas un bledo. Está en uso. Y si en la fase inicial de construcción (selección automática de la arquitectura) y entrenamiento de su red neuronal es posible la "basura", ¿cómo se construye/entrena?
¿Cómo evitar al máximo la "basura" (el no determinismo) en la POO?
El artículo en general es algo extraño, el hombre claramente se olvidó de especificar el tipo de variable const, como si tuviera js entonces al menos readonly. Después de eso escribe que supuestamente tuvo un error cuando el objeto que no debe cambiar el tamaño (ser una constante) no es de alguna manera una constante ..... y en base a esto hace conclusiones de que hay mucha probabilidad de un error en OOP))
En general, la POO permite controlar las áreas de las variables. La POO está diseñada como una transferencia de variables desde una función, es decir, ya deberíamos tener un tipo por defecto porque lo más probable es que haya pocos. Y si es necesario, esta función puede ampliarse sobre la marcha.
Es decir, en OOP hay más control inicial
Eso es todo, siempre lo sospeché)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23No entiendo quién escribe esos "artículos", retórica vacía, frases generales, mínimo sentido.
" El código en su conjunto era confuso y desordenado - lo que se llama "spaghetti " en el argot " - por culpa de los malos programadores deToyota consideraremos que enOOP el código es confuso.
" Las características de POO incorporadas sólo aumentan la confusión. "- bueno, la lógica, la capacidad de utilizar características añaden confusión al código, con un aumento constante en el número de características de POO (C#) será imposible escribir código simple nunca más. Sí.
"En la mayoría de los lenguajes orientados a objetos, los datos se pasan por referencia, es decir, diferentes partes del programa pueden tratar la misma estructura de datos, y modificarla. Esto convierte el programa en un gran bulto de estado global y contradice la idea original de la POO " - ¿Yprivado,protegido?
"...Si no te gusta esta cita, es porque el no determinismo en general no te lleva a ninguna parte."Bueno, sí, las funciones impredecibles GetMicrosecondCount, MathRand, CoptBuffer, todas las funciones de red y otras deben ser desechadas porque el resultado allí depende del estado externo. Es horrible.
Bien, suficiente, todo está claro aquí.
Ahí tienes, siempre sospechoso)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23La mayoría de los argumentos se los chupan los dedos. Algunos experimentos que "demuestran" la invalidez de la OOP son incorrectos en absoluto. En los lenguajes OOP normales, sum(int a, int b) siempre será limpio, incluso si se escriben tonterías como a += b internamente. De nuevo, si un objeto se asigna en el heap dentro de un método, siempre está protegido, porque sólo el método que lo llamó tiene una referencia a él. Puedes cambiarlo a voluntad. Hay tipos de referencia y significativos. Nadie le impide escribir funciones limpias sin efectos secundarios en los lenguajes OOP. Las funciones matemáticas estándar son así, por ejemplo. Sí, a veces no se puede prescindir de los recursos compartidos, pero hay colecciones útiles a prueba de hilos y mucho más. Al fin y al cabo, cualquier FP puro interactuará inevitablemente con IO, BD, peticiones de red y muchas otras cosas, que es donde los demonios de modificabilidad se abrirán paso.
Artículo raro....
La cantidad tiende a transformarse en calidad.
Cuando hay muchas radios, puede haber incompatibilidad electromagnética y dejarán de funcionar.
Las propiedades de espagueti del código suele ser por la cantidad y por no tener en cuenta todas las propiedades de la envoltura cuando hay muchos usos en diferentes estados.
En las funciones, la presencia de retroalimentación conducirá a lo mismo. La histéresis es una broma)
Entender los problemas, y hacerlos bien ... ))))
// Sólo he descrito las características que puedo ver aquí, obviamente no tiene sentido escribir sobre la posibilidad y propiedades de los métodos protegidos y otras cosas.... eso es solo azúcar.
Propiedades de FP es lo que nos gustaría hacer en algún lugar, después de algo, por ejemplo, nos gustaría componer una nueva función sobre la marcha en una función - compartir la actual, que utilizaría algunas de las variables actuales de nuestra función. Para pasar su ejecución a otra función - resulta que sólo pasamos la función retrasada, el cálculo que aún no se ha producido - sólo como un trozo de código....
De hecho, es muy conveniente.
Bueno, ¿quién impide hacer lo mismo en OOP? ¿Incluso en un lenguaje puramente procedimental? Se pasa un puntero a una función a otra función y se consigue retrasar la ejecución.
En general, la asincronía es un patrón de diseño puro. También se puede escribir código asíncrono en C puro. Sólo hay que hacer un estado-máquina que realice la tarea por partes. Por cierto, lo hice con indicadores en MQL que tardaron mucho en ser calculados. Lo hice para no ralentizar el gráfico y mostrar una bonita barra de estado que cambia su porcentaje de cumplimiento.
Bueno, ¿quién le impide hacer lo mismo en OOP? ¿Incluso en un lenguaje puramente procedimental? Se pasa un puntero a una función a otra función y se consigue retrasar la ejecución.
En general, la asincronía es un patrón de diseño puro. También se puede escribir código asíncrono en C puro. Sólo hay que hacer un estado-máquina que realice la tarea por partes. Por cierto, lo hice con indicadores en MQL que tardaron mucho en ser calculados. Me ayuda a no ralentizar el gráfico y a mostrar una bonita barra de estado que cambia su porcentaje de ejecución.
) También puede utilizar el ensamblador. La cuestión es dónde es más fácil.
Y no me pongas en uno u otro lado.... No soy partidario de una u otra cosa.
Artículo extraño. La POO no se diferencia del estilo procedimental para mal, porque en ella se puede hacer todo en estilo procedimental por defecto, y viceversa sin que se produzca un terrible hinchamiento de código, es decir, la POO es una "superestructura por encima", no un estilo fundamentalmente diferente.
Si el artículo trata realmente de lo funcional y no de lo procedimental (lo cual no es tan obvio si te metes con ello), entonces por qué comparar cosas que tienen usos completamente diferentes.
Topeka starter, ¿escribes tú mismo y ahora hablas de qué? ¿funcional o procedimental?
Al fin y al cabo, lo que resulta es que la POO es sobre todo para la legibilidad y la programación en equipo, es decir, para los grandes proyectos.
No sé cómo utilizar la OOP. Pero sí uso cosas primitivas de ella. Desde el pasado reciente, publicó un código muy simple.
Empezó a escribirlo en FP, cuando aún no entendía lo que eventualmente tendría que mirar.
Acabado a través de los elementos primitivos de la OOP. Probablemente perdí las habilidades de FP, pero aquí OOP parecía mucho más simple y más legible.
El código es muy simple y corto(descripción). Si lo escribes en FP, sería interesante comparar.