Чи є проблема виявлення для розробників проблемою при використанні принципів SOLID?

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

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

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

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

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

Я переглянув google / binged і навіть yahoo! D, але я не знайшов підтвердження цієї проблеми.

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

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

Чи є кращий спосіб, який не потребує інтимних знань про середній рівень, де відбувається реальна реалізація SOLID?

В основному те, що я запитую, чи є спосіб дозволити розробникам типу CRUD продовжувати бути розробниками CRUD у дуже складній системі

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

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

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

Отже, замість того, щоб писати клас, який викривав методи, я писав класи, які представляли методи (виявилося, що це "Command" з GoF). Замість того, щоб робити роботу для клієнта, всі мої основні класи заявок стали стійкими держателями, і вони стали набагато коротшими за довжиною. Кожен раз, коли мені доводилося додати новий метод інтерфейсу до самої служби, я просто створив новий клас, у якому був метод Execute (), який запускав усе. Якщо декілька команд мали щось спільне, вони походять із загального базового класу. Врешті-решт було 70+ різних класів команд, і весь проект все ще був дуже керованим і над цим було приємно працювати.

Ваш "клас TOC" не дуже далеко від того, що я зробив. У мене був абстрактний завод (GoF), який відповідав за інстанціювання команд. Всередині фабричного класу я заховав більшість деталей за базовим класом та макросами стилю ATL, тому коли програмісту довелося додавати або шукати запит, вони зайшли туди, і все, що вони побачили:

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

Альтернативно (або на додаток до цього) ви можете помістити всі фактичні класи команд в окрему область імен, тому коли люди кодують і потрібно щось запустити, вони просто вводять ім'я простору імен та Intellisense перелічує всі команди, які ви визначили. Потім кожна команда включає всі методи отримання / встановлення get, які визначають, які саме параметри вводу та виводу.

Ви також можете вивчити використання фасадної (GoF) моделі. Замість того, щоб виставляти 1000+ класів вашим інженерам CRUD. Сховати їх усіх за одним класом, який виставляє лише те, що потрібно. Я б все-таки дотримувався того, щоб кожна «дія» була своїм класом, але ваш клас «Фасад» може мати методи, які дозволять інстанціювати кожну вашу дію, і знову, з Intellisense вони відразу побачать, що є в наявності. Або у Фасаду є фактичні методи, але внутрішньо змушуйте їх створювати команди, чергувати їх і чекати відповідей. Потім повертайтеся так, як якщо б було здійснено звичайний виклик методу.

(*) Я не хотів вникати в занадто багато деталей, але насправді мав набір класів "Command" та "CommandHandler". Це розділило відповідальність за управління / встановлення в чергу / серіалізацію параметрів вводу / виходу від класів, які фактично «обробляли» ці команди.

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

Спробуйте використовувати простори імен (C #) або пакети (Java) або будь-яку подібну концепцію, яку має ваша мова (я буду називати їх усі просторами імен), щоб спростити проблему.

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

Якщо ви зробите це правильно, ви отримаєте дуже відкриті речі.

Щоб взяти ваш приклад, якщо я хочу перевірку користувача, я набираю "MyCo". і це дає мені список просторів імен програм. Я знаю, що база даних Користувача використовується у всіх наших додатках, тому я набираю "Core". то я отримую список типів функціональності. Одне з них - «Валідація», що здається очевидним вибором. А там, у межах Validation, є "UserValidator" з усією його функціональністю.

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

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

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

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

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