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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует распространенное заблуждение, что «ОО» полностью противоречит «функционалу». Эти вещи могут идти рука об руку очень хорошо. В вашем примере, я предполагаю, что "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. Почему мы все предполагаем, что клиент знает разницу между функциональным и императивным программированием? Многие люди не знают имен или специфики неопрограммных парадигм программирования и легко обмениваются такими терминами, как «процедурный», «императивный» и «функциональный».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=========

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Кажется, вы не готовы реализовать это в функциональном программировании. Вы уже немного устарели в своих навыках и не можете идти в ногу с изменениями.
2. Или клиент ожидает, что вы будете лучшим программистом, чем вы есть на самом деле. Это означает, что вам может потребоваться понизить их требования, пока вы не сможете сделать это должным образом.

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

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

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

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

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

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

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

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

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

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

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

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

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