Є об'єктивним принципом єдиної відповідальності?


17

Розглянемо двох дизайнерів інтерфейсу, які хочуть створити «привабливі для користувача» конструкції. "Привабливість користувача" - це поняття, яке не є об'єктивним і є лише у свідомості дизайнерів. Таким чином, дизайнер A міг, наприклад, підібрати червоний колір, а дизайнер B - синій. Дизайнер A створить макет, який повністю відрізняється від дизайнера B тощо.

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


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

Відповіді:


12

Хороше запитання і те, що я часто обмірковував.

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

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

(PS. Відредагував цю відповідь, оскільки остаточне запитання ОП задає протилежне заголовку питання.)


5

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

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

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


Хороший аналіз @Guffa. +1. Мені сподобалася ідея не бути всеохоплюючою. Так, SRP лише каже вам, щоб спробувати зробити все відповідальним за одне питання. Але це не говорить вам, де знаходиться межа відповідальності.
Saeed Neamati

2

Застосування принципу є суб'єктивним. Однак "суб'єктивне" не прирівнюється до "переваги" так само, як це робить естетика.

Є очевидні крайнощі. Клас із точно одним методом із лише кількома рядками коду, який не викликає жодних інших класів, безперечно слід за SRP. З іншого боку, клас з двома методами, той, який містить повну реалізацію електронної пошти через необроблені сокети, а інший, що створює форму GUI, безумовно не слідкує за SRP.

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

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


0

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


0

SRP об'єктивна; реалізації є суб'єктивними

дві реалізації з точно однаковою функціональністю можуть використовувати абсолютно різні внутрішні структури, що призводить до різних класів і методів, і обидві можуть задовольнити SRP

якщо вони використовують однакові методи та стан, і обидва нормалізуються (мінімально / не надлишково), то, теоретично, вони опиняться однаковими класами та методами в SRP.

але я не можу цього довести. І все-таки.

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