Розв’язка класів з інтерфейсу користувача

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

У багатьох книгах програмування я натрапив на приклад "Форма", який показує спадщину. Форма базового класу має метод малювання (), згідно з яким кожна форма, наприклад, коло і квадрат, переосмислюються. Це дозволяє здійснити поліморфізм. Але чи не дуже залежить метод draw () від того, яким є інтерфейс користувача? Якщо ми пишемо цей клас для скажімо, Win Forms, ми не можемо повторно використовувати його для консольного або веб-додатка. Це правильно?

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

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

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

У багатьох книгах програмування я натрапив на приклад "Форма", який показує спадщину. Форма базового класу має метод малювання (), згідно з яким кожна форма, наприклад, коло і квадрат, переосмислюються. Це дозволяє здійснити поліморфізм. Але чи не дуже залежить метод draw () від того, яким є інтерфейс користувача?

Знову ж, не обов’язково. Якщо ви можете створити інтерфейс (drawPoint, drawLine, встановити Color тощо), ви можете майже пропустити будь-який контекст для малювання речей на щось до форми, наприклад, в конструкторі фігури. Це дозволить фігурам намалювати себе на консолі чи будь-якому полотні.

Якщо ми пишемо цей клас для скажімо, Win Forms, ми не можемо повторно використовувати його для консольного або веб-додатка. Це правильно?

Ну, це правда. Якщо ви пишете UserControl (не взагалі клас) для Windows Forms, ви не зможете використовувати його з консоллю. Але це не проблема. Чому ви очікуєте, що UserControl для Windows Forms працюватиме з будь-якими видами презентацій? UserControl повинен зробити одне і зробити це добре. Це пов'язано з певною формою викладу за визначенням. Зрештою, користувачеві потрібно щось конкретне, а не абстракція. Це може бути частково справедливо для фреймворків, але це для програм кінцевих користувачів.

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

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

Ви знаєте, екстремальні програмісти люблять своє ставлення до ЯГНІ . Не намагайтеся писати все загально і не намагайтеся надто сильно намагатися зробити все загальним призначенням. Це називається перенапруженням і в кінцевому підсумку призведе до цілком перекрученого коду. Дайте кожному компоненту рівно одне завдання і переконайтеся, що він добре його виконує. Введіть абстракції там, де це потрібно, де ви очікуєте, що щось зміниться (наприклад, інтерфейс для контексту малювання, як зазначено вище).

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

Редагувати: Якщо ви хочете прочитати більше про архітектуру та методи дизайну, які можуть забезпечити кращі практики, пропоную прочитати відповідь @Catchops і прочитати про практику SOLID у Вікіпедії.

Крім того, для початку я завжди рекомендую наступну книгу: Head First Design Patterns . Це допоможе вам зрозуміти методи абстрагування / практики проектування OOP, тим більше, ніж книга GoF (що чудово, це просто не підходить початківцям).

Ви точно маєте рацію. І ні, ви "намагаєтеся чудово" :)

Читайте про принцип єдиної відповідальності

Ваша внутрішня робота над класом та те, як ця інформація повинна бути представлена ​​користувачеві, є двома обов'язками.

Не бійтеся розлучати заняття. Рідко проблема - це занадто велика абстракція та розв'язка :)

Дві дуже актуальні моделі - це модель-контролер перегляду для веб-додатків та Model View ViewModel для Silverlight / WPF.

Я багато використовую MVVM, і на мою думку, клас бізнес-об’єкта ніколи не повинен знати нічого про користувальницький інтерфейс. Зрозуміло, що їм може знадобитися знати SelectedItemабо IsChecked, або IsVisible, і т. Д., Але ці значення не потрібно прив'язувати до якогось конкретного інтерфейсу і можуть бути загальними властивостями для класу.

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

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

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

Ну ... ви праві, спостерігаючи, що якщо ви хочете намалювати коло на iPhone, це буде інакше, ніж намалювати його на ПК під керуванням Windows. У вас ОБОВ'ЯЗКОВО (у цьому випадку) конкретний клас, який малює одну свердловину на iPhone, а іншу, яка малює одну свердловину на ПК. Ось тут основний OO, який належить до спадкування, що всі ці приклади фігур руйнуються. Ви просто не можете зробити це лише успадкуванням.

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

Я бачив реферат щодо принципів SOLID . Це чудово. "S" - це принцип єдиної відповідальності. АЛЕ "D" означає інверсію залежності. Тут може бути використана інверсія схеми управління (введення залежності). Це дуже потужно і може бути використане для відповіді на питання, як створити систему, яка може намалювати коло для iPhone, а також для ПК.

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

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

Удачі!

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

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

У цьому випадку ви все ще можете використовувати MVC / MVVM та вводити різні реалізації інтерфейсу, використовуючи загальний інтерфейс:

public interface IAgnosticChartDrawing
{
   public void Draw(ChartProperties chartProperties);
   event EventHandler ChartPanned;
}

public class GuiChartDrawer : UserControl, IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //GDI, GTK or something else...
    }

    //Implement event based on mouse actions
}

public class ConsoleChartDrawer : IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //'Draw' using characters and symbols...
    }

    //Implement event based on keyboard actions
}

IAgnosticChartDrawing guiView = new GuiChartDrawer();
IAgnosticChartDrawing conView = new ConsoleChartDrawer();

Model model = new FinancialModel();

SampleController controllerGUI = new SampleController(model, guiView);
SampleController controllerConsole = new SampleController(model, conView);

Таким чином ви зможете повторно використовувати логіку контролера та моделі, одночасно додаючи нові типи графічного інтерфейсу.

Для цього є різні моделі: MVP, MVC, MVVM тощо.

Приємна стаття від Мартіна Фаулера (велике ім’я), яку слід прочитати - це архітектура GUI: http://www.martinfowler.com/eaaDev/uiArchs.html

Про MVP ще не згадували, але це, безумовно, заслуговує на посилання: погляньте на це.

Це шаблон, запропонований розробниками Google Web Toolkit для використання, він дійсно акуратний.

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

http://code.google.com/webtoolkit/articles/mvp-architecture.html

http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

Однією з переваг дотримання цього чи подібних підходів, які тут недостатньо наголошені, є перевірка! У багатьох випадках я б сказав, що це головна перевага!

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

Розглянемо систему програмування, яка могла б відправляти дві або більше змінних:

poly_draw(Shape s, Renderer r)

а також припустимо, що система може дати вам висловити poly_draw для різних комбінацій типів Shape та Renderer. Тоді було б легко придумати класифікацію форм і рендерів? Засіб перевірки типів якимось чином допоможе вам з'ясувати, чи існували комбінації форм і візуалізації, які, можливо, ви пропустили.

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

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

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

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

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

Хоча рік-два тому я теж почувався невпевненим у цьому. Я передумав після вивчення дискусій на форумі Sun щодо моделей та дизайну ОО.

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

Але чи не дуже залежить метод draw () від того, яким є інтерфейс користувача?

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

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

Обмеження можливостей малювання / візуалізації

Оскільки, якщо код малювання вищого рівня залежить лише від чогось дуже абстрактного, то ця абстракція може працювати (через заміну конкретних реалізацій) на всіх платформах, на які ви плануєте націлитись. Як надуманий приклад, якийсь дуже абстрактний IDrawerінтерфейс може бути реалізований як в консольній, так і в інтерфейсі API інтерфейсу, щоб робити такі речі, як форми сюжету (реалізація консолі може трактувати консоль як деяке 80xN "зображення" з ASCII art). Звичайно, це надуманий приклад, оскільки це, як правило, не те, що ви хочете зробити, це обробляти консольний вихід, як буфер зображення / кадру; як правило, більшість потреб користувача викликають більше текстових взаємодій у консолях.

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

Але скажіть, що ви намагаєтесь вилучити деталі горі, які залежать від Playstation Portable, iPhone, XBox One та потужного ігрового ПК, тоді як ваші потреби полягають у використанні найсучасніших методів 3D-рендерінгу / затінення в режимі реального часу на кожному. . У цьому випадку спроба розробити один абстрактний інтерфейс для абстрагування деталей візуалізації, коли основні апаратні можливості та API змінюються настільки дико, що майже впевнено призводить до величезного часу проектування та повторного проектування, велика ймовірність повторних змін дизайну з непередбачуваними. відкриття, а також рішення найменшого загального знаменника, яке не може використати повну унікальність та потужність базового обладнання.

Створення залежних потоків до стабільних, "Легких" конструкцій

В моєму полі я в тому останньому сценарії. Ми орієнтовані на безліч різноманітних апаратних засобів, що мають принципово різні основні можливості та API, і намагатися придумати одну рендеринг / малювання абстракції, щоб керувати ними всіма, є безнадійними прикордонними (ми можемо стати всесвітньо відомими, просто роблячи це ефективно, як це була б гра зміна в галузі). Тому останнім , що я хочу в моєму випадку це як аналогова Shapeабо Modelабо Particle Emitterщо вміє малювати себе, навіть якщо він висловлює , що малюнок на найвищому рівні і , можливо , найбільш абстрактний спосіб ...

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

Складне залежить від легкого, не просто залежить від складного

Тож те, що ми робимо замість цього, - змусити залежності залежати від речей, які легко спроектувати. Набагато простіше спроектувати абстрактну "Модель", яка орієнтована лише на зберігання таких речей, як багатокутники та матеріали, і зробити цю конструкцію правильною, ніж спроектувати абстрактний "Візуалізатор", який може ефективно реалізовуватися (за допомогою змінних підтипів бетону) для сервісного малювання запити рівномірно для апаратних засобів, настільки ж відмінних, як PSP від ​​ПК.

Таким чином ми перевертаємо залежності від речей, які важко спроектувати. Замість того, щоб абстрактні моделі знали, як звернути себе до абстрактного дизайну рендерінгу, від якого всі вони залежать (і порушити їх реалізацію, якщо цей дизайн зміниться), ми натомість маємо абстрактного рендерінга, який знає, як намалювати кожен абстрактний об'єкт на нашій сцені ( моделі, випромінювачі частинок тощо), і тому ми можемо потім реалізувати підтип OpenGL-рендеріра для таких ПК, як RendererGlдля інших PSP RendererPsp, інших, для мобільних телефонів тощо. У такому випадку залежність залежить від стабільних конструкцій, їх легко виправити, від рендерінгу до різних типів сутностей (моделей, частинок, текстур тощо) на нашій сцені, а не навпаки.

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

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

Принцип єдиної відповідальності

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

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

Гордість для розробників

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