Gastos generales de la OLP - página 6
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
pero no funciona :-)
Te lo digo - intenta hacerlo, es un montón de código feroz. La clase instanciable "CFoo: public InterfaceCFoo" debe contener el campo InterfaceCFoo *privateContext (hacer una relación 1:1), crearlo y eliminarlo vía factory, delegar todos los métodos y traducir las referencias CFoo* this<->privateContext aquí y allá. Se trata de "poner el sol a mano", es decir, sustituir la herencia por la delegación, y en el acto.
Crear a través de la fábrica y eliminar de la forma habitual. La necesidad de delegar viene determinada por la forma en que se supone que se utiliza el contenido de la biblioteca: si ésta proporciona clases que hacen el trabajo por sí mismas, entonces no es necesario delegar nada, basta con llamar a los métodos de la interfaz.
Por cierto, en Android/Java hay una cosa similar con las clases del núcleo - debido a la falta de herencia múltiple uno tiene que insertar un delegado en el objeto y hacer métodos envolventes para sus métodos. C'est la vie.
Te lo digo: pruébalo, es un montón de código feroz. La clase instanciable "CFoo: public InterfaceCFoo" debe contener el campo InterfaceCFoo *privateContext (hacer una relación 1:1), crearlo y eliminarlo vía factory, delegar todos los métodos y al mismo tiempo traducir las referencias CFoo* this<->privateContext aquí y allá. Se trata de "poner el sol a mano", es decir, sustituir la herencia por la delegación, y en el acto.
Y el lenguaje, una persona sobria no puede entender lo que estamos hablando sin medio litro. :) Y todo este rollo de la POO y toda esta alfabetización china está hecha para - hacer un simple intercambio de datos, que se realiza trivialmente en el nivel procedimental...
La POO en sí misma no tiene la culpa de la existencia de codificadores de POO viciosos. No hay nada malo con la POO en general, estás completamente equivocado en tu opinión sobre la POO.
La POO en sí misma no tiene la culpa de la existencia de codificadores de POO viciosos. No hay nada malo con la POO en general, estás completamente equivocado en tu opinión sobre la POO.
No conoces su historia.
Repetidas prohibiciones por sabotaje directo. Así que no reaccione ante su ignorancia beligerante.
En general, no hay nada malo en la POO; estás completamente equivocado en tu opinión sobre la POO.
Te daré algunas citas críticas famosas de la wiki sobre OOP de gente, que por alguna razón no se llama ignorante:
Como liberación, citaré algunas citas críticas famosas de la wiki sobre la OOP de gente, que por alguna razón no se llama ignorante:
Y los tres: Stepanov nacido en 1950, Wirth en 1934 y el también antiguo Killea (su libro se publicó en 1998) tendrán mucha vergüenza de repetirlo en 2017.
Lo que dijeron fue hace tanto tiempo que ya da vergüenza recordarlo. Los compiladores de C++ eran al menos 2 órdenes de magnitud más tontos y más primitivos en las optimizaciones. De hecho, allí no había ni rastro de optimización. Por aquel entonces (a principios de los noventa), yo mismo escribía mucho en ensamblador y pensaba lo mismo: "C/C++ es lento".
No me corresponde a mí realizar enlaces en forma de citas arrancadas. Además, ya has conseguido demostrar tu extrema torpeza y tu agresiva ignorancia en este hilo.
Renat Fatkhullin:
Todo lo más ya has conseguido en este hilo mostrar tu extrema torpeza e ignorancia agresiva.
Resumamos. Esta es mi principal hipótesis sobre la OOP: "La POO sólo tiene sentido como una envoltura de texto conveniente o cuando se utiliza mínimamente durante la inicialización en tiempo de ejecución..." en el post #10.
Y aquí hay una opinión razonada de un experto independiente con una opinión similar y una prueba detallada a nivel de código.
http://rainman-rocks.livejournal.com/122876.html
"La conclusión final de todo esto es la siguiente:
La principal razón de la eficacia de la programación orientada a objetos es que contiene los medios para proporcionar modularidad y declaratividad. La modularidad y la declaratividad son las herramientas que aumentan la eficacia del desarrollo, es decir, las "balas de plata". Es en esto en lo que hay que fijarse a la hora de elegir una metodología. La OOP por sí sola no debería ser el objetivo".
En resumen. Esta es mi hipótesis básica sobre la OOP: "La POO sólo tiene sentido como una envoltura de texto conveniente o cuando se utiliza mínimamente en la inicialización en tiempo de ejecución..." en el post #10.
Y aquí hay una opinión razonada de un experto independiente con una opinión similar y una prueba detallada a nivel de código.
http://rainman-rocks.livejournal.com/122876.html
"La conclusión final de todo esto es la siguiente:
La principal razón de la eficacia de la programación orientada a objetos es que contiene los medios para proporcionar modularidad y declaratividad. La modularidad y la declaratividad son las herramientas que aumentan la eficacia del desarrollo, es decir, las "balas de plata". Es en esto en lo que hay que fijarse a la hora de elegir una metodología. La OOP en sí misma no debería ser el objetivo".
Muestre sus proyectos implementados personalmente para que su opinión sea mínimamente aceptada. Ni siquiera se entiende el enlace citado: es una oda a la POO, incluida la salida.
Todo el software está escrito prácticamente en más de un 90% en OOP (no digan tonterías sobre los controladores). De hecho, es imposible escribir y luego mantener un gran proyecto sin OOP. Y no se aceptan palabras de "sólo un envoltorio" cuando se trata de negocios. El desarrollo de software es desde hace mucho tiempo un negocio bien establecido y probado.
Los que se quejan de la POO sin entenderla no saben lo que hacen los compiladores modernos de C++. A menudo no queda nada de OOP en el código final. Me refiero a C++, por supuesto.
Muestre sus proyectos realizados personalmente para que su opinión sea mínimamente aceptada. Ni siquiera se entiende el enlace citado, es sólo una oda a la POO, incluida la conclusión.
Permítanme darles una cita más sobre la idea principal de este artículo para que no haya dudas de lo que dice:
"Así, la POO, aunque pretendía sustituir a la programación estructurada-procedimental, acabó volviendo casi a lo mismo, pero sólo en envoltorios de fantasía. Surge una pregunta: ¿tenía algún sentido la maniobra?".
Lo siento, pero no entiendo la lógica y la causalidad: por qué necesitamos proyectos realizados para que la opinión de uno sea tenida en cuenta mínimamente. Normalmente, en una discusión civilizada, basta con el razonamiento y la validez razonable de la propia opinión presentada.
De lo contrario, llegamos a la absurda conclusión de que si una persona ha ejecutado un proyecto, todas sus afirmaciones posteriores deben ser aceptadas inicialmente por todos, aunque en realidad puede que no estén todas bien razonadas o incluso que contradigan la opinión de otros profesionales que también han ejecutado proyectos.
De nuevo, no es muy modesto presumir de algo, pues es malo para el karma.
Es decir, no hay proyectos, por lo tanto no hay experiencia.
Al mismo tiempo, no se olvida de la experiencia, tratando de sacar los dichos más antiguos de personas que alguna vez fueron experimentadas(en términos de su tiempo). Como no tienes experiencia propia, no comprendes que los enunciados sacados no funcionaron hace tiempo. No funcionaron y sólo fueron delirios propios de aquella época. Estos delirios ya son embarazosos de recordar.
Además, no entiendes realmente la esencia de lo que está escrito en los enlaces citados. Usted arrebata las palabras y las malinterpreta, aunque dice "la POO es mejor que las muletas (y las muletas son un intento de emular la POO sin la POO) y debe ser utilizada".