Як розробник C ++ я досить звик до файлів заголовків C ++, і вважаю вигідним мати якусь вимушену "документацію" всередині коду. Зазвичай у мене поганий час, коли мені доводиться читати якийсь код C # через це: у мене немає такої ментальної карти класу, з якою я працюю.

Припустимо, що як програмний інженер я розробляю рамки програми. Чи було б занадто божевільним визначати кожен клас як абстрактний безреалізований клас, аналогічно тому, що ми робимо із заголовками C ++, і дозволити розробникам його реалізовувати?

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

Причина цього було зроблено в C ++, пов’язана з тим, щоб зробити компілятори швидшими та легшими в реалізації. Це не було дизайном, щоб полегшити програмування .

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

Намагання копіювати наслідки старих обмежень на обладнання в сучасних умовах розвитку не рекомендується!

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

Насправді інші розробники можуть видалити ваші абстрактні класи. Якщо я знайду інтерфейс у коді, який відповідає обом цим критеріям, я видаляю його та перетворюю його з коду:1. Does not conform to the interface segregation principle 2. Only has one class that inherits from it

Інша справа, що у Visual Studio є інструменти, які роблять те, що ви прагнете досягти автоматично:

1. The Class View
2. The Object Browser
3. У Solution Explorerви можете натиснути на трикутниках затратити класи , щоб побачити свої функції, параметри і повертаються тип.
4. Під вкладками файлів є три маленьких випадаючих меню, найправіший - список усіх членів поточного класу.

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

Крім того, є технічні причини цього не робити ... це зробить ваш кінцевий бінарний файл більшим, ніж потрібно. Я повторю цей коментар Марка Беннінгфілда:

Декларації у файлах заголовків C ++ не входять до складу генерованих бінарних файлів. Вони там для компілятора і лінкера. Ці C # абстрактні класи були б частиною згенерованого коду, без жодної користі.

Також технічно згаданий Роберт Харві технічно найближчим еквівалентом заголовка в C # буде інтерфейс, а не абстрактний клас.

По-перше, зрозумійте, що суто абстрактний клас насправді є просто інтерфейсом, який не може зробити багатократне успадкування.

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

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

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

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

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

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

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

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

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

Так, це було б жахливо, тому що (1) Він вводить непотрібний код (2) Він бентежить читача.

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

Одиничні тести

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

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

Приклад: Де ви могли записати файл заголовка myclass.h, як це:

class MyClass
{
public:
  void foo();
};

Натомість у c # напишіть такий тест:

[TestClass]
public class MyClassTests
{
    [TestMethod]
    public void MyClass_should_have_method_Foo()
    {
        //Arrange
        var myClass = new MyClass();
        //Act
        myClass.Foo();
        //Verify
        Assert.Inconclusive("TODO: Write a more detailed test");
    }
}

Цей дуже простий тест передає ту саму інформацію, що і файл заголовка. (У нас повинен бути клас під назвою "MyClass" з функцією без параметрів "Foo") Хоча файл заголовка більш компактний, тест містить набагато більше інформації.

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