Що б ви зробили, якби ваш клієнт вимагав від вас не використовувати об'єктно-орієнтоване програмування?

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

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

Щоб було зрозуміло, оригінальні слова від клієнта - це "не клас", але не "функціональне програмування". Тож я припускаю, що він не означає функціонального програмування, і я можу це зробити обов'язково. Крім того, я не маю попереднього досвіду функціонального програмування.

Однак я вважаю, що корисно зосередитись на цьому питанні, зокрема, на вимозі функціонального програмування, а не просто "робити це обов'язково".

Як би ви вирішили цю ситуацію? Ви б спробували переконати свого клієнта, що використання об'єктно-орієнтованого програмування набагато чистіше, спробуйте дотримуватися того, що він вимагає, і надайте йому неякісний код, або зробите щось інше?

Об'єктно-орієнтований код не є чистішим за визначенням, і навпаки, не-OO код не за визначенням crappy. Хоча, мабуть, існує досить очевидне об'єктно-орієнтоване відображення цієї конкретної проблеми, я б запропонував вам все-таки спробувати функціональний підхід до програмування. Постарайтеся зробити це найкращим чином, спробуйте вирішити проблему в найкращому стилі функціонального програмування, який ви можете зібрати, і ви можете просто навчитися тому, чого ви не очікували.

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

Можливо, він має намір зберегти код і зберегти його пізніше.

Більше того, я не думаю, що обидва варіанти - чи робити це в OO-стилі, або писати хитромудрий код, як ви згадали. Звичайно, написання функціонального коду на прикладі, подібному до цього, може бути складніше, особливо якщо у вас є лише досвід роботи з об'єктно-орієнтованими мовами, але якщо клієнт готовий почекати трохи довше, щоб ви швидше працювали з функціональним стилем, тоді він би не став ' не боляче його запитати.

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

Якщо все інше не вдасться пояснити, що це займе у вас набагато менше часу, щоб зробити це в стилі ОО.

Чи знаєте ви, що функціональне програмування не означає просто "програмування без класів"?

Дивіться статтю Вікіпедії про це для повного schtick, але коротше ...

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

Функціональне програмування - це парадигма програмування, як і OO - парадигма програмування.

Якщо ваш фон знаходиться в ОО, то я бачу, як ви хочете, щоб усі ваші мурахи були об’єктами. З іншого боку, якщо ви імітуєте мурашину ферму з мільйонами мурашок, ОО та передача повідомлень можуть стати неефективними.

На щастя для вас, Python має чудові інструменти для функціонального програмування (найважливішим є те, що функції - це першокласні об'єкти.)

Функціональне програмування Python HOWTO

Поясніть своєму клієнту, що якщо він хоче функціонального програмування, він повинен найняти того, хто спеціалізується на цьому. Функціональне програмування сильно відрізняється від OOP, і ви помилитесь, якщо подумаєте, що зможете легко підібрати його та поставити складне рішення високої якості.

Існує поширена помилкова думка, що "ОО" повністю суперечить "функціональному". Ці речі можуть йти рука об руку. У вашому прикладі, я думаю, що "Мураха" може бути добре змодельований як абстрактний тип даних, який може бути реалізований прямо вперед за допомогою класів та об'єктів. Переходи між "мурашиними станами" можна закономірно моделювати за допомогою функцій, що приведе вас до функціонального підходу, оскільки ваш клас "Мураха" є незмінним типом.

І майте на увазі, що "об'єкти" можуть бути замінені функціональною концепцією закриття, оскільки об'єкти - це закриття бідної людини, об'єкти бідної людини - це ... ;-):

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. Для того, щоб дійсно знати, чи має клієнт дійсну точку, вам потрібно отримати більше досвіду роботи з функціональним програмуванням, або ви зможете збити це з упевненістю або зрозуміти, що ваш ухил до OO зумовлений вашим недосвідченістю.

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

ні (навіть незважаючи на те, що обидва однаково об'єктно-орієнтовані, наскільки це стосується класичного "даних разом з функціями, які працюють на ньому").

Ви б спробували переконати свого клієнта, що використання об'єктно-орієнтованого програмування набагато чистіше?

Я думаю, що вам потрібно більше вчити себе парадигмам програмування. Об'єктно-орієнтований запрограмований код не обов'язково є чистішим, а насправді він не є універсальним. Крім того, хороший об'єктно-орієнтований кодер знає, як зробити хорошу роботу, використовуючи процедурну / модульну (З функціональними та деклараційними парадигмами це трохи складніше, але хорошому програмісту не повинно бути надто складно - через читання та відрахування - до прийнятного FP / декларативного рішення.)

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

Або ви б спробували дотримуватися того, що він вимагав, і дайте йому шалений код?

Якщо ви не можете написати гарний код процедурно, я сумніваюся, що ви можете написати хороший код об'єктно-орієнтованим способом. Період. Я не намагаюся судити тут, але це потрібно стверджувати.

Об'єктна орієнтація - це розширення процедурного та модульного програмування. Об'єктно-орієнтована просто дає вам інструменти, які при належному використанні дають вам кращі механізми вирішення питань інкапсуляції, з'єднання, згуртованості та використання коду та повторного використання / розширення.

Але всі ці питання не притаманні та унікальні для ОО. Вони існують у процедурному / модульному коді (та в інших парадигмах з цього приводу.) Це тип питань складності, який, по суті, не залежить від парадигми. Якщо ви не можете впоратися з ними без OO клею, то навряд чи ви зможете з цим впоратися.

=========

Повертаючись до свого початкового питання, чи варто переконати свого клієнта. Це залежить. Як сказав плакат Шон Макміллан, якщо клієнт просто намагається мікро-керувати зусиллями з розробки певного порядку денного (читай, офісна політика), піти геть. Люди, які роблять ці диверсійні проекти, звинувачують когось іншого, або просувають певний порядок денний. Ви не хочете в цьому брати участь.

Інакше, можуть бути інші причини такої вимоги. Багато вбудованих магазинів, правильно чи неправильно, вирішують покласти чимало обмежень на те, що можна зробити з C ++ (наприклад, немає віртуальних методів, не є винятки.) Деколи це робиться у коліна. В інший час для цього є вагомі технічні причини.

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

Насправді немає приводу для доставки шаленого коду, незалежно від парадигми програмування. Якщо ви не можете створити прийнятний код за допомогою однієї парадигми, ви, звичайно, не можете створити прийнятний код загалом.

Ви змішуєте структури даних та об'єктно-орієнтоване програмування (звичайна плутанина в цьому зараженому OO світі)

Якщо все, що вам потрібно зробити, це "відстежувати атрибути даних" у структурі даних та змінювати їх, то майже будь-яка мова, зроблена після 70-х, буде мати гарну підтримку для цього, OO чи ні.

Те, що простіше зробити в ОО, - це грубість

• Спадщина на основі класу (легко створити новий клас, який видає себе за старий)
• Поліморфізм на основі класу (легко додавати нові види мурашок до моделювання згодом)

Якщо у вас немає гострої потреби в одному з них, то в основному будь-яка парадигма програмування повинна вирішити це без зайвих проблем.

мій клієнт сказав, що оскільки він має досвід функціонального програмування, він би хотів, щоб моделювання було зроблено за допомогою функціонального програмування.

(Це ще один приклад того, що соціальне питання помиляється з технічним / дизайнерським питанням.)

Тут є дві можливості:

1. Ваш клієнт очікує, що зможе взяти написаний вами код та адаптувати його або підтримувати його сам після того, як ви закінчите його писати. Якщо так, то вам слід знати набагато більше про "стиль будинку" - функціонал проти ОО є лише вершиною айсберга. Вам або потрібно буде обмежитися стилем програмування, який розуміє ваш клієнт, або вам доведеться навчати свого клієнта в обраних вами стилях. (Одного разу мене попросили створити веб-додаток із CGI, не використовуючи шаблони чи бібліотеки, оскільки клієнт може захотіти внести зміни.)

2. Ваш клієнт намагається контролювати розвиток через певний порядок денний. Це мішок, повний божевільного, з яким ти нічого не хочеш робити. Якщо ви справді надаєте програмне забезпечення «під ключ», клієнту не повинно бути байдуже, чи він зроблений з хом'яків, що працюють на колесах, доки він виконує цю роботу надійно. Дозволити собі таким чином керувати мікроменеджерами - це просто просити біль.

Ви самі вирішите, в якій ситуації ви знаходитесь, і діяти відповідно.

Гм ... я єдиний, хто думає, що "це очевидно тестове завдання / завдання"? .

По-перше - сама задача має свого роду "академічний" характер (імітують аспект поведінки мурашок).

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

Якщо це так, вам краще зробити те, що від вас вимагається - це буде досить приємний досвід навчання, і якщо ви зможете це зробити, ви багато чого навчитеся в процесі ...

Якщо це не так, ви дійсно повинні запитати у себе та / або замовника про міркування про доручення. Якщо міркування є твердими, то зробіть це - ви навчитесь, і вам стане краще як програміст для досвіду. Хто знає - ви навіть можете навчитися любити функціональний стиль через OO.

Якщо пояснення бракує, то всі ставки відключені .. Я не можу порекомендувати вам, що робити.

Ви можете спробувати незалежно від того, щоб реалізовувати вимоги у функціональній мові / стилі, або можете ввічливо відхилити пропозицію, якщо відчуєте щось рибне.

Головне - як тільки ви зрозумієте мотивацію, що стоїть за вимогами, правильний хід дій стає очевидним.

EDIT: Після перегляду діагоналі на посилається PDF, описані там алгоритми, безумовно, здаються більш підходящими для функціонального стилю, а не для OO

У їх запиті щодо використання функціонального програмування є кілька хороших аспектів:

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

Але є і деякі тривожні ознаки:

1. Ви, здається, не готові реалізувати це у функціональному програмуванні. Ви вже трохи застаріли у своїх навичках і не можете йти в ногу зі змінами.
2. Або клієнт очікує, що ти будеш кращим програмістом, ніж ти є насправді. Це означає, що вам може знадобитися знизити їх вимоги, поки ви не зможете це зробити належним чином.

Окремі відповіді вище, що, можливо, ОО не є найкращим рішенням, і в цьому випадку клієнт може мати точку.

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

Ви нічого не писали про мову програмування, що, мабуть, є найважливішим. Різниця між OOP і функціональним програмуванням полягає не тільки в тому, як організовано код, але і самій мові. У випадку високої конкурентоспроможності використовується функціональна мова Erlang, яка має дуже високу перевагу перед, наприклад, Java (вона використовується, наприклад, в чаті Facebook). Рішення OOP може просто вийти з ладу через проблеми з продуктивністю.

Клієнт тут - університет, тому мова - це не лише питання продуктивності / конфігурації, код також може використовуватися для дидактичної роботи зі студентами або для власних досліджень. Тому "переконання" клієнта вибрати іншу парадигму, на мою думку, тут не застосовується. Це або ви можете впоратися із завданням, або не можете (і так, ви не повинні брати цей проект).

Клієнт каже "стрибок", ваша відповідь: __ _ ?

Для мене я б спробував переконати, якщо це має сенс (новий проект), але у мене також є клієнт із 10-річним додатком VB6, який час від часу роблю оновлення ... не збираюся їх переконувати

Трохи перехресно вивчіть свого клієнта (безконфліктно):

Чи справді клієнт знає різницю між OOP та функціональним програмуванням? Чи законні проблеми / запити клієнта?

Якщо "Так": Якщо ви маєте кваліфікацію, робіть те, що вони хочуть, і беруть ваші гроші. Якщо ви не маєте кваліфікації, скажіть їм і нехай вони вирішать, що робити.

Інакше: привіт-хвіст це звідти!

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

Ця функція функціонує до тих пір, поки вона не читає / не записує нічого поза функцією. Якщо функція торкнулася змінної класу, вона більше не була б "функціональною". Перевагою функціонального стилю є те, що більше немає помилок із зміни або недійсного стану. Велика кількість функцій - це лише математичні формули. Це функціональне програмування в двох словах.

До речі, ви можете комбінувати функціональний стиль в рамках об'єктного або орієнтованого дизайну. Наприклад, дві змінні "Point" - це об'єкти зі станом. А функція все ще функціональна! Так !!