Необектно-орієнтоване програмування об'єктно-орієнтованою мовою [закрито]

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

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

PS: Я не прошу тут говорити мені про достоїнства об'єктно-орієнтованого програмування над процедурним програмуванням.

C ++ - це не просто "мова ОО", це мова з багато парадигми. Таким чином, ви можете вирішити чи проти програмування ОО, або змішати їх обоє. Використання OO-методів додає вашій програмі більшої структури - від чого ви отримаєте користь, коли ваша програма досягне певного розміру чи складності. Однак ця додаткова структура приходить до ціни додаткових рядків коду. Тож для "малих" програм найкращий шлях - це найперше їх реалізувати в стилі, що не входить в ООС, і додавати все більше і більше технік OO пізніше, коли програма починає рости з роками (чого, мабуть, не станеться " "програм, але це типовий життєвий цикл для багатьох бізнес-програм).

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

Як професійні програмісти висловлюють судження про те, чи варто йти на ООП чи ні? Це було б дуже корисно для мене.

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

Однак більшість проектів не настільки чіткі. Другий момент рішення - це коли підмножина проекту переросла у величезний клубок висловлювань "if-then" або "case-switch", і особливо, коли для цих тверджень потрібна велика кількість параметрів, щоб правильно запустити. Я відчуваю, що починаю втрачати логіку того, що намагаюся досягти, і код починає відчувати себе тендітним. У цей момент це, як правило, знак того, що настав час перефактурувати код на базові класи із конкретними реалізаціями.

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

Наприклад, ось функціональний стиль у псевдокоді C # -style:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

Але, можливо, ви могли б переписати це на щось подібне:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

А потім сам код:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

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

Але об’єктно-орієнтований стиль справді світить, коли у вас є більше ніж одна дія, ніж просто Confirm()метод, який потрібно виконати. Можливо, у вас є програма ініціалізації, три або більше методів дій, які можна запустити, і Cleanup()метод. Базовий алгоритм ідентичний, за винятком того, що він здійснює виклики у відповідні об'єкти, що реалізують загальний базовий клас. Тепер ви починаєте бачити реальну користь для об'єктно-орієнтованого стилю: базовий алгоритм читати набагато простіше, ніж якби він перевіряв твердження if-then на кожному кроці шляху.

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