Что бы вы сделали, если бы ваш клиент потребовал от вас не использовать объектно-ориентированное программирование?

31

Я пишу программу для имитации активности муравьев в сетке (PDF). Муравей может передвигаться, собирать вещи и бросать их.

Проблема в том, что действие муравьев и положение каждого муравья можно легко отслеживать с помощью атрибутов класса (и мы можем легко создать множество экземпляров таких муравьев), мой клиент сказал, что, поскольку у него есть опыт в функциональном программировании, он хотел моделирование должно быть выполнено с использованием функционального программирования.

Чтобы быть понятным, исходные слова от клиента только «без класса», но не «функциональное программирование». Поэтому я предполагаю, что он не имеет в виду функциональное программирование, и я могу сделать это обязательно. Кроме того, у меня нет предыдущего опыта в функциональном программировании.

Тем не менее, я думаю, что лучше сосредоточиться на этом вопросе, касающемся, в частности, требований к функциональному программированию, чем просто «делать это обязательно».

Как бы вы справились с этой ситуацией? Пытаетесь ли вы убедить своего клиента в том, что использование объектно-ориентированного программирования намного чище, попробуйте выполнить то, что ему требуется, и дать ему некачественный код, или сделать что-то еще?

user8
источник
9
Одна вещь, которая может изменить его мнение, это то, что если вы платите за это больше (если вы владеете языками ОО лучше, чем функциональный язык программирования).
Хольгер
Может быть интересно сравнить код симуляции муравья Рича Хики ( gist.github.com/1093917 ) - в Clojure, поэтому он в основном функционален, хотя симуляция была в основном предназначена для демонстрации использования STM.
Микера
13
Комментаторы: Не оставляйте ответ здесь в комментариях. Напиши свой ответ. Комментарии не являются местом для обсуждения различных возможных ответов на вопрос: либо выдвиньте свое предложение в качестве ответа, либо используйте его для чата, чтобы конкретизировать его первым.
6
Просто хочу убедиться, что вы поняли точку зрения N3dst4, что «функциональное программирование» - это особая дисциплина программирования. Программирование, которое не является объектно-ориентированным, обычно описывается как «процедурное программирование».
DJClayworth
1
Почему вы думаете, что объектно-ориентированная реализация будет "намного чище"? Скорее всего, это будет гораздо менее читабельным, чем правильное функциональное решение.
SK-logic

Ответы:

201

Объектно-ориентированный код по определению не является более чистым, и, наоборот, не OO-код по определению не является дрянным. Несмотря на то, что, по-видимому, существует довольно очевидное объектно-ориентированное отображение этой конкретной проблемы, я хотел бы предложить вам в любом случае попробовать подход функционального программирования. Сделайте это как можно лучше, постарайтесь решить проблему в наилучшем функциональном стиле программирования, который вы только можете придумать, и вы можете просто научиться чему-то, чего не ожидали.

Йорис Тиммерманс
источник
83
+1 за "вы могли бы просто научиться чему-то, чего не ожидали"!
Кеннет
2
Кроме того, ориентированное на данные программирование обеспечивает отличную производительность, потому что кэш-память дружественна и лучше реализована в наборах функций, обрабатывающих блоки данных. Кажется, это идеально подходит для проблемы, над которой вы работаете. Я не знаю, как это применимо к функциональному программированию, но я предполагаю, что это помогает больше, чем ранит.
Klaim
8
+1 за «вы можете просто научиться чему-то, чего не ожидали» !, НО: если у ОП нет большого опыта в функциональном программировании, и клиент ожидает хорошего и дешевого решения, было бы довольно рискованно погрузиться в новый способ решения проблем.
Морт
3
@mort - клиент в этом случае хочет что-то конкретное, похоже, он знает достаточно, чтобы на самом деле знать, чего он хочет, поэтому, если человек, которого он нанял, не может этого сделать, это его проблема. Я предполагаю, что я говорю о том, что клиент хочет что-то «хорошее и дешевое», и говорю, что они наняли не того человека, который не может это предоставить, это вина клиента, а не автора, он не знает, как обеспечить дешево и хорошее функциональное программирование для решения этой проблемы. Одной из тех, которые стоит того, чтобы автор пытался предоставить то, что хочет клиент, поскольку нет никаких технических причин не делать этого.
Ramhound
2
Нигде в этом вопросе ОП не произнесла слова «хорошо и дешево». Желание может быть «Быстро и хорошо» (из трех: быстро, хорошо, дешево). Все это не имеет значения, без указания OP, поскольку в «Спецификациях» говорится «Использовать функциональное программирование».
WernerCD
68

Вы упоминаете, что клиент раньше программировал на функциональном языке, возможно, у него есть причина, по которой он требует от вас написания кода в функциональном стиле. Вы должны спросить его, почему .

Может быть, он намеревается сохранить код и сохранить его сам позже.

Более того, я не думаю, что есть два варианта: сделать это в стиле OO или написать дрянной код, как вы упоминали. Конечно, писать функциональный код в подобном примере может быть сложнее, особенно если у вас есть опыт работы только с объектно-ориентированными языками, но если клиент готов подождать немного дольше, чтобы вы быстро освоили функциональный стиль, тогда больно спрашивать его об этом.

Я спросил бы его, почему он хочет код в функциональном стиле, и если время не так уж важно, я бы попросил несколько дополнительных дней, чтобы освоиться с функциональным программированием. (ура за оплату обучения!)

Если ничего не помогает, объясните, что вам потребуется гораздо меньше времени, чтобы сделать это в стиле ОО.

Танос Папатанасиу
источник
@ downvoter не могли бы вы дать отзыв?
Танос Папатанасиу
3
Я понимаю, что обозначение tl; dr стоит понизить, для некоторых
Independent
1
Есть ли что-нибудь на страницах часто задаваемых вопросов или справки, где говорится о применении "tl; dr"? Или это просто некоторые мошенники, которым это не нравится? Мне кажется, что добавление краткого резюме ответа может быть только хорошей вещью, поэтому я не могу себе представить, почему это будет стоить отрицательного ответа.
Бен Ли
1
@Bratch Я думал, что запись tl; dr предназначена для пользователя, пытающегося прочитать мой ответ. Это означает, что даже если вы пропустите все остальное, если вы просто прочитаете это, вы получите суть ответа. Что вы имеете в виду под тем, что говорите?
Танос Папатанасиу
1
Некоторые из нас, пожилых людей, понятия не имеют, что означает tl; dr (я действительно искал это, но зачем кому-то использовать такую ​​загадочную чепуху?)
HLGEM
55

Знаете ли вы, что функциональное программирование означает не просто «программирование без классов»?

См. Статью Wikipedia об этом для полного schtick, но вкратце ...

В информатике функциональное программирование - это парадигма программирования, которая рассматривает вычисления как оценку математических функций и избегает состояния и изменчивых данных. Он подчеркивает применение функций, в отличие от императивного стиля программирования, который подчеркивает изменения в состоянии.

Функциональное программирование - это парадигма программирования, также как ОО - парадигма программирования.

Если ваш фон в OO, тогда я вижу, как вы хотите, чтобы все ваши муравьи были объектами. С другой стороны, если вы моделируете ферму муравьев с миллионами муравьев, ОО и передача сообщений могут стать неэффективными.

К счастью для вас, в Python есть отличные инструменты для функционального программирования (наиболее важным из которых является то, что функции являются первоклассными объектами).

Python функциональное программирование HOWTO

N3dst4
источник
+1 за высовывание этого. Это действительно следует уточнить в вопросе.
Bratch
Знаете ли вы, что у вас могут быть языки, которые являются одновременно ОО и функциональными? Это два организационных принципа, которые на самом деле в значительной степени ортогональны друг другу. По общему признанию, многие ОО-языки также являются структурированными императивными языками, но нет теоретической основы для их сильной связи.
Донал Феллоуз
@DonalFellows Безусловно, хорошо, что эти два понятия не являются взаимоисключающими. Python (потому что вопрос был изначально помечен как Python) является императивным, объектно-ориентированным и функциональным, в зависимости от того, где вы стоите, когда смотрите на него. А в других местах на этой странице кто-то упоминает OCaml, который является ОО и функциональным.
N3dst4
22

Объясните своему клиенту, что если он хочет функционального программирования, он должен нанять кого-то, кто специализируется на этом. Функциональное программирование сильно отличается от ООП, и вы ошибетесь, если считаете, что можете легко его взять и предложить комплексное решение высокого качества.

KaptajnKold
источник
Согласен. Это просто здравый смысл.
Мистер Смит
1
Проблема заключается в том, что с точки зрения бизнеса не всегда легко признать недостаток знаний у клиента («Вместо этого вы должны нанять человека, знакомого с функциональным программированием»). Проще сказать, что ООП лучше, просто потому что вы с ним знакомы. Менее честно , но проще.
Андрес Ф.
@Andres F: Работа с новым языком (и парадигмой) совсем не легка. Рано или поздно клиент должен пересмотреть проблему. Лучше скорее, чем позже.
Мистер Смит
4
@ Мистер Смит: Я полностью согласен с вами. Я просто говорю, что такого рода честность от провайдера (то есть программиста) не всегда наступает. По сути, вы говорите клиенту нанять кого-то другого, что имеет смысл в мире, но, тем не менее, болезненно.
Андрес Ф.
13

Существует распространенное заблуждение, что «ОО» полностью противоречит «функционалу». Эти вещи могут идти рука об руку очень хорошо. В вашем примере, я предполагаю, что "Ant" может быть смоделирован как абстрактный тип данных, который может быть непосредственно реализован с использованием классов и объектов. Переходы между «состояниями Ant» могут быть естественным образом смоделированы с использованием функций, которые приведут вас к функциональному подходу, поскольку ваш класс «Ant» является неизменным типом.

И помните, что «объекты» могут быть взаимозаменяемы с помощью функциональной концепции замыкания, поскольку объекты - это замыкания бедняков, то есть объекты бедняков - это ... ;-):

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

Док Браун
источник
+1 Функциональное программирование и ООП - ортогональные понятия. Посмотрите на OCaml, Scala, Clojure, python для языков, которые могут обрабатывать оба.
Rds
Эти две ссылки стоят одного голоса ...
Уэйн Вернер
8

После обсуждения этого с клиентом, если он все еще хочет этого по-своему, вы либо выполняете профессиональную работу, либо, если не можете, то либо не принимаете контракт, либо находите какой-то выход из этого.

Производить «дерьмовый код» только потому, что вы не согласны, было бы крайне непрофессионально.

Jaydee
источник
8
  1. Почему мы все предполагаем, что клиент знает разницу между функциональным и императивным программированием? Многие люди не знают имен или специфики неопрограммных парадигм программирования и легко обмениваются такими терминами, как «процедурный», «императивный» и «функциональный».

  2. Не ходите так, как другие говорят вам ходить, если только вы не уверены, что должны идти этим путем. Поэтому, если вы не верите, что функциональное программирование подходит, не настраивайте себя на провал или нерешительно приступайте к проекту.

  3. Если клиент пишет спецификацию, тогда реализуйте спецификацию, в противном случае вы пишете спецификацию и реализуете свою спецификацию.

  4. Лучшая стратегия влияния на решения клиентов - сделать нежелательный вариант значительно дороже. Это работает каждый раз.

  5. Если вы являетесь экспертом (по отношению к клиенту), то вы сможете убедить их.

  6. Чтобы действительно знать, есть ли у клиента действительная точка, вам нужно получить больше опыта с функциональным программированием, чтобы вы могли уверенно сбить его с толку или понять, что ваш уклон в сторону ОО связан с вашей неопытностью.

  7. Почему бы не сделать это обоими способами, а затем позволить клиенту увидеть обе реализации и решить, что легче поддерживать. Просто включите все это в свои оценки проекта, чтобы вы могли наслаждаться кривой обучения, пока вам платят.


источник
+1 за «Почему мы все предполагаем, что клиент знает разницу между функциональным и императивным программированием?». Клиент может означать что-то вроде «Я не хочу, чтобы это было повторяющимся, поэтому разбейте все на функции», что является здравым смыслом для разработчиков. Клиент может не думать, что это здравый смысл, поэтому он говорит вам.
AlexWebr
1
+1, на самом деле клиент не имеет ни малейшего представления о том, что такое функциональное программирование, или руководствуется последними модными словами или потому, что они сделали это двадцать лет назад и все еще считают себя техническими.
Анонимный тип
5

Прежде чем побеспокоиться, я позабочусь, чтобы вы оба говорили об одном и том же. Вы можете спросить его, когда программное обеспечение «объектно-ориентировано» для него. Так как он сказал, что это не его основная экспертиза, возможно, у него какая-то искаженная идея.

Например, многие люди могли бы рассмотреть

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

быть классическим объектно-ориентированным подходом, но

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

нет (даже если оба они в равной степени объектно-ориентированы, поскольку речь идет о классических «данных вместе с функциями, которые над ними работают»).

Фрерих Раабе
источник
2
Зачем спорить о точном значении ООП? Было бы лучше спросить, почему клиент считает, что его симуляция лучше подходит для функционального программирования. Клиент может быть прав ... Я серьезно сомневаюсь, что под "функционалом" он имел в виду ваш второй пример C или что он путал "функционал" с "императивом".
Андрес Ф.
@Andres F .: Я не утверждал, что под «функционалом» он имел в виду мой второй пример C. Я просто указывал, что некоторые люди считают это ООП, а другие нет. Поэтому, прежде чем начинать спор, было бы хорошо избежать недоразумений. Может быть, нет никаких разногласий в первую очередь. Возможно, начальник, поскольку он сказал, что не знаком с самим ООП, предполагает, что ООП обладает определенными свойствами (точно так же, как ОП, очевидно, предполагал, что функциональное программирование имеет определенные свойства).
Фрерих Раабе
Строго говоря, я бы не стал считать, что последний является ООП, поскольку вызов метода / отправка сообщения не маршрутизируются через объект. Это ключевая особенность ООП.
Donal Fellows
5

Будете ли вы пытаться убедить своего клиента, что использование объектно-ориентированного программирования намного чище?

Я думаю, что вам нужно больше изучать парадигмы программирования. Объектно-ориентированный программируемый код не обязательно является более чистым и фактически не всегда применим. Кроме того, хороший объектно-ориентированный кодер знает, как выполнять хорошую работу, используя процедурный / модульный (с функциональными и декларативными парадигмами это немного сложнее, но для хорошего программиста не должно быть слишком сложно прийти - через чтение и дедукцию - к приемлемому ФП / Декларативному решению.)

Вы почти никогда не можете, я повторяю, вы почти не можете хорошо понять, когда и как использовать объектную ориентацию, не имея хорошего понимания процедурного и модульного программирования. OO - это намного больше, чем просто объявление классов и иерархий наследования.

Или вы попытались бы следовать тому, что он требовал, и дать ему дерьмовый код?

Если вы не можете написать хороший код процедурно, я сомневаюсь, что вы можете написать хороший код объектно-ориентированным способом. Период. Я не пытаюсь здесь судить, но это нужно утверждать.

Объектная ориентация является расширением процедурного и модульного программирования. Объектно-ориентация просто предоставляет вам инструменты, которые при правильном использовании дают вам более эффективные механизмы для решения проблем инкапсуляции, связывания, связности и повторного использования кода / расширяемости.

Но все эти проблемы не являются неотъемлемыми и уникальными для ОО. Они существуют в процедурном / модульном коде (и в других парадигмах в этом отношении). Это тип проблем сложности, который по своей сути не зависит от парадигмы. Если вы не можете справиться с ними без ОО-клея, то вряд ли вы справитесь с ними.

=========

Возвращаясь к исходному вопросу, стоит ли пытаться убедить вашего клиента. Это зависит. Как сказал постер Шон Макмиллан, если клиент просто пытается микро-управлять усилиями по разработке какой-либо программы (читай, офисная политика), уходите. Люди, которые занимаются саботажем проектов, обвиняют кого-то другого или выдвигают определенную повестку дня. Вы не хотите участвовать в этом.

OTH, могут быть другие причины для такого требования. Многие встроенные магазины, правильно или неправильно, предпочитают накладывать множество ограничений на то, что вы можете делать с C ++ (например, без виртуальных методов, без исключений). Иногда это делается по-колено. Иногда есть веские технические причины для этого.

Таким образом, вы должны понять, почему клиент хочет избежать OO-кода. И если вы можете предположить, что нет политической повестки дня (нет красных флажков), тогда вам следует заняться профессиональным делом, то есть просто сделать код процедурным / модульным, и хорошо поработать над этим.

На самом деле нет оправдания доставлению дрянного кода независимо от парадигмы программирования. Если вы не можете создать приемлемый код с одной парадигмой, вы наверняка не сможете создать приемлемый код в целом.

luis.espinal
источник
3

Вы смешиваете структуры данных и объектно-ориентированное программирование (распространенная путаница в этом мире, наполненном ОО)

Если все, что вам нужно сделать, это «отслеживать атрибуты данных» в структуре данных и изменять их, то практически любой язык, созданный после 70-х годов, будет иметь для этого хорошую поддержку, OO или нет.

В OO проще заниматься грубостью

  • Наследование на основе классов (легко создать новый класс, который выглядит как старый)
  • Основанный на классах полиморфизм (его легко добавить новые виды муравьев в симуляцию впоследствии)

Если у вас нет острой необходимости в одном из них, тогда любая парадигма программирования должна решить эту проблему без особых проблем.

hugomg
источник
Я хотел бы добавить, что любой функциональный язык программирования с поддержкой полиморфизма должен довольно легко писать объектно-ориентированный или псевдообъектно-ориентированный стиль, который позволяет легко добавлять новые типы муравьев.
Марчин
@Marcin: правда, что современные языки FP довольно мощные. Я просто очень хотел указать на разницу между структурами данных / ADT и ОО
hugomg
Но ОО - это на самом деле просто ADT плюс диспетчеризация методов, управляемых объектами. Все остальное строится поверх этого. (Ну, часто единственным объектом контроля над диспетчеризацией является тип объекта, но это уточнение.)
Donal Fellows
3

Мой клиент сказал, что, поскольку у него есть опыт работы в области функционального программирования, он хотел бы, чтобы моделирование проводилось с использованием функционального программирования.

(Это еще один пример того, как социальная проблема была ошибочно принята за техническую / дизайнерскую проблему.)

Здесь есть две возможности:

  1. Ваш клиент ожидает, что он сможет взять код, который вы написали, и принять его или сохранить его самостоятельно после того, как вы закончили его писать. Если это так, вы должны знать гораздо больше о «домашнем стиле» - функционал против ОО - это только верхушка айсберга. Вам нужно будет либо ограничить себя стилем программирования, понятным вашему клиенту, либо вы должны будете обучить своего клиента тем стилям, которые вы предпочитаете. (Однажды меня попросили создать веб-приложение с CGI без использования шаблонов или библиотек, потому что клиент может захотеть внести изменения.)

  2. Ваш клиент пытается контролировать развитие из-за какой-то повестки дня. Это сумка, полная сумасшествия, с которой ты не хочешь иметь ничего общего. Если вы действительно предоставляете программное обеспечение «под ключ», клиенту не должно быть никакого дела, если он сделан из хомяков, работающих на колесах, если он надежно выполняет свою работу. Позволить себе микроуправляться таким способом - просто просить боли.

Вам решать, в какой ситуации вы находитесь, и действовать соответственно.

Шон Макмиллан
источник
3

Хм ... я здесь один думаю, что "это, очевидно, тестовая работа / задание"? ,

Во-первых, само задание носит своего рода «академический» характер (имитировать аспект поведения муравьев).

Во-вторых, это запрос на выполнение требований, использующий (или избегающий) очень специфическую парадигму программирования, которая пахнет «клиентом», который может читать код и делать такие утверждения.

Если это так, вам лучше делать то, что от вас требуется - это будет довольно приятный опыт обучения, и если вы сможете это сделать, вы многому научитесь в процессе ...

Если это не так, вам следует спросить себя и / или клиента о причинах данного задания. Если аргументация убедительна, то сделайте это - вы научитесь, и вы станете программистом лучше. Кто знает - вы можете даже научиться любить функциональный стиль поверх ОО.

Если объяснение отсутствует, то все ставки сняты .. Я не могу рекомендовать вам, что делать.

Вы можете попытаться независимо выполнить требования в функциональном языке / стиле, или вы можете вежливо отклонить предложение, если почувствуете что-то подозрительное.

Главное - как только вы поймете мотивацию требований, правильный курс действий станет очевидным.

РЕДАКТИРОВАТЬ: После диагонального взгляда на PDF-файл, на который ссылаются, алгоритмы, описанные там, безусловно, кажутся подходящими для функционального стиля, а не OO

Роланд Тепп
источник
2

В их просьбе использовать функциональное программирование есть несколько хороших аспектов:

  1. У вас есть клиент, это всегда хороший знак
  2. Клиент ожидает, что вы будете очень хороши в том, что вы делаете. Вот почему они спрашивают о функциональном программировании. Таким образом, ваша сбытовая организация делает хорошую работу, или вы запрашиваете очень высокую цену за свои услуги.
  3. В клиентской организации есть люди, которые знают, что функциональное программирование - это хорошо, и в будущем оно станет большим

Но есть и тревожные признаки:

  1. Кажется, вы не готовы реализовать это в функциональном программировании. Вы уже немного устарели в своих навыках и не можете идти в ногу с изменениями.
  2. Или клиент ожидает, что вы будете лучшим программистом, чем вы есть на самом деле. Это означает, что вам может потребоваться понизить их требования, пока вы не сможете сделать это должным образом.
ТР1
источник
-1 для неявного предположения, что FP лучше, чем ООП.
Рассел Борогове
@ tp1 1) Вы предполагаете, что клиент технически умнее программиста, а это не так, поскольку клиент - это просто клиент. 2) FP старше ООП, и хотя в последнее время он получает много прессов, в ООП нет ничего плохого, и вам не нужно забывать использовать FP 3) Хуже всего то, что предположим, что FP лучше и использует FP делает вас лучшим программистом, это верно только в каждом конкретном случае, и в этом случае это не так.
Джо Тиман
@Joe Tyman: Ну, должно быть предположение, что люди не глупы, или иначе клиенты ушли в одно мгновение. Я не пытался сказать, что это плохо или плохо, но вместо этого предположение, что функциональность может быть необоснованным требованием в этой ситуации - может быть, клиент не знает навыков программистов или, что еще хуже, пытается заставить программистов переключать свои технологии.
tp1
@Joe Tyman: Кроме того, наихудший сценарий, который я имел в виду, состоял в том, что клиентам действительно нужны люди, которые могут заниматься каким-то продвинутым функциональным программированием, например теорией категорий, и они пытаются найти команду, которая может это сделать - вот почему для них может быть необоснованным.
tp1
1

После приведенных выше ответов, что, возможно, ОО не является лучшим решением, в этом случае клиент может иметь смысл.

Взгляните на AI Challenge, который моделирует поведение, подробно описанное в этом вопросе, здесь, http://aichallenge.org, а затем взгляните на множество стартовых пакетов - http://aichallenge.org/starter_packages.php/ most это языки, которые я бы не включил в парадигму ОО.

Люк
источник
1

Вы ничего не написали о языке программирования, что, пожалуй, самое важное. Разница между ООП и функциональным программированием заключается не только в том, как организован код, но и в самом языке. Когда имеет место высокий параллелизм, используется функциональный язык Erlang, и он имеет очень большое преимущество перед, например, Java (он используется, например, в чате Facebook). Решение ООП может просто потерпеть неудачу из-за проблем с производительностью.

Клиент здесь - университет, поэтому язык - это не только проблема производительности / конфигурации, код также может быть использован для дидактической работы со студентами или для собственных исследований. Так что «убедить» клиента выбрать другую парадигму, на мой взгляд, здесь не применимо. Это либо вы можете справиться с задачей, либо не можете (и поэтому вы не должны брать этот проект).

Дунайский моряк
источник
0

Клиент говорит «прыгать», ваш ответ: __ _ ?

Для меня я бы попытался убедить, если это имеет смысл (новый проект), но у меня также есть клиент с 10-летним приложением VB6, которое я периодически обновляю ... не собираюсь убеждать их

boomhauer
источник
Технически, хотя приложение VB6 в порядке, оно почти ОО, и если оно работает нормально на текущей ОС, зачем «обновляться» до .NET. Это просто не имеет смысла, если вы не хотите воспользоваться новой функциональностью.
Анонимный тип
Да, но вы пытались использовать VB6 в последнее время? это тааак больно;)
boomhauer
Ага. Мы используем его для поддержки существующих приложений, которым еще не выделен бюджет на обновление до Java или .net. Это больно (по сравнению с современной IDE), но это также относительно. Как и любой язык (включая сценарии), когда вы хорошо разбираетесь в нем, ваше определение боли становится намного более субъективным.
анонимный тип
0

«Пересмотрите» своего клиента немного (неконфронтационно):

Знает ли клиент на самом деле разницу между ООП и функциональным программированием? Являются ли проблемы / запросы клиента законными?

Если «Да»: если вы квалифицированы, делайте, что хотите, и берите деньги. Если вы не квалифицированы, скажите им об этом, и пусть они решат, что делать.

Остальное: привет там!

Вектор
источник
0
double dist(Point p1, Point p2) 
{
  //return distance
}

Эта функция является функциональной, если она не читает и не записывает ничего вне функции. Если бы функция коснулась переменной класса, она больше не была бы «функциональной». Преимущество функционального стиля в том, что больше нет ошибок от изменения или неправильного состояния. Большое количество функций - это просто математические формулы. Это функциональное программирование в двух словах.

Кстати, вы можете комбинировать функциональный стиль в объектно-ориентированном или ориентированном дизайне. Например, две переменные «Point» - это объекты с состоянием. И функция все еще функционирует! Ура!!

Лорд тидус
источник