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

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

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

Практикуючись у розробці системи, ви почнете відчувати природні стосунки між об’єктами. Код - це лише побічний продукт дизайну. Намалюйте схеми та змоделюйте свою програму у чисто некодовій формі. Які стосунки? Як взаємодіють ваші моделі? Навіть не думайте про код.

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

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

Найпростіший спосіб - вивчити такі поняття, як SOLID, DRY, FIT, DDD, TDD, MVC тощо. Коли ви шукаєте ці абревіатури, це призведе вас до багатьох інших кролячих дір, і як тільки ви закінчите з читанням, ви повинні мати добре розуміння того, що краще об’єктно-орієнтоване програмування!

SOLID подкасти: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

Тверда структура: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

СУХИЙ: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

Потрібно прочитати DDD: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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

Занадто багато людей думають кодувати спочатку, об'єкти, останні.

Ви можете прочитати всі книги, які хочете, але це не навчить вас мислити об’єктно-орієнтовано - для цього потрібна практика та певна методологія.

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

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

3. Коли все це буде зроблено, тоді переживайте про те, як працює клас.

Моя пропозиція полягала б у вивченні чогось іншого.

Вивчіть функціональне програмування та застосуйте те, що ви отримаєте з цього, до ООП. Якщо ви знаєте C ++, пограйте із загальним програмуванням.

Вивчайте не об’єктно-орієнтовані мови.

Не лише тому, що вам слід також використовувати всі ці речі (вам слід), або тому, що вони повинні повністю замінити ООП (вони, мабуть, не повинні), а тому, що ви можете застосувати уроки з них і до ООП.

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

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

Не намагайтеся писати хороший код ООП. Спробуйте написати хороший код. І використовуйте ООП, коли це сприяє досягненню цієї мети.

У багатьох сферах є момент "еврики", коли все якось поєднується.

Пам’ятаю, я відчував розчарування в геометрії середньої школи. Я не знав, яку теорему застосувати на кожному кроці доведення. Але я продовжував це робити. Я детально вивчив кожну теорему та вивчив, як вони застосовувались у різних прикладах доказів. Оскільки я розумів не лише визначення кожної теореми, а й те, як ними користуватися, я створив "набір інструментів" із звичних прийомів, які міг би витягнути за потреби.

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

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

Вивчіть іншу мову! Більшість розробників, що використовують лише Java (як приклад), мають лише обмежене розуміння ОО, оскільки вони не можуть відокремлювати мовні особливості та поняття. Якщо ви цього ще не знаєте, погляньте на python. Якщо ви знаєте python, вивчіть Ruby. Або виберіть одну з функціональних мов.

Aswer - у вашому запитанні;)

Практика, практика, практика.

Перегляньте власний код і вчіться на помилках.

TDD мені найбільше допоміг у покращенні загального набору навичок, включаючи ООП.

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

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

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

Мовні дизайнери по-різному інтерпретували "Об'єктно-орієнтоване програмування". Наприклад, подивіться, як його визначив Алан Кей, людина, яка вперше вжила термін ООП:

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

(Цитується з http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

Може здатися дивним, що він не розглядає мови Java та C ++ OOP! Але як дизайнер однієї з перших і найкращих мов ООП (Smalltalk), він має на це свої вагомі причини. Чому Алан Кей вважав Lisp об’єктно-орієнтованою мовою, а не Java? Це питання вимагає серйозного розгляду всіма, хто стверджує, що розуміє ООП.

Ерланг має зовсім іншу реалізацію ООП, у Схеми інша. Варто розглянути всі ці альтернативні погляди. По можливості вивчіть усі ці мови! Це дасть вам широкий кругозір, покладе до вашої руки нові потужні інструменти та зробить вас кращим програмістом.

Я підсумував свої експерименти з впровадженням мови ООП, базуючись на ідеях, запозичених у Smalltalk, Scheme та Erlang у цій статті .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

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

Кожен із цих видів речей, які ви вирішили відстежити, стає класом.

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

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

Занадто багато інформації про об’єкти. Найголовніше - оволодіти основами, і все легше стає на свої місця.

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

Це абсолютна база. Є ще три концепції, якими ви повинні абсолютно володіти:

Спадщина - Це все про повторне використання коду.

Інкапсуляція - це все про приховування реалізації від інтерфейсу. Простіше кажучи, все повинно бути приватним, доки не буде доведено протилежне.

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

Якщо ці поняття дуже добре зрозумілі, у вас все буде добре.

Остання остання порада: Ви згадуєте найкращі книги. Ви читали " Мислення на Яві " Брюса Еккеля? Я рекомендую цю книгу навіть людям, які починають працювати в .Net, оскільки концепції ООП чітко викладені.

Станьте спритнішими, навчіться тестуванню на випробування та вивчіть дизайн доменного стилю. Я пропоную книгу "Управління доменом: вирішення складності в серці програмного забезпечення", хоча в деяких моментах це трохи важко.

Навички ООП з’являються з часом. Читання 1, 2 ... 10 книг це не вирізає. Потренуйтеся написати якийсь код. Якщо ви працюєте в середовищі програмування ... це може бути корисно. Якщо не спробувати потрапити в один. Запропонуйте розробити деякі додатки безкоштовно. Треба забруднити руки. Пам’ятайте ... жодне додаток не є ідеальним з нуля.

Крім того ... не захоплюйтеся ООП занадто сильно ... це часом з часом. Турбуйтеся про розробку повністю функціональних додатків.

Спробуйте трохи програмування на Self , одній з найчистіших мов OO навколо. Насправді настільки чистий, що в ньому навіть немає класів, лише об’єкти. Він також не має змінних, полів, статики, атрибутів, лише методи. Цікавим є також той факт, що кожен об’єкт у системі - це також об’єкт на екрані і навпаки.

Деякі з цікавих статей про Self - це побудова додатків на основі прототипів за допомогою SELF 4.0 (навчальний посібник), Self: сила простоти та організація програм без занять . Крім того, Self: The Video (Рендалл Б. Сміт; Дейв Унгар) приголомшливий, оскільки двоє дизайнерів мови пояснюють ідеї Селфа.

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

OO нарешті натиснув на мене після того, як я спробував запрограмувати банківську програму, яка обробляла транзакції, обчислювала відсотки та відстежувала все це. Я зробив це під час вивчення Java. Я б запропонував просто спробувати, завершити, а тоді, коли закінчите, перегляньте ДОБРЕ рішення і подивіться, що ви могли б зробити краще.

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

Закатайте рукави і кодуйте!

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

Чи читали ви розділ про ОО з першого видання книги "Ефективний C ++" Скотта Майерса? Це не дійшло до наступних видань, але це було чудове пояснення. Заголовок в основному був "сказати те, що ви маєте на увазі, означати те, що ви говорите" про відповідні умови.

Насправді, ви можете побачити мою відповідь на подібне запитання тут .

HTH

ура,

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

Кодуйте речі таким чином, що якщо ви хочете змінити 1 фрагмент коду, вам потрібно змінити лише цей 1 фрагмент коду, а не 50 його екземплярів.

ООП - це не те, що ви можете опанувати, прочитавши тисячі книг. Швидше ви повинні відчувати внутрішні поняття. Читайте що завгодно, але намагайтеся відчути прочитане. Побудуйте концепцію в глибині думки і спробуйте зіставити їх з новими сценаріями. Перевіряйте та оновлюйте свої концепції, досліджуючи нові речі.

Удачі!

пиво допомагає. серйозно. лягайте на диван із накладкою для каракулів розміром А3, ручкою та пивом. Замкніть назовні собаку, кота та дружину. І думайте про проблему, розслабившись. Навіть не наважуйтесь намалювати на ньому API!

Блок-схеми, картки відповідальності (CRC) та пиво (але не надто багато) проходять довгий шлях.

Найпростіший спосіб рефакторингу коду - це не спочатку.

http://misko.hevery.com/code-reviewers-guide/

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

Ви також захочете вивчити тверді принципи: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

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

Ви вже можете писати код таким чином і не знати його - якщо так, чудово. Але якщо вам потрібна мета, до якої потрібно прагнути, це золотий стандарт.

Здаватися! Навіщо вам це, що ООП? Просто напишіть якийсь корисний додаток. Не відповідає використанню ООП, процедурного або функціонального підходу.

Як би ви не вибрали мову Python, яку ви обираєте, вона повинна бути придатною для практики.

Ви моя цільова аудиторія. Подивіться на Навички навичок в ОО-дизайні

Можливо, це може допомогти.