Давайте посмотрим, как интерфейсы могут помочь организовать и очистить вашу кодовую базу!

Когда я пишу на C#, особенно для игровых проектов Unity, я обычно сначала пробую разные вещи. Я просто хочу, чтобы моя функция работала в целом, и меня не волнуют мелкие детали.

Однако, чтобы получить надежный и поддерживаемый проект, всегда полезно усовершенствовать и организовать код. И, зачастую, очень приятно, когда можно полностью развязать несвязанные системы, чтобы они не конфликтовали друг с другом.

Итак, сегодня я хочу немного поговорить о шаблонах проектирования ООП и интерфейсах C# и посмотреть, как мы можем создавать легко взаимозаменяемые модели поведения!

👏 Если вам понравилась статья и вы хотите поддержать меня, не забудьте похлопать в конце ;)

Композиция над наследованием

C#, как и многие другие языки программирования, поддерживает ООП (объектно-ориентированное программирование). У вас есть надежная система классов, наследования, инкапсуляции данных и т. д. Но если вы немного привыкли к ООП, вы можете знать, что наследование — не единственный способ, в частности, из-за того, как оно тесно связывает все вместе. Вот почему некоторые люди предпочитают композицию наследованию.

По сути, идея состоит в том, что вместо того, чтобы связывать ваши классы в цепочку через ссылку «родитель-потомок» и распространять некоторые поля или методы перед расширением поведения дочернего класса, вы скорее строите свое поведение, собирая маленькие кирпичики, каждый из которых содержит часть логики.

Обычно это основной принцип многих игровых движков, таких как Unity или Unreal Engine: когда вы создаете объект в своей сцене, вы затем привязываете к нему кучу компонентов, чтобы дать ему определенный материал, включаете его в систему физики, позволяете ему работать. воспроизвести анимацию и связать с ригом…

Теперь предположим, что вы хотите сделать то же самое в своем коде C#. Конечно, вы не хотите просто «предполагать», что у вас есть компоненты A, B и C — вы хотите убедиться, что они доступны, когда вы работаете в своем классе «строитель». Это особенно важно, если: