delphi oop class-helpers

delphi - ¿Deberían utilizarse Class Helpers en el desarrollo de un nuevo código?



oop class-helpers (10)

Antes de aceptar a los ayudantes de clase como una nueva herramienta para el código de fantasía, creo que debes entender las limitaciones que incluye. Solo es posible proporcionar un ayudante de clase para una clase. Entonces, ¿qué pasará si proporcionas ayudantes de clase para tus clases, y tus clases derivan de una clase común que otros han proporcionado como ayudantes de clase?

CodeGear presenta los ayudantes de clase como ''un hack'' para evitar romper cosas, no como una característica de diseño interesante. Cuando diseñe el código, diseñe sin ayudantes de clase. Sé que puedes. Cuando se trata de un código existente que puede controlar, use la refactorización. Cuando no haya otro camino, busque ayudantes de clase.

Esa es mi opinión de cualquier manera ...

Delphi 8 introdujo Class Helpers a los efectos de mapear el VCL / RTL a la jerarquía de objetos .NET. Permiten la inyección de métodos en una clase existente sin anular la clase o modificar el original. Las versiones posteriores de Delphi encontraron que los ayudantes de clase mejoraron y fueron portados a Win32.

En la ayuda, dice "no deben verse como una herramienta de diseño para usar al desarrollar un código nuevo".

Los Ayudantes de Clase violan la POO tradicional, pero no creo que eso los haga ser malos. ¿Está justificada esta advertencia?

¿Deberían usarse ayudantes de clase al desarrollar un nuevo código?

¿Los usas cuando desarrollas un nuevo código?

¿Por qué o por qué no?

Los comentarios de Per Malcolm : Nuevo código significa el desarrollo de aplicaciones diarias, donde tienes algunas bibliotecas de terceros, algunos códigos existentes y luego el código que estás escribiendo.


Depende de lo que quiere decir con "código nuevo".

No son realmente relevantes para las clases que está desarrollando recientemente, por lo que en ese caso, no, probablemente no deberían usarse.

Pero incluso en un nuevo proyecto, es posible que deba modificar una clase existente que no puede cambiar de otras maneras (clase vcl, clase de terceros, etc.). En este caso, claro, yo diría que adelante.

No son malvados en sí mismos. Como la mayoría de las otras cosas, solo necesita comprender cómo funcionan y usarlas en un contexto apropiado.


Encontré este artículo muy interesante. Se trata de C ++, pero las ideas principales son independientes del lenguaje. La idea principal es que las rutinas globales a veces son preferibles a los métodos, incluso en un entorno OOP. Desde este punto de vista, hay menos necesidad de ayudantes de clase.


Estos suenan como los métodos de extensión C #. Diría que si bien los métodos de extensión como estos son útiles cuando no tiene la capacidad de modificar una clase que necesita ampliar con funcionalidad, son una forma pobre de diseñar su propio código. Al diseñar su propio código, desea que todas las funcionalidades se ubiquen en el mismo archivo de código tanto como sea posible en lugar de extenderse entre las diferentes clases. Yo diría que los use para lo que estaban destinados, básicamente como decoradores para agregar nuevas funcionalidades a clases cerradas, y no los use para diseñar su propio código.


Estoy de acuerdo con Vegar en esto: ayudantes de clase como herramienta de emergencia. Cuando sabes que son la única forma de hacer las cosas en el tiempo previsto. Más tarde, si hay tiempo para hacerlo, elimínelos.

Una vez olvidé una parametrización, y si los ayudantes de la clase no existieran en Delphi 2006, costaría UNA GRAN CANTIDAD DE TIEMPO ... Con los ayudantes de la clase, tardaron 6 horas en hacer que thigs funcionen bien. PERO, era una situación de emergencia: los ayudantes de clase son una característica oscura del lenguaje y crean dificultades a los nuevos desarrolladores para seguir el flujo del programa.


Me encuentro usándolos más y más como una construcción de diseño.

Situaciones en las que los uso:

  • En una configuración de cliente / servidor, amplío las clases base compartidas con ayudantes de clase para proporcionar funcionalidad solo de servidor o cliente.
  • Para complementar las clases de VCL / RTL (y otro código de terceros) con útiles funciones de herramientas.
  • Para evitar las diferencias cuando las clases no comparten el mismo árbol de herencia (el uso de ayudantes permite tener propiedades genéricas de Cuenta y Elementos, por ejemplo).

De hecho, deseo que Delphi acepte múltiples ayudantes para la misma clase base; incluso he presentado una solicitud para esto si recuerdo correctamente.


Lo siento, no puedo evitar ser el Capitán Obvio por un momento: si las propias personas internas de Delphi afirman que "no deberían ser vistas como una herramienta de diseño para usarlas al desarrollar un nuevo código", entonces, por definición, no deberían usarse. Están ahí para extender el VCL solo para sus propios fines. ¿Quién más te va a dar una razón mejor que la gente que lo escribió?


Quizás un buen enfoque que puedes usar es (como lo uso):

  1. Siempre dé preferencia a la herencia sobre los ayudantes de la clase, úsela solo cuando la herencia no sea una opción.
  2. Da preferencia a los ayudantes de clase sobre los métodos globales desnudos .
  3. Si vas a necesitar la funcionalidad de Extendend en más de una Unidad, prueba algo más ( como envoltorios de clase ).

Los métodos .Net Extensions son demasiado similares y fueron creados y soportados por el mismo motivo: hacer una extensión de las clases base (en lugar de una actualización que en Delphi.Net no era una opción para tratar de hacer que el código nativo de Delphi fuera bueno) de "compatible" con el código .Net - En mi humilde opinión esto era demasiado ambicioso)

De todos modos, los ayudantes de Delphi Class siguen siendo una gran herramienta en algunas situaciones.


Los uso mucho. Utilizo objetos remotos y los objetos que hay allí son creados por el motor de RO para que no pueda agregarlos sin descender de ellos y luego otros trozos de desorden. Los Ayudantes de clase significan que puedo tratarlos como cualquier otro objeto. y aunque una clase solo puede tener un ayudante, puede descender las clases auxiliares para obtener el comportamiento heredado.