Самое забавное, что все (ну ладно, многие) считают, что они пишут для себя. Отсюда и такое как у Вас отношение. Пишите так, чтобы другие сказали, что вы пишете понятно. Исли изначально исходить из таких предпосылок, то и вопросов о читаемости не возникнет.
Вот это поворт
Ну да. Тут главное понять что такое «большой проект» и «сложный проект» — полтора миллиона строк для управления продажами или 12 тысяч строк на ассемблере, которые будут работать на орбите в течении 3х лет. Так вот второе это «сложный», а первое совсем наоборот. Довести любой учетный проект до состояния точки невозврата возможно, но довольно быстро возникает ситуация, когда само управление изменениями становится большей проблемой чем, собственно, внесение изменений. Тут мы вспоминаем про Фаулера и начинаем излагать умные мысли, хотя на самом деле нужно было изначально подумать «а как мы будем изменять», ведь изменение — основа всех учетных систем. И IOC в данном случае как раз путь к решению этой проблемы на уровне архитектуры
Работаю с двумя реализациями IoC, Ни в одной не встречал ситуации «у нас все плохо, но мы не скажем почему», скорее всего по тому, что живых ситуаций потери зависимостей не так много и все они разжевываются новичкам буквально в первые недели работы. Гораздо сложнее объяснить про контекстно зависимость для части классов. Вот тут реально такие варианты решения «проблем» видел, что хоть вешайся. Тут остро стоит вопрос «я новичок и должен показать, что я умею круто программировать», в итоге — свои реализации стандартных контейнеров, обязательная «самая правильная» реализация синглтона (я уж не знаю, возможно это какое-то неформальное соревнование). А размер проекта вообще на сложность не влияет, если он изначально написан модульно.
Есть телефон, зарегистрированный 16 лет назад, но с адресом, с которого съехали 6 лет назад и с email сообще от балды, другой телефон 16 летней выдержки отсутствует. Есть так же домашний, со старым владельцем, который умер 8 лет назад…
Самое забавное, что все (ну ладно, многие) считают, что они пишут для себя. Отсюда и такое как у Вас отношение. Пишите так, чтобы другие сказали, что вы пишете понятно. Исли изначально исходить из таких предпосылок, то и вопросов о читаемости не возникнет.
Ну да. Тут главное понять что такое «большой проект» и «сложный проект» — полтора миллиона строк для управления продажами или 12 тысяч строк на ассемблере, которые будут работать на орбите в течении 3х лет. Так вот второе это «сложный», а первое совсем наоборот. Довести любой учетный проект до состояния точки невозврата возможно, но довольно быстро возникает ситуация, когда само управление изменениями становится большей проблемой чем, собственно, внесение изменений. Тут мы вспоминаем про Фаулера и начинаем излагать умные мысли, хотя на самом деле нужно было изначально подумать «а как мы будем изменять», ведь изменение — основа всех учетных систем. И IOC в данном случае как раз путь к решению этой проблемы на уровне архитектуры