Як практикувати об’єктно-орієнтоване програмування? [зачинено]

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

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

Тепер у орієнтації на об’єкти у нас є маса додаткових речей. Справа не лише в тому, щоб продумати алгоритм, а глибше проаналізувати вимоги, написати випадки використання, з’ясувати діаграми класу, властивості та методи, налаштувати ін'єкцію залежностей та багато чого іншого.

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

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

Через те, який хороший спосіб практикувати орієнтацію на об'єкт?

Тепер у орієнтації на об’єкти у нас є маса додаткових речей.

Ні, ти не ...

Справа не лише в тому, щоб продумати алгоритм, а глибше проаналізувати вимоги, написати випадки використання, з’ясувати діаграми класу, властивості та методи, налаштувати ін'єкцію залежностей та багато чого іншого.

Жодна з цих речей не потрібна для практикування об'єктно-орієнтованого програмування.

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

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

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

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

Гарне питання. Звичайно, те, що ви говорите, це те, що практикувати OOP насправді означає практикувати всі ці речі (аналіз вимог, використання кейсів, шаблонів дизайну тощо), що є істинним і на перший погляд може здатися жахливим.

Моєю порадою було б розпочати свої практичні заняття, пам’ятаючи про дві речі: тестовий розвиток та принцип єдиної відповідальності .

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

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

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

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

Це допоможе вам розвинути набагато краще розуміння відносин IS-A та HAS-A , що, мабуть, є найбільш важливою класифікацією в будь-якому дизайні OOP (і, незважаючи на це, все ще здається, що це щось, з чим бороються багато досвідчених програмістів мови OOP ). Якщо ви опановуєте IS-A / HAS-A, існує також ІМ-ВПРОВАДЖЕННЯ В УМОВИ (Я також бачив опис як IS-KIND-OF-A: ^)

Серйозно кажучи, наступна поїздка до супермаркету, уявіть собі, що хтось дав вам завдання написати симуляцію OOP про місце ...

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

Що стосується ООП, то насправді все стосується практики та прагнення до вдосконалення. Рідко хтось отримує це прямо з нуля. Таким чином, ітерації відбуваються протягом усього життєвого циклу проекту.

Додамо трохи термінології, об'єктно-орієнтованого аналізу та об'єктно-орієнтованого дизайну , як це робив Пітер Коад у 1990-х.

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

Іноді це проект для однієї людини, і тоді ти повинен носити всі шапки (але не обов’язково всі одночасно). Я величезний шанувальник тестових розробок для власних особистих проектів (див. Рекомендацію Франка), але це стосується не лише об'єктно-орієнтованої розробки програмного забезпечення.

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

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

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