¿Qué haría si su cliente le solicitara que no usara programación orientada a objetos?

Estoy escribiendo un programa para simular la actividad de las hormigas en una cuadrícula (PDF). La hormiga puede moverse, recoger cosas y dejarlas caer.

El problema es que la acción de las hormigas y las posiciones de cada hormiga pueden rastrearse fácilmente por los atributos de clase (y podemos crear fácilmente muchas instancias de tales hormigas) mi cliente dijo que dado que tiene experiencia en programación funcional, le gustaría que simulación a realizar mediante programación funcional.

Para ser claros, las palabras originales del cliente son "sin clase" solamente, pero no "programación funcional". Así que supongo que no se refiere a la programación funcional y puedo hacerlo imperativamente. Además, no tengo experiencia previa en programación funcional.

Sin embargo, creo que es beneficioso enfocarse en esta pregunta que se refiere particularmente a un requisito de programación funcional que simplemente "hacerlo imperativamente".

¿Cómo manejarías esta situación? ¿Tratarías de persuadir a tu cliente de que usar una programación orientada a objetos es mucho más limpio, tratar de seguir lo que necesita y darle un código de baja calidad, o hacer algo más?

El código orientado a objetos no es por definición más limpio y, por el contrario, el código que no es OO no es, por definición, malo. Si bien parece haber una asignación orientada a objetos bastante obvia para este problema en particular, le sugiero que pruebe el enfoque de programación funcional de todos modos. Dale tu mejor oportunidad, intenta resolver el problema con el mejor estilo de programación funcional que puedas reunir, y tal vez aprendas algo que no esperabas.

Usted menciona que el cliente solía programar en un lenguaje funcional, tal vez tiene una razón por la que le exige que escriba el código en un estilo funcional. Deberías preguntarle por qué .

Tal vez tiene la intención de mantener el código y mantenerlo él mismo más tarde.

Además, no creo que las dos opciones sean hacerlo al estilo OO o escribir código malo como mencionaste. Claro que escribir código funcional en un ejemplo como este podría ser más difícil, especialmente si solo tiene experiencia en lenguajes orientados a objetos, pero si el cliente está dispuesto a esperar un poco más para ponerse al día con el estilo funcional, entonces no sería No duele preguntarle eso.

Le preguntaría por qué quiere el código en un estilo funcional y si el tiempo no es un problema, le pediría algunos días adicionales para ponerme al día con la programación funcional. (¡hurra por que me paguen por aprender!)

Si todo lo demás falla, explique que le tomaría mucho menos tiempo hacerlo en un estilo OO.

¿Eres consciente de que la programación funcional no solo significa "programación sin clases"?

Vea el artículo de Wikipedia sobre el tema completo, pero en resumen ...

En informática, la programación funcional es un paradigma de programación que trata la computación como la evaluación de funciones matemáticas y evita el estado y los datos mutables. Enfatiza la aplicación de funciones, en contraste con el estilo de programación imperativo, que enfatiza los cambios de estado.

La programación funcional es un paradigma de programación, al igual que OO es un paradigma de programación.

Si tu fondo está en OO, entonces puedo ver cómo quieres que todas tus hormigas sean objetos. Por otro lado, si estás simulando una granja de hormigas con millones de hormigas, OO y la transmisión de mensajes pueden volverse ineficientes.

Afortunadamente para usted, Python tiene excelentes herramientas para la programación funcional (la más importante es que las funciones son objetos de primera clase).

CÓMO de programación funcional de Python

Explique a su cliente que si quiere una programación funcional, debe contratar a alguien que se especialice en eso. La programación funcional es muy diferente de la OOP, y se equivocará si cree que puede recogerla fácilmente y ofrecer una solución compleja de alta calidad.

Existe una idea errónea de que "OO" es completamente contrario a "funcional". Estas cosas pueden ir de la mano muy bien. En su ejemplo, supongo que una "Ant" puede modelarse bien como un tipo de datos abstracto, que puede implementarse directamente utilizando clases y objetos. Las transiciones entre "estados Ant" pueden modelarse naturalmente utilizando funciones, lo que lo llevará a un enfoque funcional en la medida en que su clase "Ant" sea de un tipo inmutable.

Y tenga en cuenta que los "objetos" pueden intercambiarse por el concepto funcional de un cierre, ya que los objetos son los cierres del pobre son los objetos del pobre son los ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Después de hablarlo con el cliente, si él todavía lo quiere a su manera, o haces un trabajo profesional, o si no puedes, entonces no aceptas el contrato o no encuentras la forma de salir de él.

Producir "código malo" solo porque no está de acuerdo sería muy poco profesional.

1. ¿Por qué todos suponemos que el cliente conoce la diferencia entre la programación funcional y la imperativa? Mucha gente no conoce los nombres o detalles de los paradigmas de programación que no son OO e intercambiará fácilmente términos como "procedimiento", "imperativo" y "funcional".

2. No camine como otros le dicen que camine a menos que crea que debe caminar de esa manera. Por lo tanto, si no cree que la programación funcional sea adecuada, no se configure para fallar o asumir un proyecto a medias.

3. Si el cliente escribe la especificación, implemente la especificación; de lo contrario, escriba la especificación e implemente su especificación.

4. La mejor estrategia para influir en las decisiones de los clientes es hacer que la opción no deseada sea significativamente más costosa. Funciona todo el tiempo.

5. Si usted es el experto (en relación con el cliente), entonces debería poder persuadirlos.

6. Para saber realmente si el cliente tiene un punto válido, necesita ganar más experiencia con la programación funcional, ya sea para poder derribarlo con confianza o darse cuenta de que su sesgo hacia OO se debe a su inexperiencia.

7. ¿Por qué no hacerlo en ambos sentidos y luego dejar que el cliente vea ambas implementaciones y decida cuál es más fácil de mantener? Solo tenga en cuenta todo esto en las estimaciones de su proyecto para que pueda disfrutar de la curva de aprendizaje mientras le pagan.

Antes de molestarme más, me aseguraré de que ambos estén hablando de lo mismo. Podrías preguntarle cuándo el software está 'orientado a objetos' para él. Sin embargo, dijo que no es su experiencia principal, puede ser que tenga una idea sesgada.

Por ejemplo, muchas personas podrían considerar

class C {
public:
  C();
  void f( int );
  void g();
};

ser un enfoque clásico orientado a objetos, pero

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

no (aunque ambos están igualmente orientados a objetos en lo que respecta a la definición clásica de "datos junto con las funciones que operan en él").

¿Tratarías de persuadir a tu cliente de que usar programación orientada a objetos es mucho más limpio?

Creo que necesitas educarte más sobre paradigmas de programación. El código programado orientado a objetos no es necesariamente más limpio y, de hecho, no es de aplicación universal. Además, un buen codificador orientado a objetos sabe cómo hacer un buen trabajo utilizando un procedimiento / modular (con paradigmas funcionales y declarativos, es un poco más difícil, pero no debería ser demasiado difícil para un buen programador llegar, a través de la lectura y la deducción - a una solución aceptable FP / declarativa.)

Casi nunca puedes, repito, casi no puedes tener una buena comprensión de cuándo y cómo usar la Orientación de Objetos sin tener una buena comprensión de la programación modular y de procedimientos. OO es mucho más que declarar clases y jerarquías de herencia.

¿O tratarías de seguir lo que él requería y darle un código malo?

Si no puede escribir un buen código de procedimiento, dudo que pueda escribir un buen código orientado a objetos. Período. No estoy tratando de juzgar aquí, pero esto tiene que ser afirmado.

La orientación a objetos es una extensión de la programación procesal y modular. La Orientación de Objetos simplemente le brinda herramientas que, cuando se usan apropiadamente, le brindan mejores mecanismos para tratar los problemas de encapsulación, acoplamiento, cohesión y reutilización de código / extensibilidad.

Pero todos esos problemas no son inherentes y exclusivos de OO. Existen en el código de procedimiento / modular (y en otros paradigmas para el caso). Este es el tipo de problemas de complejidad que, en esencia, es independiente del paradigma. Si no puede manejarlos sin pegamento OO, entonces es poco probable que pueda manejarlos con él.

=========

Volviendo a su pregunta original, sobre si tratar de persuadir a su cliente. Depende. Como dijo el cartel Sean McMillan, si el cliente simplemente está tratando de microgestionar el esfuerzo de desarrollo para alguna agenda (leer, política de la oficina), aléjese. Las personas que hacen ese sabotaje proyectan culpar a alguien más, o empujar una agenda particular. No quieres involucrarte en eso.

OTH, puede haber otras razones para tal requisito. Muchas tiendas integradas, para bien o para mal, optan por poner muchas restricciones sobre lo que puede hacer con C ++ (sin métodos virtuales, sin excepciones, por ejemplo). Algunas veces se hace de una manera increíble. En otras ocasiones, existen razones técnicas válidas para hacerlo.

Por lo tanto, debe comprender por qué el cliente quiere evitar el código OO. Y si puede suponer que no hay una agenda política (no hay señales de alerta), entonces debe hacer lo profesional, que es simplemente hacer el código procesal / modular, y hacer un buen trabajo al respecto.

Realmente no hay excusa para entregar código malo, independientemente del paradigma de programación. Si no puede producir código aceptable con un paradigma, ciertamente no puede producir código aceptable en general.

Estás mezclando estructuras de datos y programación orientada a objetos (una confusión común en este mundo infestado de OO)

Si todo lo que necesita hacer es "rastrear atributos de datos" en una estructura de datos y modificarlos, entonces casi cualquier lenguaje creado después de los años 70 tendrá un buen soporte para ello, OO o no.

Las cosas que son más fáciles de hacer en OO son rudas

• Herencia basada en clases (es fácil crear una nueva clase que pretende ser una antigua)
• Polimorfismo basado en clases (es fácil agregar nuevos tipos de hormigas a la simulación después)

Si no tiene una necesidad apremiante de uno de estos, básicamente cualquier paradigma de programación debería resolverlo sin demasiados problemas.

mi cliente dijo que, dado que tiene experiencia en programación funcional, le gustaría que la simulación se realice utilizando programación funcional.

(Este es otro ejemplo más de un problema social que se confunde con un problema técnico / de diseño).

Hay dos posibilidades aquí:

1. Su cliente espera poder tomar el código que ha escrito y adaptarlo o mantenerlo él mismo después de que haya terminado de escribirlo. Si es así, debe saber mucho más sobre el "estilo de la casa": funcional frente a OO es solo la punta del iceberg. Deberá limitarse a un estilo de programación que su cliente entienda, o deberá educar a su cliente en los estilos que prefiera. (Una vez, me pidieron que creara una aplicación web con CGI, sin usar plantillas o bibliotecas porque el cliente podría querer hacer cambios).

2. Su cliente está tratando de controlar el desarrollo debido a alguna agenda. Esta es una bolsa llena de locos con los que no quieres tener nada que ver. Si realmente está proporcionando un software "llave en mano", al cliente no debería importarle si está hecho de hámsters que corren sobre ruedas, siempre que haga el trabajo de manera confiable. Permitirse ser microgestionado de esta manera es solo pedir dolor.

Depende de usted decidir en qué situación se encuentra y actuar en consecuencia.

Umm ... ¿soy el único aquí pensando "esto es obviamente un trabajo de prueba / asignación"? .

En primer lugar, la tarea en sí es de naturaleza "académica" (simula un aspecto del comportamiento de las hormigas).

En segundo lugar, una solicitud para implementar requisitos usando (o evitando) un paradigma de programación muy específico huele al "cliente" que puede leer el código y hacer tales afirmaciones.

Si este es el caso, es mejor que haga lo que se le exige: será una experiencia de aprendizaje bastante agradable y, si puede hacerlo, aprenderá mucho en el proceso ...

Si este no es el caso, debe preguntarse a sí mismo y / o al cliente por el razonamiento sobre la asignación. Si el razonamiento es sólido, entonces hazlo: aprenderás y serás mejor como programador para la experiencia. Quién sabe, incluso podrías aprender a que te guste el estilo funcional sobre OO.

Si falta la explicación, entonces todas las apuestas están apagadas. No puedo recomendarle qué hacer.

Es posible que desee probar independientemente de implementar los requisitos en lenguaje / estilo funcional o puede rechazar cortésmente la oferta si siente algo sospechoso.

Lo principal es: una vez que comprenda la motivación detrás de los requisitos, el curso de acción adecuado se hace evidente.

EDITAR: después de echar un vistazo diagonal al PDF referenciado, los algoritmos descritos allí seguramente parecen encajar bien con el estilo funcional en lugar de OO

Hay varios aspectos buenos en su solicitud de usar programación funcional:

1. Tienes un cliente, siempre es una buena señal
2. El cliente espera que seas muy bueno en lo que estás haciendo. Es por eso que piden programación funcional. Entonces, su organización de ventas está haciendo un buen trabajo o está pidiendo precios muy altos por sus servicios.
3. La organización del cliente tiene algunas personas que saben que la programación funcional es algo bueno y será grande en el futuro

Pero también hay algunas señales alarmantes:

1. No parece estar preparado para implementarlo en la programación funcional. Ya estás un poco desactualizado en tus habilidades y no puedes seguir el ritmo de los cambios.
2. O el cliente espera que seas mejor programador de lo que realmente eres. Esto significa que es posible que deba rebajar sus requisitos hasta que pueda hacerlo correctamente.

Secundando las respuestas anteriores que quizás OO no es la mejor solución, en cuyo caso el cliente puede tener un punto.

Eche un vistazo al Desafío AI que modela algunos de los comportamientos detallados en la pregunta aquí http://aichallenge.org y luego eche un vistazo a la variedad de paquetes de inicio: http://aichallenge.org/starter_packages.php/ most son idiomas que no ubicaría dentro del paradigma OO.

No ha escrito nada sobre el lenguaje de programación, que es probablemente lo más importante allí. La diferencia entre OOP y la programación funcional no es solo la forma en que se organiza el código sino el lenguaje en sí. Cuando el caso es de alta concurrencia, se está utilizando el lenguaje funcional Erlang, y tiene una ventaja muy alta sobre, por ejemplo, Java (se usa, por ejemplo, en el chat de Facebook). La solución OOP simplemente podría fallar debido a problemas de rendimiento.

El cliente aquí es universitario, por lo que el idioma no es solo un problema de rendimiento / configuración, el código también se puede usar para el trabajo didáctico con estudiantes o investigación propia. Entonces, 'persuadir' al cliente para que elija otro paradigma, en mi opinión, no es aplicable aquí. Esto es, ya sea que puede ocuparse de la tarea o no puede (y, por lo tanto, no debe tomar ese proyecto).

El cliente dice "saltar", su respuesta es: __ _ ?

Para mí, intentaría persuadirlo si tuviera sentido (nuevo proyecto), pero también tengo un cliente con una aplicación VB6 de 10 años para la que hago actualizaciones ocasionalmente ... sin convencerlos de que

'Examina' un poco a tu cliente (de una manera no conflictiva):

¿El cliente realmente sabe la diferencia entre OOP y la programación funcional? ¿Son legítimas las inquietudes / solicitudes del cliente?

En caso afirmativo: si está calificado, haga lo que quiera y tome su dinero. Si no está calificado, dígales y deje que decidan qué hacer.

De lo contrario: hola-cola fuera de allí!

double dist(Point p1, Point p2) 
{
  //return distance
}

Esta función es funcional siempre que no lea / escriba nada fuera de la función. Si la función tocara una variable de clase, ya no sería "funcional". La ventaja del estilo funcional es que no hay más errores de cambio o estado inválido. Una gran cantidad de funciones son solo fórmulas matemáticas. Esa es la programación funcional en pocas palabras.

Por cierto, puede combinar un estilo funcional dentro de un diseño orientado o basado en objetos. Por ejemplo, las dos variables de "Punto" son objetos con estado. ¡Y la función sigue siendo funcional! ¡¡Hurra!!