В Вашей реализации есть достаточно заметные недостатки, а именно необходимость изменять исходный код декорируемых классов (use TDecorator;).
Такая реализация бесполезна в случае использования сторонних библиотек.
Советую всеже посмотреть как декораторы реализуются в питоне — там это сделано очень красиво за счет метапрограммирования и переопределения функций/методов в рантайме. Именно о такой реализации я и мечтаю.
Напрямую заказчик с разработчиками и не общается, просто из моего опыта Product owner это человек который играет на стороне заказчика а не команды. И обычно он старается максимально выполнить хотелки заказчика иногда в ушерб команде. Хотя я надеюсь что просто мне не очень повезло попасть в такой проект.
Несмотря на то что статья про «реальный опыт» больше всего похоже на некий скрам в вакууме.
Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт.
И что будет если этот разработчик уволится или заболеет? Вы прекратите разработку этого модуля?
Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
Первый раз слышу чтобы заказчик так понимающе относился к проблемам разработки. Из моего опыта они и слышать не хотят о сдвиге уже запланированных задач и предлагают использовать внутренние резервы или магию увеличения количества часов в сутках.
Резюмируя:
Мне слабо верится что это действительно реальный опыт и у вас все так хорошо как вы описали.
Но если это действительно так, то конечно завидую :)
Я конечно не специалист в Unity3D, но кеп во мне подсказыват что класс PlayerPrefs предназначен для храниния «настроек» пользователя но никак не сохранений.
Хранение сохранений в реестре выглядит дико, на мой взгляд для сохранений гораздо лучше использовать все же папку пользователя.
Так что я думаю лучше воздержаться от использования этого класса данным способом.
В вашем же ответе есть подтверждение моим словам :). Ключевые слова: «некоторых случаях» — «Иногда становилось».
Я не спорю что массивы действительно могут помочь в определенных случаях (например ресурсоемкий алгоритм обрабатывающий десятки тысяч обьектов за раз), но в большинстве случаев разница не принципиальна. Зато правильное использование ООП позволяет сделать поддержку и развите проекта легче и это как правило гораздо важнее 10% выигрыша в производительности.
Резюмируя хочу сказать что массивы или обьекты не являются серебрянной пулей. В каждой конкретной ситуации надо думать и принимать решение в зависимости от условий.
Уже надоело видеть это замечание в любом предложении об использовании ООП или большого количества обьектов. В всех проектах тормоза вызваны не ООП и не обьектами, а кривыми руками программистов. Да, использование обьектов дает небольшой перерасход ресурсов, но это не сравнится с какой нибудь сортировкой пузырьком или запросом на 3 таблицы в БД чтобы извлечь значение которое потом нигде не используется.
Некоторые изменения в ПО сделать не проще чем полностью поменять фундамент у построенного небоскреба.
Обратная совместимость обходится очень дорого и потому рано или поздно надо отказываться от ее поддержки.
В случае 2 в крупных компаниях может возникать интересная ситуация когда непосредственный начальник не знает сколько получают его подчиненные. С моей точки зрения это неправильно и сильно мешает реально оценивать работу (полезность) сотрудников.
Такая реализация бесполезна в случае использования сторонних библиотек.
Советую всеже посмотреть как декораторы реализуются в питоне — там это сделано очень красиво за счет метапрограммирования и переопределения функций/методов в рантайме. Именно о такой реализации я и мечтаю.
И что будет если этот разработчик уволится или заболеет? Вы прекратите разработку этого модуля?
Первый раз слышу чтобы заказчик так понимающе относился к проблемам разработки. Из моего опыта они и слышать не хотят о сдвиге уже запланированных задач и предлагают использовать внутренние резервы или магию увеличения количества часов в сутках.
Резюмируя:
Мне слабо верится что это действительно реальный опыт и у вас все так хорошо как вы описали.
Но если это действительно так, то конечно завидую :)
Хранение сохранений в реестре выглядит дико, на мой взгляд для сохранений гораздо лучше использовать все же папку пользователя.
Так что я думаю лучше воздержаться от использования этого класса данным способом.
Я не спорю что массивы действительно могут помочь в определенных случаях (например ресурсоемкий алгоритм обрабатывающий десятки тысяч обьектов за раз), но в большинстве случаев разница не принципиальна. Зато правильное использование ООП позволяет сделать поддержку и развите проекта легче и это как правило гораздо важнее 10% выигрыша в производительности.
Резюмируя хочу сказать что массивы или обьекты не являются серебрянной пулей. В каждой конкретной ситуации надо думать и принимать решение в зависимости от условий.
Некоторые изменения в ПО сделать не проще чем полностью поменять фундамент у построенного небоскреба.
Обратная совместимость обходится очень дорого и потому рано или поздно надо отказываться от ее поддержки.