Comments 20
А зачем столько "пустых" ничего не делающих абстракций? Бесконечные abstract *Base классы с private protected override заглушками - просто визуальный бесполезный шум.
А еще код не органично выглялит для dotnet. Скорее похоже на рукописи древних джавистов или плюсовиков, лет так дцать назад.
Ну и самое главное, из статьи не понятно какую проблему решает этот фреймворк? Где он дает буста при разработке игр? Пока визуально кажется что он лишь добавляет когнитивной нагрузки - пойди сначала разберись, что вообще есть, от чего надо понаследоваться и что пооверрадить чтобы что-то нужное получить.
Как будто смотришь в чей-то ящик проношенных труханов.
Что это и зачем, выглядит очень не очень. Я думаю почти каждый опытный разработчик, который так или иначе получил опыт на создании/изменении архитектуры проектов, в состоянии и сам набросать абстракций, некоторые и получше имеющихся в статье.
И сколько времени потребуется, чтобы набросать подобные абстракции? Теперь, каждый опытный и не опытный разработчик может использовать мой фремворк. Разве это плохо? Многие проекты, кстати, вообще не имеют четкой архитектуры. Для решения этой проблемы и были придуманы фреймворки типа ribs. Что именно выглядит не очень? У вас есть идеи получше? Предлагайте!
Перед разработкой чего надо всегда спросить себя: а не сделал ли кто подобное? А если и сделал в чем мой продукт лучше, выделяется. Чем не угодил MonoGame?
Как по мне большая проблема дотнета это отсутствие нативна. Только и дело что врапить Cpp.
А кто-то делал подобное? MonoGame это совершенно другое.
Да, MonoGame это другое. Это было гениальным решением сделать фреймворкосодержащий продукт для игр, в названии которого:
Game - это пустой абстрактный класс с
OnDisposeInternal()Framework - это когда проект состоит из базовых классов с абстрактными методами, которые доступны только внутри своей борки.
Pro - это
Private pRotected Override void OnDisposeInternal()
Вся индустрия на MonoGame, Unity и Godot, не подозревая, что настоящий геймдев - это когда PlayListBase знает про State2, а State2 знает про PlayListBase, и вместе они дружно вызывают друг другу OnDisposeInternal
Жду GameFramework.Pro.Max.Ultra, где добавят sealed-класс PlayerBase3<TPlayer, TWorld, TInput, TDisposeHandler, TDisposeHandler2>, а в Check.Operation.Alive начнут проверять, жив ли ещё сам разработчик
Зачем каждому методу добавлять кучу модификаторов? protected internal abstract полностью убивает расширяемость, так как метод с такой комбинацией модификаторов невозможно реализовать из другой сборки, соответственно все Base1234 классы идут лесом. И тебе явно стоит изучить как правильно реализовывать IDisposable
И как же правильно надо реализовывать IDisposable?
Первая же ссылка по запросу «C# dispose pattern»: https://learn.microsoft.com/ru-ru/dotnet/standard/garbage-collection/implementing-dispose
В целом, я посмотрел твой репозиторий с этой библиотекой, заодно ещё заглянул в тот что с Unity проектом. У меня просто слов нет, чтобы описать всё что ты там понаписал. Ты явно пытаешься натянуть стиль Java на C#. Я ещё никогда так не угорал, когда читал чужой код. Там же буквально в каждой строчке какие то пёрлы
Какие пёрлы? И чем вам не нравится Java стиль?
Не нравится тем что это C#, если бы код был на Java то вопросов бы не было. И вот те самые пёрлы:
Кто в здравом уме будет писать using внутри namespace в каждом файле? Это прям нишевая фишка, которая может пригодиться раз в жизни.
Открывающиеся фигурные скобки в C# следует писать с новой строчки, ты либо в блокноте код фигачишь, либо вручную зачем то в настройках убрал перенос на новую строку.
Куча модификаторов на каждом методе. Зачем это надо? Зачем ты добавляешь методу internal и потом в настройках прописываешь InternalsVisibleTo? На ровном месте всё усложняешь
Зачем то постоянно переопределяешь методы. Вот эти все
private protected override abstract. Зачем это делается?Постоянные проверки
Check.Operation.Alive, как будто у тебя идёт работа с нативной памятью. Если у тебя даже намёка нету на работу с нативной памятью, то зачем эти миллиард проверок на то что объект был освобождён? Ну и про неправильную реализациюIDisposableя уже писалМожно не писать в каждом файле
#nullable enable, можно просто в настройках проекта поставить<Nullable>enable</Nullable>Вот эти твои *Base1234 тоже ни к чему тут, надо нормально классы обзывать, а не цифры в конце добавлять
ProgramBase2 - это прям сок, настолько раздутых дженериков я ещё никогда не видел
default! для readonly полей… В чём проблема сделать protected конструктор? Вот реально с нифига выбираешь самые странные решения. У тебя в ProgramBase2, 4 свойства с init, в каждом по 2 проверки, итого при создании экземпляра у тебя в моменте будет 8 проверок идти, половина из которых передовые
Божественное название (((фреймворка)))
10 пунктов для этого фреймворкосодержащего продукта. Если говорить и про тот Unity проект, то там вообще песня
И в чем тут проблема?
В том что тебе срочно нужен атрибут [CleanArchitecture]. Ставь его на каждый класс, каждый метод, каждое свойство и поле. Чтобы уж точно было видно - архитектура чистейшая. Правда, судя по всему, испачкана она уже во что-то коричневое. Надеюсь, это шоколад, но пахнет иначе
А если серьёзно, ты реально не видишь проблем в своём коде? Или ты просто прикалываешься? Ты называешь это фреймворком, но при этом твой “фреймворк” ничего кроме абстракций не даёт. Такую шляпу можно самому за полчаса накатать, и то лучше выйдет. Вот представь: чтобы написать hello world, тебе сначала надо сделать свою реализацию абстрактного System.String, а для этого реализовать GetType() и GetHashCode(). Прикольно? Вот и будущим пользователям твоего фреймворка так же весело. Фреймворк - это когда он даёт готовый функционал: рендеринг, звук, загрузку ресурсов, пайплайн ассетов. А ты просто шаблоны накатал, которые ещё и написаны кучеряво, и назвал это GameFramework. Переименуй тогда уж в BoilerplateBase.Pro
Фреймворк GameFramework.Pro (.Net)