Як ви розробляєте об'єктно-орієнтовані проекти? [зачинено]


231

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

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

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

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

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

Конкретно мене цікавить, які методи ви використовуєте? Який процес ви слідуєте, як правило, виходить хороший, чистий дизайн, який буде тісно представляти кінцевий продукт?


2
Я вважав, що Code Complete є досить корисним у цій темі - зокрема, глави 5.3 та 5.4 (де є конкретніші пропозиції) та вся глава 6. Однак я фактично не робив жодного дизайну коду для великого проекту.
Пол Д. Вейт

1
Я можу порекомендувати пройти курс об’єктно-орієнтованого дизайну на Java. На UDEMY udemy.com/mastering-object-oriented-design-in-java/… є чудовий . Я думаю, що це, безумовно, може вам допомогти. Ще один чудовий ресурс - це спробувати об'єктно-орієнтовану проблему з банкоматом. Ви можете це google.
Кінський голос

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

Відповіді:


199

Кроки, які я використовую для початкового проектування (переходу до діаграми класів), є:

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

  2. Складіть розповідь з окремих випадків використання.

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

  4. Відмовтеся від повторних іменників та виділіть загальну функціональність.

  5. Створіть діаграму класів. Якщо ви розробник Java, в NetBeans 6.7 від Sun є модуль UML, який дозволяє проводити діаграми, а також інженерну програму, і це БЕЗКОШТОВНО. Eclipse (відкритий код Java IDE) також має рамки моделювання, але я не маю цього досвіду. Ви також можете спробувати ArgoUML, інструмент з відкритим кодом.

  6. Застосовуйте принципи OOD для організації занять (виділяйте загальну функціональність, будуйте ієрархії тощо)


6
Це дійсно корисна методика, особливо коли у вас немає справжньої ручки щодо проблемної області. Однак він рідко створює оптимальну архітектуру.
NomeN

1
Я можу порекомендувати пройти курс об’єктно-орієнтованого дизайну на Java. На UDEMY udemy.com/mastering-object-oriented-design-in-java/… є чудовий. Я думаю, що це, безумовно, може вам допомогти. Ще один чудовий ресурс - це спробувати об'єктно-орієнтовану проблему з банкоматом. Ви можете це google.
Кінський голос

1
Де ви це дізнаєтесь? Чи можете ви надати джерело цього?
Канагавелу Сугумар

68

Додавши до того, що Скотт Девіс мав сказати:

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

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

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

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

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

Всього два мої копійки. Сподіваємось, це корисно.


19

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

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

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

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

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

Отже, підбиваючи підсумки:

  1. Під час ітерації ви відчуєте смак цього та навчитесь
  2. Під час другої ітерації ви очищаєте продукт і готуєте його до майбутнього
  3. У ітерації три ви додаєте нові функції та дізнаєтесь більше
  4. goto 2

16

Найцікавіше джерело, про яке я знаю з цього приводу, це частина D « Об’єктно-орієнтована побудова програмного забезпечення», 2-е видання Бертран Меєра.

Частина D: Об'єктно-орієнтована методологія: добре застосовувати метод

19: Про методологію, 20: Шаблон проектування: багатопанельні інтерактивні системи, 21: Тематичне дослідження спадкування: "скасувати" в інтерактивній системі, 22: Як знайти класи , 23: Принципи дизайну класів, 24: Добре використання успадкування , 25: Корисні методи, 26: Почуття стилю, 27: Об'єктно-орієнтований аналіз, 28: Процес побудови програмного забезпечення, 29: Навчання методу

Цікаво, що глава 22. Як знайти заняття доступний в Інтернеті.


12

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

Для OOP ваші класи повинні описувати важливі відомості та спосіб їх взаємодії.

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

Це просто розширення: точно знайте, що ви намагаєтеся зробити.


12
Поведінка об'єкта важливіша за дані. Це прямий результат інкапсуляції: серце об'єктно-орієнтованого програмування. Експозиція даних (з таких мов, як C та Pascal) призводить до систем, які важко підтримувати (покращувати та налагоджувати) просто тому, що ви ніколи не знаєте, яке інше місце в системі змінює дані. OOP не стосується даних; OOP - це про поведінку. Це важлива відмінність.
Дейв Джарвіс

Це важлива відмінність, але це не означає, що поведінка важливіша за дані.
Johnny

Що стосується OOD, я, як правило, починаю з дизайну моделей після уточнення вимог, що дає мені основне уявлення про те, як організації повинні бути організовані, як стосунки між ними. У той же час, у мене є основне уявлення про те, що операції можуть відбуватися в кожній організації. Після чорнової картинки про моделі ми можемо переглянути вимоги та перевірити, чи щось нам не вистачає. І тоді буде легше повернутися до рівня класу та рівня контролера.
Джошуа

10

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

http://behaviour-driven.org/


1
+1 Використання тестових / поведінкових / доменних розробок дозволяє створювати класи в процесі роботи, щоб уникнути проблемної методології великого переднього проектування водоспаду.
Халвард

8

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

Спочатку спробуйте подумати з більш високого рівня абстракції. Подумайте про основні компоненти та їх обов'язки (їх інтерфейс з іншими компонентами), подивіться на деякі архітектурні зразки для натхнення (ні, не шаблони дизайну, це занадто низький рівень! MVC і Multi-Tier - це приклади архітектурного шаблону). Для досить великих проектів така точка зору повинна містити близько 3-5 компонентів.

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

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

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

Коротше кажучи: візьміть на себе принцип приховування інформації та інформації та підніміть її на інший рівень!


PS: Робіть багато ескізів під час проектування, це як справжня архітектура!

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


7

Метод, який я використовував у реальних проектах з розумним успіхом, - це дизайн, керований відповідальністю, натхненний книгою Wirfs-Brock.

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

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

Знати, коли зупинитись - це питання про судження (яке приходить лише з досвіду).


+1 для дошки, видатна річ: DI вирішує 80% проблем, сидячи перед дошкою, просто дивлячись на це і думаючи: "що було б найкраще?"
usoban

7

Шаблони дизайну

Шаблони креативного дизайну

Singleton - Переконайтеся, що створено лише один екземпляр класу та надайте глобальну точку доступу до об'єкта.

Фабрика (спрощена версія Factory Method) - створює об'єкти, не піддаючи клієнту логіку ідентифікації та посилається на новостворений об'єкт через загальний інтерфейс.

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

Abstract Factory - пропонує інтерфейс для створення сімейства пов'язаних об’єктів, не чітко вказуючи їх класи.

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

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

Шаблони поведінкового дизайну

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

Команда - інкапсулює запит у об’єкт, дозволяє параметризувати клієнтів різними запитами та дозволяє зберегти запити в черзі.

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

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

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

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

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

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

Відвідувач - представляє операцію, яка повинна виконуватися на елементах об’єктної структури / Visitor дозволяє визначити нову операцію без зміни класів елементів, над якими вона працює.

Нульовий об’єкт - надайте об’єкт як сурогат за відсутністю об'єкта заданого типу. / Null Object Pattern забезпечує інтелектуальну поведінку нічого, приховуючи деталі від своїх співробітників.

Структурні конструкції

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

Міст - Складіть об’єкти в дерева структури, щоб представити частину цілу ієрархію. / Композиція дозволяє клієнтам обробляти окремі об'єкти та композиції об'єктів рівномірно.

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

Декоратор - додайте додаткові обов'язки динамічно до об'єкта.

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

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

Проксі - надайте «Заполнитель» для об'єкта для управління посиланнями на нього.


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

5

Я б рекомендував вам використовувати BlueJ, а також ActiveWriter для навчання, а також для розвитку хорошого розуміння об'єктів. Рекомендована книга - також приємний ресурс.

З Вікіпедії :

alt текст

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

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

alt текст http://www.ryanknu.com/ryan/bluej.png

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

alt текст
(джерело: altinoren.com )


1
Я використовував синій J ... це безумовно корисно, але як це допомагає мені розробляти класи та їхні стосунки?
Віктор

1
Я думаю, що мені стало зрозуміло бачити всю картину про те, як ідентифікувати класи та як їх візуально співвідносити, на своїх перших кроках я експериментував, як було представлено коди об’єктів та як зрозуміти, як мислити в об’єктах. Я пам'ятаю, коли я приділяв час, щоб з'ясувати "є" і "має", і UML був чудовою допомогою. Відтоді я використовую цей візуальний інструмент для проектування своїх об'єктів, і коли я виявив ActiveWriter, я був дуже задоволений, оскільки BlueJ не має генерації коду, і цей інструмент це робить, просто для того, щоб застосувати мій аргумент, я думаю, що візуально у вас є більш широкий підхід до рішення.
Нельсон Міранда

4

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

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

І останнє - спробуйте прочитати це: Алгоритм творчого мислення


4

Просто цитуючи http://www.fysh.org/~katie/computing/methodologies.txt

І в основі RUP - невелика площа, де ви повинні використовувати OO таланти дизайну .... якщо у вас їх немає, це як би мати методологію для бігу на 100 м.

"Крок 1: пишіть про біг по-справжньому швидко. Крок 2: Перейдіть і намалюйте план бігової доріжки. Крок 3: ідіть і купуйте дуже тісні шорти з лайкри. Крок 4: Біжіть дійсно, дійсно, дуже швидко. Крок 5: спочатку перехрестіть лінію "

Саме той крок 4 найважчий. Але якщо ви зробите великий акцент на 1,2,3 та 5, можливо, ніхто цього не помітить, і тоді ви, мабуть, могли б заробити багато грошей, продаючи методологію, щоб бути спортсменами, які думають, що є якийсь "секрет" бути 100 м бігун


4

Ви задали питання, яке багато авторів використовують для написання книги. Існує ряд методологій, і вам слід вибрати ту, яка вам здається «найкрасивішою».
Я можу порекомендувати книгу "Дизайн, керований доменом" Еріка Еванса. Також перегляньте сайт dddcommunity.org .


3

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

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

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

Але ви не маєте досвіду, читаючи лише книги. Вам слід вчитися, працюючи в хорошій групі під хорошим керівництвом.

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

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


3

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

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

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


2
  1. вивчення та освоєння шаблонів дизайну.
  2. Далі дізнайтеся про дизайн, керований доменом
  3. Після цього вивчіть збір вимог

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

  1. Ви знаєте про крок 3. Вам потрібно його освоїти. Я маю на увазі, завдяки великій практиці зробити так, щоб це стало вашим другим характером. Це тому, що метод, який ви вивчаєте, просто проти того, як ми звикли. Тож вам потрібно справді оволодіти цим. В іншому випадку ви завжди знайдете, що повернетесь до свого оригінального способу здійснення справи. Це якось схоже на Test Driven Process, коли багато розробників Java віддають його після кількох спроб. Якщо вони цілком не опановують це, інакше це просто тягар для них

  2. Пишіть випадки використання, особливо для альтернативного курсу. Черговий курс займає більше 50% нашого часу розвитку. Зазвичай, коли ваш прем'єр-міністр призначить вам завдання, наприклад, створити систему входу, він подумає, що це прямо вперед, ви можете взяти 1 день, щоб закінчити його. Але він ніколи не враховує, що вам потрібно врахувати: 1. що робити, якщо користувач вводить неправильний пароль, 2. що робити, якщо користувач 3 рази вводить неправильний пароль, 3. що робити, якщо користувач не вводить ім’я користувача і т.д. Вам потрібно перерахувати їх та показати його своєму прем'єр-міністру, попросити його перенести термін.


2

Я боюся, що це не відповідь, яку люблять чути люди . У будь-якому випадку, дозвольте висловити свою думку.

OOP слід розглядати як одну з парадигм, а не як вищу парадигму. OOP добре підходить для вирішення певних проблем, наприклад, розробки бібліотеки графічного інтерфейсу. Він також вписується в стиль розробки програмного забезпечення, за яким зазвичай йдуть великі компанії з програмного забезпечення - елітна команда дизайнерів або архітекторів викладає дизайн програмного забезпечення в діаграмах UML або іншому подібному середовищі та менш освіченій команді розробниківперевести цю конструкцію у вихідний код. OOP пропонують невелику користь, якщо ви працюєте в самоті або з невеликою командою високо талановитих програмістів. Тоді, краще використовувати мову, яка підтримує декілька парадигм і допоможе швидко придумати прототип. Python, Ruby, Lisp / Scheme тощо - хороший вибір. Прототип - ваш дизайн. Тоді ви вдосконалюєтесь на цьому. Використовуйте парадигму, яка найкраще вирішити проблему. При необхідності оптимізуйте гарячі точки із розширеннями, написаними на C чи іншій мові системи. Використовуючи одну з цих мов, ви також отримуєте розширеннябезкоштовно, не тільки на рівні програміста, але і на рівні користувача. Такі мови, як Lisp, можуть динамічно генерувати та виконувати код, а це означає, що ваші користувачі можуть розширити додаток, написавши невеликі фрагменти коду мовою, що кодується саме програмне забезпечення! Або якщо ви вирішили написати програму на C або C ++, подумайте про вбудовування інтерпретатора для такої малої мови, як Lua. Розкрийте функції як плагіни, написані цією мовою.

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

Підводячи підсумок, мій кращий спосіб написання програмного забезпечення:

  1. Використовуйте динамічну мову.
  2. Напишіть дизайн (прототип) самою цією мовою.
  3. При необхідності оптимізуйте певні області за допомогою C / C ++.
  4. Забезпечити розширення за допомогою інтерпретатора самої мови реалізації.

Остання функція дозволяє програмному забезпеченню легко адаптуватися до конкретних потреб користувача (включаючи мене!).


Це навряд чи порадити, як проектувати
NomeN

2
Я використовую подібний підхід. Щоб не перевантажувати складність, починайте з виду вертольота. Мені подобається ескіз з 8-20 функцій. Якщо я починаю отримувати більше, то дивлюсь, як розділити на підсистеми. Після того, як я отримаю такий вигляд високого рівня, я розкладу кожну функцію на 8-20 підфункцій і т. Д. Переглядаючи, якими цими функціями керують, я отримую класи вищого рівня. Саме тоді я починаю викладати скелетну систему в Python, також виконавчий псевдо-код. Це разом із блоками коментарів - це моя "виконувана специфікація", яка потім прогресивно удосконалюється.
CyberFonic

2

Я використовую тестово-керований дизайн (TDD). Написання тесту спочатку допомагає привести вас до чистого та правильного дизайну. Дивіться http://en.wikipedia.org/wiki/Test-driven_development .


2
TDD допомагає спочатку візуалізувати вашу систему як чорний ящик із зразком введення та виводу. Але саме по собі це не допомагає вам придумати дизайн системи. Я мав на увазі для одиничного тестування, для початку потрібно створити інтерфейс класу для тестування
Вісенте Болея


1

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


1
Мені подобаються блок-схеми, коли я зациклююся на питанні. Іноді це допомагає мені подумати про проблему по-іншому.
користувач133018

Замість або як діаграми потоків "Діаграми потоку даних" (DFD) мають набагато більш високий рівень: вони більше схожі на діаграму розгортання UML і підходять для отримання розуміння функціональності системи (тобто введення даних у систему та виведення даних, внутрішнє та зовнішнє зберігання даних та обробка даних) та архітектура. Діаграми потоку (IMHO) ближче за обсягом до моделювання однієї функції з операторами if-then-else.
ChrisW

Так, я використовую обидві частини часу, як правило, діаграми потоку в основному для того, коли я намагаюся з’ясувати певну проблему.
користувач133018

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


1

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

Справді. Поспостерігайте, як діяла б бічна аптека чи лікарня.

Сведіть проблему вашого домену на щось зрозуміле для вас; те, до чого ви можете ставитися.

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

Стосовно до домену та розуміння його на високому рівні є ключовою частиною будь-якого дизайну.


1

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.