С# притом, что большая часть терминов из языка думал над тем что бы назвать статью "термины С# + еще всякое", но решил, что укороченного названия будет достаточно можно и 10 статей на каждый термин сделать с кучей примеров, но зачем? смысл в том что бы было нужное в одной, для удобства
да с финалом проглядел, что документация к С++, спасибо а несвязные вещи - соединил для удобства чтения, если каждый термин писать отдельно, статью будет неудобно читать
Согласен - все учесть невозможно + в процессе производства игры многое может поменяться. Однако если на старте (или на новом этапе) есть хорошо описанное тз, то фундамент (из грамотно подобранных интерфейсов) будет надежным. Но, возможно про изменения интерфейсов речь шла о рефакторинге (его ж никто не отменял), то в таком случае можно и старые поправить и новых добавить. На мой взгляд это все упирается в решения команды (лидов/сеньеров) - закладывают ли они возможность уделять время на изменения базовых структур архитектуры, либо архитектура изначально подразумевает динамическую структуру (возможность без особых последствий изменять уже существующий код).
Моей основной задачей было - кратко изложить суть так, что бы было понятно человеку, который до этого ни разу не сталкивался с подобными понятиями. В том числе что можно прописать в интерфейс. Конечно не факт, что этим воспользуются, но хотя бы знать о возможности стоит. Но почему тогда у меня нет приписки о реализации в интерфейсах? В оставленных ссылках со статьями об этом нет упоминания, поэтому решил не усложнять понимание. Если считаете что это стоит упоминания в этой статье, то постараюсь добавить хороший материал на эту тему.
по С# такого не нашел, но вот в Java они присутствуют (оставляю для общего развития) Скорее проще перечислить что есть у них общего… а это только корень final и то что они являются зарезервированными словами в Java. final — модификатор, применяющийся к классам, методам, переменным. В общем своём представлении делающий объект своего действия неизменным, а если быть точнее, то после его применения:-от класса становится невозможно наследоваться;-метод невозможно переопределить;-переменную невозможно изменить(но в случае, если переменная-это ссылка на объект, то на состояние объекта final никак не влияет, если только класс сам не является final). finally является частью конструкции try-catch-finally, в где играет роль блока, который выполняется независимо от событий происходящих в try-catch и выполняется в любом случае. finalize() является методом класса Object.
вероятно это вопрос с подвохом и ответ возможен такой - в С# таких понятий нет, это Java синтаксис. В свою очередь могут задать - "а что подобное есть в С#?"
Спасибо) Что ж начнем полемику и возможно появится какое то среднее мнение) Про интерфейсы - в грамотном подходе к архитектуре проекта для большой команды, в начале создаются интерфейсы - что бы большая часть команды уже начала делать свои задачи просто наследуясь. Следовательно если в будущем вносить изменения в интерфейс, а наследники будут писаться кучей людей, то в итоге начнется неразбериха и кто то потратит время на исправление всего и вся. Это один из принципов солида - "не изменяй то, что уже работает - добавляй новое".
Конечно если проект ведешь в одиночку или буквально в несколько человек, то и интерфейсами можно пренебречь и изменять можно что угодно, тут скорее про удобство и быстроту реагирования.
В документации микрософт по интерфейсам есть вот такие слова :
Начиная с C# 8.0, член интерфейса может объявлять тело. Этот называется реализацией по умолчанию. Члены с телом позволяют интерфейсу предоставлять реализацию по умолчанию для классов и структур, которые не предоставляют реализацию с переопределением. Кроме того, начиная с C# 8.0, интерфейс может включать следующее.
Явные модификаторы доступа (доступ по умолчанию — public).
Начиная с C# 11 интерфейс может объявлять static abstract элементы для всех типов элементов, кроме полей.
Да реализация в интерфейсах появилась, но это соблазн в будущем эту реализацию поменять. Обычно интерфейсы как раз и используют для того, что бы реализация была разной у каждого наследника.
примеры с интерфейсами сначала и решил показать, но они кхм "большие" для того что бы кратко изложить суть, а хотелось сделать картинку - подсказку достаточно компактную. Все остальное можно подчерпнуть из статьей-ссылок, поэтому их так много, что бы охватить большую часть информации.
На данный момент у меня было 4 собеса на мидла, и везде были вопросы в основном про ООП/солид и использование юнити + какие сторонние ассеты приходилось "трогать".
Спасибо за добрые слова)
постараюсь добавить, для меня это тоже новенькое)
Спасибо и тебе за приятный комментарий)
Например можешь глянуть вот сюда https://habr.com/ru/post/493484/
Разнообразный? Это же здорово
С# притом, что большая часть терминов из языка
думал над тем что бы назвать статью "термины С# + еще всякое", но решил, что укороченного названия будет достаточно
можно и 10 статей на каждый термин сделать с кучей примеров, но зачем? смысл в том что бы было нужное в одной, для удобства
да с финалом проглядел, что документация к С++, спасибо
а несвязные вещи - соединил для удобства чтения, если каждый термин писать отдельно, статью будет неудобно читать
можешь зайти в статью и посмотреть вопросы
Здорово! Спасибо за статью)
Согласен - все учесть невозможно + в процессе производства игры многое может поменяться.
Однако если на старте (или на новом этапе) есть хорошо описанное тз, то фундамент (из грамотно подобранных интерфейсов) будет надежным.
Но, возможно про изменения интерфейсов речь шла о рефакторинге (его ж никто не отменял), то в таком случае можно и старые поправить и новых добавить.
На мой взгляд это все упирается в решения команды (лидов/сеньеров) - закладывают ли они возможность уделять время на изменения базовых структур архитектуры, либо архитектура изначально подразумевает динамическую структуру (возможность без особых последствий изменять уже существующий код).
Моей основной задачей было - кратко изложить суть так, что бы было понятно человеку, который до этого ни разу не сталкивался с подобными понятиями.
В том числе что можно прописать в интерфейс. Конечно не факт, что этим воспользуются, но хотя бы знать о возможности стоит.
Но почему тогда у меня нет приписки о реализации в интерфейсах?
В оставленных ссылках со статьями об этом нет упоминания, поэтому решил не усложнять понимание.
Если считаете что это стоит упоминания в этой статье, то постараюсь добавить хороший материал на эту тему.
по С# такого не нашел, но вот в Java они присутствуют (оставляю для общего развития)
Скорее проще перечислить что есть у них общего… а это только корень final и то что они являются зарезервированными словами в Java.
final — модификатор, применяющийся к классам, методам, переменным. В общем своём представлении делающий объект своего действия неизменным, а если быть точнее, то после его применения:-от класса становится невозможно наследоваться;-метод невозможно переопределить;-переменную невозможно изменить(но в случае, если переменная-это ссылка на объект, то на состояние объекта final никак не влияет, если только класс сам не является final).
finally является частью конструкции try-catch-finally, в где играет роль блока, который выполняется независимо от событий происходящих в try-catch и выполняется в любом случае.
finalize() является методом класса Object.
вероятно это вопрос с подвохом и ответ возможен такой - в С# таких понятий нет, это Java синтаксис.
В свою очередь могут задать - "а что подобное есть в С#?"
Спасибо)
Что ж начнем полемику и возможно появится какое то среднее мнение)
Про интерфейсы - в грамотном подходе к архитектуре проекта для большой команды, в начале создаются интерфейсы - что бы большая часть команды уже начала делать свои задачи просто наследуясь. Следовательно если в будущем вносить изменения в интерфейс, а наследники будут писаться кучей людей, то в итоге начнется неразбериха и кто то потратит время на исправление всего и вся.
Это один из принципов солида - "не изменяй то, что уже работает - добавляй новое".
Конечно если проект ведешь в одиночку или буквально в несколько человек, то и интерфейсами можно пренебречь и изменять можно что угодно, тут скорее про удобство и быстроту реагирования.
В документации микрософт по интерфейсам есть вот такие слова :
Начиная с C# 8.0, член интерфейса может объявлять тело. Этот называется реализацией по умолчанию. Члены с телом позволяют интерфейсу предоставлять реализацию по умолчанию для классов и структур, которые не предоставляют реализацию с переопределением. Кроме того, начиная с C# 8.0, интерфейс может включать следующее.
Константы
Операторы
Статический конструктор
Вложенные типы
Статические поля, методы, свойства, индексаторы и события
Объявления членов с использованием явного синтаксиса реализации интерфейса.
Явные модификаторы доступа (доступ по умолчанию —
public).Начиная с C# 11 интерфейс может объявлять
static abstractэлементы для всех типов элементов, кроме полей.Да реализация в интерфейсах появилась, но это соблазн в будущем эту реализацию поменять. Обычно интерфейсы как раз и используют для того, что бы реализация была разной у каждого наследника.
вероятнее всего ожидал ответ наподобие -
Есть несколько видов полиморфизма
Параметрический полиморфизм - дженерики.
Полиморфизм подтипов - ООП-полиморфизм, выражаемый в переопределении методов при наследовании. Same dunction - different behavior.
Ну и ad-hoc (мнимый полиморфизм) - статический полиморфизм, выражающийся в перегрузке методов.
Но нашел это в другой статье и уже добавил ссылку.
Спасибо)
Спасибо)
примеры с интерфейсами сначала и решил показать, но они кхм "большие" для того что бы кратко изложить суть, а хотелось сделать картинку - подсказку достаточно компактную.
Все остальное можно подчерпнуть из статьей-ссылок, поэтому их так много, что бы охватить большую часть информации.
да в целом так и есть + более глубокое понимание С# и ооп + грамотный подход к архитектуре проекта
На данный момент у меня было 4 собеса на мидла, и везде были вопросы в основном про ООП/солид и использование юнити + какие сторонние ассеты приходилось "трогать".
ох, к сожалению это ощущение будет преследовать нас до конца). Радует что статья уже дает результаты)
Если у тебя есть более конкретный пример в 2-3 строки (и который будет понятен для новичка) то буду рад его добавить вместо моего