Mi enfoque. El núcleo es el motor. - página 137
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
Peter, realmente has entendido mal algo sobre la aplicación de la POO.
Nikolai, ¿estás construyendo HIERRA o creando mecanismos de dibujo?
Si construyes HIERRA (no te importa el dibujo), entonces está claro por qué necesitas OOP en todas partes.
Si estás creando un mecanismo de dibujo que funciona sobre la base de UNA clase, entonces no necesitas la propia clase.
Clase, - de la palabra Clasificación. La clasificación es una división por atributos. La clase es un derivado de la clasificación. Si hay una Clase, entonces no hay Clasificación.
Así que la clase, en ese caso, es una mierda abstracta. No tiene sentido.
...
Uno tiene la impresión de que la propia OOP se adelanta al mecanismo al que debe servir. Es decir, el mecanismo debe esforzarse por la integridad, por lo tanto por el menor número de sus bloques. Pero la POO obliga a estos bloques a multiplicarse por cualquier motivo. Como resultado, la estructura de los mecanismos está destrozada y no funcionan bien. Y se desarrollan aún peor.
...
Bueno, tal vez deberías estudiar un poco de OOP en lugar de fantasear con ello. Ni siquiera debes fantasear, sino delirar.
Nikolai, ¿se te ha ocurrido alguna vez que tu amor por la OOP no se justifica por casi nada más que por razones abstractas?
Digamos que, si estuvieras creando mecanismos gigantescos con esta OOP, estaría claro por qué la necesitas tanto. Usted justificaría específicamente por qué necesita la OOP. Pero, usted crea mecanismos relativamente pequeños. No hay suficiente código para sacar conclusiones sobre las desventajas y ventajas de uno u otro enfoque. Pero de todos modos sigues hablando de OOP. Mientras que la POO es sólo una herramienta, y no tiene sentido por sí misma. Es decir, si no hay ningún mecanismo que hacer, la OOP no es necesaria. Pero si hay un mecanismo, debería ser lo suficientemente serio como para requerir OOP mientras se crea.
La mayoría de los que defienden la OOP no hacen nada serio. Sólo hacen cosas pequeñas. Sin embargo, su creencia en la POO es inquebrantable. Otros que hacen mecanismos mucho más serios son mucho menos propensos a gritar sobre la grandeza de la POO. Algunos incluso se manifiestan con críticas (ha habido un par de veces).
Por lo tanto, su argumento debe estar respaldado por la práctica, no sólo por la teoría. Yo, por ejemplo, puedo discutir sobre las ventajas de la POO en el desarrollo de la interfaz gráfica de usuario con Anatoly, porque podemos comparar las soluciones y sus matices en la práctica. Pero, contigo, no puedo desplegar mi argumento porque no lo entenderás. Lo harás, pero no lo entenderás (sin ánimo de ofender). Anatoly, por el contrario, puede entenderlo muy bien. La diferencia de experiencia en la creación de mecanismos globales es el principal motivo de malentendidos.
SZY. Como profesional te diré lo siguiente: el enfoque debe ser tal que maximice el potencial de los cerebros de un programador en particular. Yo mismo he encontrado un enfoque de este tipo.
Las fantasías sobre la OOP son cada vez más salvajes...
La seriedad del trabajo se determina por el resultado, no por el número de años invertidos.
Por desgracia, no es una tontería.
Dibujar en el lienzo no requiere una clase envolvente. Una lista de funciones es suficiente. No necesitas ningún derecho de acceso al método para dibujar. Y tú lo sabes. Pero usted niega este hecho. Estás negando lo evidente.
¡Oh! Sí. Para comer un plátano, hay que pelar la piel. Pero si una vaca tiene cuernos, entonces todos los que tienen cuernos son una vaca.
Bueno, no hay mucha gente así por aquí. Probablemente yo sea uno de ellos. Aunque, no es para enseñarte. Sólo para escuchar una respuesta sensata. ¿Por qué, al dibujar, te refieres a las funciones de la clase a través de objetos, si sólo utilizas UNA clase?
Debido a que las funciones de dibujo en el lienzo sólo se refieren a dibujar en el lienzo y nada más, por lo que no hay razón para mantenerlos en un recipiente separado, es por eso que se recogen en una clase. Pero de todos modos no lo entenderías.
Nikolai, ¿estás construyendo HIERRA o creando mecanismos de dibujo?
Si construyes HIERRA (no te importa el dibujo), entonces está claro por qué necesitas OOP en todas partes.
Si estás creando un mecanismo de dibujo que funciona sobre la base de UNA clase, entonces no necesitas la propia clase.
Clase, - de la palabra Clasificación. La clasificación es una división por atributos. La clase es un derivado de la clasificación. Si hay una Clase, entonces no hay Clasificación.
Así que la clase, en ese caso, es una mierda abstracta. No tiene sentido.
¿Qué tiene que ver la jerarquía con esto? La programación orientada a objetos hace un amplio uso de la herencia... ...y otro montón de fantasía desenfrenada...
...y la guinda del pastel:
Tuve un proyecto similar con otro software bastante caro, y también implementé la idea utilizando soluciones alternativas (para no comprar módulos adicionales).
Tuve un proyecto similar en otro software bastante caro, también implementé la idea a través de workarounds (para no comprar módulos adicionales), funcionó, pero con algunos clientes terminó en un punto muerto y se perdió el tiempo
Pero era una esfera completamente diferente, y era fácil encontrar clientes