DoSomethingToThing (Thing n) versus Thing.DoSomething()

Question

¿Qué factores determinan qué enfoque es más apropiado?

Answer 1

Creo que ambos tienen su lugar.

No debe simplemente usar DoSomethingToThing(Thing n) solo porque piensa que "la programación funcional es buena". Del mismo modo, no debería usar simplemente Thing.DoSomething() porque "la programación orientada a objetos es buena".

Creo que se trata de lo que está tratando de transmitir. Deja de pensar en tu código como una serie de instrucciones y comienza a pensar en ello como un párrafo o una oración de una historia. Piense en qué partes son las más importantes desde el punto de vista de la tarea en cuestión.

Por ejemplo, si la parte de la 'oración' que desea resaltar es el objeto, debe usar el estilo OO.

Ejemplo:

fileHandle.close(); 

mayoría de las veces cuando se está pasando alrededor de identificadores de archivo, lo principal que se está pensando en no perder de vista el archivo que representa.

contraejemplo:

string x = "Hello World"; 
submitHttpRequest(x); 

En este caso, la presentación de la solicitud HTTP es mucho más importante que la cadena que es el cuerpo, por lo submitHttpRequst(x) es preferible x.submitViaHttp()

hace falta decir que estos no son mutuamente exclusivo. Probablemente tenga realmente

networkConnection.submitHttpRequest(x) 

en el que los mezcla ambos. Lo importante es que piense en qué partes se enfatiza y qué se transmitirá al futuro lector del código.

Answer 2

No hay suficiente información aquí. Depende si su lenguaje incluso admite el constructo "Cosa.algo" o equivalente (es decir, es un lenguaje OO). Si es así, es mucho más apropiado porque ese es el paradigma OO (los miembros deben estar asociados con el objeto sobre el que actúan). En un estilo de procedimiento, por supuesto, DoSomethingtoThing() es su única opción ... o ThingDoSomething()

Answer 3

Para estar orientado a objetos, diga, no pregunte: http://www.pragmaticprogrammer.com/articles/tell-dont-ask.

Por lo tanto, Thing.DoSomething() en lugar de DoSomethingToThing (Thing n).

Answer 4

DoSomethingToThing (Cosa n) sería más un enfoque funcional, mientras que Thing.DoSomething() sería más un enfoque orientado a objetos.

Answer 5

Esa es la orientada a objetos frente a la elección de programación procedimental :)

Creo que las ventajas OO bien documentados se aplican a la Thing.DoSomething()

Answer 6

Si usted está tratando con el estado interno de una cosa, Thing.DoSomething() tiene más sentido, porque incluso si cambia la representación interna de Thing, o cómo funciona, el código que habla con él no tiene que cambiar. Si está tratando con una colección de Cosas, o escribe algunos métodos de utilidad, DoSomethingToThing() de estilo de procedimiento puede tener más sentido o ser más directo; pero aún así, por lo general se puede representar como un método en el objeto que representa esa colección: por ejemplo

GetTotalPriceofThings(); 

vs

Cart.getTotal(); 

Realmente depende de la forma orientada a objetos es su código.

Answer 7

esto se ha preguntado Design question: does the Phone dial the PhoneNumber, or does the PhoneNumber dial itself on the Phone?

Answer 8

Aquí hay un par de factores a considerar:

• ¿Se puede modificar o extender la clase Thing. De lo contrario, utilice el anterior
• Puede crearse una instancia de Thing. De lo contrario, utilice el último como método estático
• Si realmente se modifica Thing (es decir, tiene propiedades que cambian), prefiera este último. Si Thing no se modifica, este último es igual de aceptable.
• De lo contrario, como los objetos están destinados a asignarse al objeto del mundo real, elija el método que parece estar más basado en la realidad.

Answer 9

Incluso si usted no está trabajando en un lenguaje orientado a objetos, donde tendría cosa.HacerAlgo(), para la legibilidad del conjunto de su código, que tiene un conjunto de funciones como:

ThingDoSomething() ThingDoAnotherTask() ThingWeDoSomethingElse()

continuación

AnotherThingDoSomething()

y así sucesivamente es mucho mejor.

Todo el código que funciona en "Cosa" está en la única ubicación. Por supuesto, el "DoSomething" y otras tareas deben nombrarse de manera consistente, por lo que tiene un ThingOneRead(), un ThingTwoRead() ... por ahora debería obtener un punto. Cuando vuelvas a trabajar en el código dentro de doce meses, apreciarás tomarte el tiempo para hacer las cosas lógicas.

Answer 10

En general, si "algo" es una acción que la "cosa" naturalmente sabe cómo hacer, entonces debe usar thing.doSomething(). Esa es una buena encapsulación OO, porque de lo contrario DoSomethingToThing (cosa) tendría que acceder a la información interna potencial de "cosa".

Por ejemplo invoice.getTotal()

Si "algo" no es, naturalmente, parte del modelo de dominio "de algo", a continuación, una opción es utilizar un método de ayuda.

Por ejemplo: Logger.log (factura)

Answer 11

Si DoingSomething a un objeto es probable que produzca un resultado diferente en otro escenario, entonces yo le sugeriría oneThing.DoSomethingToThing (anotherThing).

Por ejemplo, es posible que tenga dos cosas de ahorro en su programa para que pueda adoptar un objeto de base de datos. Guardar (cosa) SessionObject.Save (thing) sería más ventajoso que thing.Save() o thing.SaveToDatabase o cosa .SaveToSession().

Casi nunca paso ningún parámetro a una clase, a menos que esté recuperando propiedades públicas.

Answer 12

Para agregar a la respuesta de Aeon, depende de la cosa y lo que quiere hacer con ella. Entonces, si estás escribiendo Thing, y DoSomething altera el estado interno de Thing, entonces el mejor enfoque es Thing.DoSomething. Sin embargo, si la acción hace más que cambiar el estado interno, entonces DoSomething (cosa) tiene más sentido. Por ejemplo:

Collection.Add(Thing) 

es mejor que

Thing.AddSelfToCollection(Collection) 

Y si usted no escribió nada, y no se puede crear una clase derivada, entonces no tienen chocie pero para hacer HacerAlgo (Cosa)

Answer 13

1. Thing.DoSomething es apropiado si cosa es el tema de su sentencia.
   • DoSomethingToThing (Thing n) es apropiado si Thing es el objeto de su oración.
   • ThingA.DoSomethingToThingB (ThingB m) es una combinación inevitable, ya que en todos los idiomas que puedo pensar, las funciones pertenecen a una clase y no son de propiedad mutua. Pero esto tiene sentido porque puedes tener un sujeto y un objeto.

La voz activa es más sencilla que la voz pasiva, por lo que asegúrese de que su oración tiene un sujeto que no es sólo "la computadora". Esto significa que usa el formulario 1 y el formulario 3 con frecuencia, y el formulario 2 rara vez.

Para mayor claridad:

// Form 1: "File handle, close." 
fileHandle.close(); 

// Form 2: "(Computer,) close the file handle." 
close(fileHandle); 

// Form 3: "File handle, write the contents of another file handle." 
fileHandle.writeContentsOf(anotherFileHandle); 

Answer 14

Incluso en la programación orientada a objetos que podría ser útil el uso de una llamada de función en lugar de un método (o para el caso de llamar a un método de un objeto distinto al que llamamos en). Imagine un marco de persistencia de base de datos simple donde le gustaría simplemente llamar a save() en un objeto. En lugar de incluir una instrucción SQL en cada clase que le gustaría guardar, complicando así el código, distribuyendo SQL en todo el código y haciendo que cambiar el motor de almacenamiento sea un PITA, podría crear una interfaz que defina guardar (Class1), guardar (Class2) etc. y su implementación. Entonces estarías llamando a databaseSaver.save (class1) y tendrías todo en un solo lugar.

Answer 15

Estoy de acuerdo con Kevin Conner

También hay que tener en cuenta la persona que llama de cualquiera de las 2 formas. La persona que llama es probablemente un método de algún otro objeto que definitivamente hace algo para su Cosa :)

Answer 16

Estoy de acuerdo con Orion, pero voy a reformular el proceso de decisión.

Tiene un sustantivo y un verbo/un objeto y una acción.

• Si muchos objetos de este tipo utilizarán esta acción, intente hacer que la acción forme parte del objeto.
• De lo contrario, intente agrupar la acción por separado, pero con acciones relacionadas.

Me gustan los ejemplos de archivos/cadenas. Hay muchas operaciones de cadena, como "SendAsHTTPReply", que no sucederá con una cadena promedio, pero sí con cierta configuración. Sin embargo, básicamente siempre cerrará un archivo (con suerte), por lo que tiene sentido poner la acción Cerrar en la interfaz de clase.

Otra forma de pensar en esto es comprar parte de un sistema de entretenimiento. Tiene sentido agrupar un control remoto de TV con un televisor, porque siempre los usa juntos. Pero sería extraño combinar un cable de alimentación para una videograbadora específica con un televisor, ya que muchos clientes nunca lo usarán. La idea clave es ¿con qué frecuencia se usará esta acción en este objeto?