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

31

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?

usuario8
fuente
99
Una cosa que podría cambiar de opinión es si el costo de hacerlo es mayor (si es más competente en lenguajes OO que un lenguaje de programación funcional).
Holger
Puede ser interesante comparar el código de simulación de hormigas de Rich Hickey ( gist.github.com/1093917 ), en Clojure tan funcional, aunque la simulación fue diseñada principalmente para demostrar el uso de STM.
mikera
13
Comentaristas: No deje una respuesta aquí en los comentarios. Escribe tu propia respuesta. Los comentarios no son un lugar para discutir varias respuestas posibles a la pregunta: ya sea exponga su sugerencia como respuesta o tómela para conversar primero.
66
Solo queriendo asegurarme de que vio el punto de N3dst4 de que la "programación funcional" es una disciplina de programación particular. La programación que no está orientada a objetos generalmente se describe como "programación procesal".
DJClayworth
1
¿Por qué crees que la implementación orientada a objetos sería "mucho más limpia"? Lo más probable es que sea mucho menos legible que una solución funcional adecuada.
SK-logic

Respuestas:

201

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.

Joris Timmermans
fuente
83
¡+1 para "quizás aprendas algo que no esperabas"!
Kenneth
2
Además, la programación orientada a datos permite excelentes desempeños porque es amigable con la caché y se implementa mejor en conjuntos de funciones que procesan bloques de datos. Parece perfecto para el problema en el que estás trabajando. No sé cómo se aplica a la programación funcional, pero supongo que ayuda más de lo que duele.
Klaim
8
¡+1 para "puede que aprendas algo que no esperabas!" PERO: si el OP no tiene mucha experiencia en programación funcional y el cliente espera una solución buena y barata, sería bastante arriesgado sumergirse en un Nueva forma de resolver problemas.
mort
3
@mort: el cliente en este caso quiere algo específico, parece que sabe lo suficiente como para saber lo que quiere, por lo que si la persona que contrató no puede hacerlo, ese es su problema. Supongo que lo que estoy diciendo es el hecho de que el cliente quiere algo "bueno y barato" y dice que contrató a la persona equivocada que no puede proporcionar eso, es culpa del cliente, no es culpa del autor que no sepa cómo proporcionar un servicio barato y barato. Buena solución de programación funcional a este problema. Uno de esos vale la pena el autor tratando de proporcionar lo que el cliente quiere, ya que no hay ninguna razón técnica para no hacerlo.
Ramhound
2
En ninguna parte de la pregunta el OP dijo las palabras "bueno y barato". El deseo podría ser "Rápido y bueno" (de los tres: rápido, bueno, barato). Todo eso es irrelevante, sin orientación de OP, ya que las "Especificaciones" dicen "Usar programación funcional".
WernerCD
68

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.

Thanos Papathanasiou
fuente
@downvoter, ¿podrías darnos tu opinión?
Thanos Papathanasiou
3
Entiendo que la notación tl; dr merece un voto negativo, para algunos
Independiente
1
¿Hay algo en las Preguntas frecuentes o en las páginas de ayuda que advierte el uso de "tl; dr"? ¿O son solo algunos usuarios malintencionados a quienes no les gusta? Me parece que agregar un resumen sucinto de una respuesta solo puede ser algo bueno, por lo que no puedo imaginar por qué esto se consideraría digno de un voto negativo.
Ben Lee
1
@Bratch Pensé que la notación tl; dr era para el usuario que intentaba leer mi respuesta. Lo que significa que incluso si se salta todo el resto, si solo lee esto, obtendrá la esencia de la respuesta. ¿Qué quieres decir con lo que estás diciendo?
Thanos Papathanasiou
1
Algunos de nosotros, las personas de edad tienen ni idea de lo tl; dr medios (lo hice mirar hacia arriba pero ¿por qué usaría alguien tal sentido críptico?)
HLGEM
55

¿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

N3dst4
fuente
+1 por resolver esto. Realmente debería aclararse en la pregunta.
Bratch
¿Sabía que puede tener lenguajes que sean OO y funcionales? Esos son dos principios de organización que en realidad son en gran medida ortogonales entre sí. Es cierto que muchos lenguajes OO también son lenguajes imperativos estructurados, pero no hay una base teórica para acoplarlos fuertemente.
Donal Fellows
@DonalFellows Absolutamente, es un buen punto que los dos no son mutuamente excluyentes. Python (porque la pregunta se etiquetó originalmente como Python) es imprescindible, orientada a objetos y funcional, dependiendo de dónde te encuentres cuando la mires. Y en otra parte de esta página, alguien menciona OCaml, que es OO y funcional.
N3dst4
22

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.

KaptajnKold
fuente
De acuerdo. Es solo sentido común aplicado.
Señor Smith
1
El problema es que, desde una perspectiva comercial, no siempre es fácil admitir su falta de conocimiento al cliente ("Debería contratar a alguien familiarizado con la programación funcional"). Es más fácil afirmar que OOP es mejor, simplemente porque estás familiarizado con él. Menos honesto , pero más fácil.
Andres F.
@Andres F: Tratar con un nuevo lenguaje (y paradigma) no es nada fácil. Tarde o temprano, el cliente debe reconsiderar el problema. Mejor pronto que tarde.
Señor Smith
44
@ Señor Smith: Estoy totalmente de acuerdo con usted. Solo digo que este tipo de honestidad del proveedor (es decir, el programador) no siempre es comunicativo. Esencialmente le está diciendo al cliente que contrate a otra persona, lo cual tiene todo el sentido del mundo, pero no obstante es doloroso.
Andres F.
13

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

Doc Brown
fuente
+1 La programación funcional y OOP son conceptos ortogonales. Mire OCaml, Scala, Clojure, python para los lenguajes que pueden manejar ambos.
rds
Esos dos enlaces valen solo un voto positivo ...
Wayne Werner
8

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.

Jaydee
fuente
8
  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.

Sam
fuente
+1 para "¿Por qué todos suponemos que el cliente conoce la diferencia entre programación funcional e imperativa?". El cliente podría significar algo como "No quiero que sea repetitivo, así que divida todo en funciones", lo cual es de sentido común para los desarrolladores. Es posible que un cliente no piense que tiene sentido común, por lo que te está diciendo.
AlexWebr
1
+1, en realidad, el cliente no tiene idea de qué es la programación funcional o está impulsada por las últimas palabras de moda o porque lo hicieron hace veinte años y todavía se consideran técnicos.
Tipo anónimo
5

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").

Frerich Raabe
fuente
2
¿Por qué discutir sobre el significado preciso de OOP? Sería mejor preguntar por qué el cliente cree que su simulación se adapta mejor a la programación funcional. El cliente puede tener razón ... Dudo seriamente que por "funcional" se refiriera a su segundo ejemplo de C, o que estaba confundiendo "funcional" con "imperativo".
Andres F.
@Andres F .: No dije que por 'funcional' se refería a mi segundo ejemplo de C. Solo estaba señalando que algunas personas consideran que es POO mientras que otras no. Entonces, antes de comenzar una discusión, sería bueno evitar cualquier malentendido. Quizás no haya desacuerdo en primer lugar. Tal vez el jefe, ya que dijo que no está familiarizado con el propio OOP, supone que el OOP tiene ciertas propiedades (al igual que el OP aparentemente asumió que la programación funcional tenía ciertas propiedades).
Frerich Raabe
Estrictamente, no consideraría que este último sea OOP ya que el envío de llamadas / mensajes de método no se enruta a través del objeto. Esa es una característica clave de OOP.
Donal Fellows
5

¿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.

luis.espinal
fuente
3

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.

hugomg
fuente
Agregaría que cualquier lenguaje de programación funcional con soporte para polimorfismo debería hacer que sea bastante fácil escribir un estilo orientado a objetos u orientado a pseudoobjetos que le permita agregar fácilmente nuevos tipos de hormigas.
Marcin
@ Marcin: es cierto que los lenguajes FP modernos son bastante potentes. Solo quería señalar la distinción entre estructuradores de datos / ADTs y OO
hugomg
Pero OO es realmente solo ADT más despacho de métodos controlados por objetos. Todo lo demás se suma a eso. (Bueno, a menudo el único control del objeto sobre el envío es por el tipo de objeto, pero eso es un refinamiento).
Donal Fellows
3

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.

Sean McMillan
fuente
3

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

Roland Tepp
fuente
2

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.
tp1
fuente
-1 por la suposición implícita de que FP es mejor que OOP.
Russell Borogove
@ tp1 1) Asume que el cliente es técnicamente más inteligente que el programador, lo cual no es el caso, ya que el cliente es solo el cliente. 2) FP es más antiguo que OOP y, aunque últimamente se está presionando mucho, no hay nada de malo en OOP y no necesita olvidarse de usar FP 3) La peor parte de esto es asumir que FP es mejor y usar FP te hace un mejor programador, solo es cierto en un caso por caso y en este caso eso no parece ser cierto.
Joe Tyman
@ Joe Tyman: Bueno, debe suponerse que las personas no son estúpidas, o de lo contrario los clientes se van en un instante. No estaba tratando de decir que oop es malo o peor, sino que asumir que funcional podría ser un requisito irrazonable en esta situación, tal vez el cliente no conoce las habilidades de los programadores, o peor, tratando de hacer que los programadores cambien su tecnología.
tp1
@ Joe Tyman: Además, el peor de los casos que tenía en mente era que los clientes realmente necesitan personas que puedan hacer una programación funcional avanzada, como la teoría de categorías, y están tratando de encontrar un equipo que pueda hacerlo; esta es la razón por la solicitud para ellos podría ser irracional.
tp1
1

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.

Luke
fuente
1

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).

Marinero danubiano
fuente
0

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

boomhauer
fuente
técnicamente, aunque la aplicación VB6 está bien, es casi OO, y si funciona bien en el sistema operativo actual, ¿por qué "actualizar" a .NET? Eso simplemente no tiene sentido a menos que desee aprovechar la nueva funcionalidad.
Tipo anónimo
Sí, pero ¿has intentado usar vb6 últimamente? es muuuy doloroso;)
boomhauer
Sip. Usamos mucho para mantener las aplicaciones existentes a las que aún no se les ha asignado un presupuesto para una actualización de java o .net. Es doloroso (en comparación con un IDE moderno) pero también es relativo. Al igual que cualquier lenguaje (incluidos los guiones) una vez que eres bueno, tu definición de dolor se vuelve mucho más subjetiva.
Tipo anónimo el
0

'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í!

Vector
fuente
0
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!!

Lord Tydus
fuente