Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
— вот бизнес ставит задачу X, программист ее делает без багов, а продажи это не увеличивает. В итоге виноват программист?
— вот бизнес ставит задачу Y, программист смотрит на нее и говорит, что продаж от нее не будет, и смысла ее делать нет. Что тогда делаете? Отменяете ее?
В общем случае для разных компонентов порядок вызова Start не определен, а значит и OnStart.
Производительность: если дорого проверять в каждом апдейте, то можно сделать явную подписку на событие, а без вот этих вот словарей/боксинга/кастов.
Что если два компонента добавят элемент с одним и тем же именем?
Компонент будет работать, просто он не будет получать значение и ошибки не будет
А так ли это хорошо? Может лучше, если будет ошибка, и разработчики узнают о проблеме?
На мой взгляд это writeonly подход, написал — проверил что работает — закрыл навсегда. При каком-либо усложнении логики чтение и даже отладка превратиться в сущий ад.
А какие плюсы дает система, я так и не получил ответа.
Похоже на сборник советов того, как не нужно делать.
При таком «сильно связанном» подходе, особенно, при наличии большого количества компонентов, довольно просто запутаться и поддерживать целостность такой связи. К примеру, если изменится название свойства или метода в одном компоненте, то придется исправлять во всех компонентах, использующих этот. И это гемор.
Как текущий подход помог избавиться от этого гемора?
За то добавилось много нового:
компилятор больше не помощник, он не скажет где вы ошиблись, где использовали не тот
ide больше не помощник, он вам просто так уже не переименует переменные
производительность?
порядок OnStart должен быть определен строго, если вдруг кто-то уже захочет взять данные из другого компонента в своем OnStart
создаем новый объект, добавили в него FirstComponent. А он не работает, потому что ожидает «count». Куда идти, где искать?
А вообще, если появилась такая необходимость завязать много компонентов друг на друга, может что-то не так с архитектурой?
Предплечья на изображении находятся под слишком большим углом, от этого возникает ощущение, что это руки разных людей. А если это руки одного человека, то даже не знаю, чтобы это могло значить :-)
И уже не раз встречал именно такое положение рук от разных людей.
<офтоп> Простите, а что с руками на иконке? Концептуально выглядит, как два человека заключили некий договор и подкрепляют его рукопожатием. На деле это рукопожатие левой и правой рукой. </офтоп>
— вот бизнес ставит задачу X, программист ее делает без багов, а продажи это не увеличивает. В итоге виноват программист?
— вот бизнес ставит задачу Y, программист смотрит на нее и говорит, что продаж от нее не будет, и смысла ее делать нет. Что тогда делаете? Отменяете ее?
Производительность: если дорого проверять в каждом апдейте, то можно сделать явную подписку на событие, а без вот этих вот словарей/боксинга/кастов.
Что если два компонента добавят элемент с одним и тем же именем?
А так ли это хорошо? Может лучше, если будет ошибка, и разработчики узнают о проблеме?
На мой взгляд это writeonly подход, написал — проверил что работает — закрыл навсегда. При каком-либо усложнении логики чтение и даже отладка превратиться в сущий ад.
А какие плюсы дает система, я так и не получил ответа.
Как текущий подход помог избавиться от этого гемора?
За то добавилось много нового:
А вообще, если появилась такая необходимость завязать много компонентов друг на друга, может что-то не так с архитектурой?
Предплечья на изображении находятся под слишком большим углом, от этого возникает ощущение, что это руки разных людей. А если это руки одного человека, то даже не знаю, чтобы это могло значить :-)
И уже не раз встречал именно такое положение рук от разных людей.