Ви не робите DRY, тому що хтось написав це в книзі десь, що це добре робити, ви DRY, оскільки це насправді має відчутні переваги.
Зокрема з цього питання:
Якщо ви повторите себе, ви можете створити проблеми з ремонтом. Якщо doStuff1-3 усі мають аналогічний структурований код, і ви вирішите проблему в одному, ви можете легко забути виправити проблему в інших місцях. Крім того, якщо вам доведеться додати новий кейс для обробки, ви можете просто передавати різні параметри в одну функцію, а не склеювати копію всюди.
Однак DRY часто сприймають спритні програмісти. Іноді, щоб не повторювати себе, доводиться створювати абстракції настільки тупими, що ваші товариші по команді не можуть слідувати за ними. Іноді структура двох речей лише невиразно схожа, але досить різна. Якщо doStuff1-4 досить різні, так що перефактування їх, щоб вони не повторювались, змушує вас написати неприродний код або зазнати розумних зворотних кодувань, які змусять вашу команду відблискувати, тоді, можливо, буде добре повторити себе. Я схилився назад, щоб не повторити себе пару разів неприродними способами і пошкодував про кінцевий продукт.
Тож, по суті, не думайте, "о, чоловіче, цей код досить схожий, можливо, я повинен рефактор, щоб не повторювати себе". Подумайте, "чи робить рефакторинг для того, щоб зробити цю базу коду повторним використанням загальних елементів, зробити код більш рентабельним або менш ремонтом ?" Потім виберіть той, який робить його більш ретельним.
Зважаючи на це, враховуючи SRP та просто намагаючись мати невеликі, гнучкі класи загалом, може бути доцільним проаналізувати свій код з цієї причини , розділити біти поведінки, які використовують загальні типи (ви сказали, що вони ідентичні, крім типу) на невеликі класи. Тоді ви дізнаєтесь, що деякі з цих класів насправді є абсолютно однаковими (не просто здебільшого однаковими), і тоді ви зможете скласти інструментарій на випадок, якщо хочете додати Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax.