¿Es un olor de código si está creando un objeto con frecuencia solo para llamar a un método?

Lo consideraría un olor a arquitectura, ya que UpdateData probablemente debería pertenecer a una clase de 'servicio'.

Donde los datos son una manzana. Donde AppleAdapter es servicio / clase de inteligencia de negocios. Donde AppleService es una referencia Singleton a un AppleAdapter que existe fuera del método actual.

private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
    get
    {
        if (_appleService == null)
        {
            lock (_appleServiceLock)
            {
                if (_appleService == null)
                    _appleService = new AppleAdapter();
            }
        }
        return _appleService;
    }
}

public SomeAppleRelatedMethod(Apple apple)
{
    AppleService.UpdateData(apple);
}

No creo que lo que esté haciendo esté necesariamente mal, pero si SomeDataAdapter realmente representa algún tipo de servicio comercial sin estado, entonces un singleton sería la mejor práctica para ello. ¡Espero que ayude! El ejemplo proporcionado es una forma elegante de asegurar que no haya contención del _appleService si resulta que es nulo y se accede al mismo tiempo por dos o más subprocesos.

¿Sabes qué? Si SomeDataAdapter es un IDbDataAdapter de ADO (que es casi seguro que lo es), ¡ignora esta respuesta completa!

: P

No tengo permiso para agregar un comentario a la pregunta original, pero si puedes especificar dónde existe este código.

Si este código representa una implementación personalizada de un IDbDataAdapter, y UpdateData está creando una IDbConnection, IDbCommand, y conectándolo todo entre bastidores, entonces no lo consideraría un olor porque ahora estamos hablando de flujos y otras cosas que deben eliminarse cuando hayamos terminado de usarlos.

Creo que este problema va incluso más allá de eso. Incluso si lo refactorizas en un método estático, entonces obtienes un código donde llamas método estático único en todo el lugar. Que en mi opinión es el olor del código en sí mismo. Podría indicar que le falta alguna abstracción importante. Tal vez desee crear un código que haga un poco de procesamiento previo y posterior, mientras que le permite cambiar lo que sucede en el medio. Ese procesamiento previo y posterior contendrá las llamadas comunes, mientras que el intermedio dependerá de la implementación concreta.

Tipo de. Por lo general, significa que usted quiere pasar una función y el idioma que elija no lo permitirá. Es un poco torpe y poco elegante, pero si estás atrapado en un idioma sin funciones de primera clase, no hay mucho que puedas hacer.

Si ninguno de esos objetos se pasa como argumentos a otras funciones, podría convertirlos en métodos estáticos y nada cambiaría.

Si mantener el estado hace que una clase dada sea más utilitaria, funcional ... reutilizable, entonces no. Por alguna razón, el patrón de diseño de comando viene a la mente; esa razón ciertamente no es el deseo de que Robert Harvey se ahogue.

Define "frecuentemente". ¿Con qué frecuencia () creas una instancia del objeto? Mucho - probablemente no?

Es probable que haya problemas más grandes de los que preocuparse en su sistema. Estar en estado estático comunicará más claramente al programador que el estado interno del objeto no está cambiando, excelente.

Sin embargo, si se está desordenando el estado, y tienes que empezar a hacer otras cosas estáticas para que la primera cosa sea estática, debes preguntar qué partes deben ser estáticas y cuáles no.

Sí es un olor a código, solo uno pequeño.

Haz que sea un método estático y sigue adelante. No hay nada malo con los métodos estáticos. Una vez que emerge un patrón de uso, entonces puede preocuparse por abstraer el patrón.

El olor aquí es que este es un código de procedimiento envuelto (mínimamente) en objetos.

Debe haber una razón por la que desea realizar esa operación en la tabla de datos, pero en lugar de modelar esa operación con otras operaciones relacionadas que comparten alguna semántica (es decir, tiene un significado común), el autor acaba de realizar un nuevo procedimiento dentro de una nueva clase & lo llamó.

En un lenguaje funcional, así es como harías las cosas;) pero en el paradigma OO, querrías modelar alguna abstracción que incluyera esa operación. Luego, utilizaría técnicas de OO para desarrollar ese modelo y proporcionar un conjunto de operaciones relacionadas que preserven algunas semánticas.

El olor principal aquí es que el autor está usando clases, probablemente porque el compilador lo requiere, sin organizar las operaciones en un modelo conceptual.

Por cierto, tenga cuidado cuando vea que se está modelando el programa en lugar del espacio de problemas . Es una señal de que el diseño podría beneficiarse de una mayor reflexión. En otras palabras, tenga cuidado con las clases, que son "xAdaptor" y "xHandler" y "xUtility", y generalmente están vinculadas a un modelo de dominio anémico . Significa que alguien simplemente está empaquetando el código por conveniencia, en lugar de modelar realmente los conceptos que desea implementar.