Здравствуйте, Pzz, Вы писали:

Pzz>>>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.
S>>Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.
Pzz>Ну вообще-то говоря, этого совсем не следовало бы делать. Просто в таких местах происходит конфликт интересов между хорошим программированием и хорошим ведением бизнеса. И бизнес обычно побеждает.
Да, ты прав. Этого не следует делать. Но если бизнес победит программирование то и ты и я это сделаем в обоих случаях


Pzz>>>Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.
S>>Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?
Pzz>Потому, что вытащить внутренность в интерфейс заметно сложнее, чем открыть прямой доступ к памяти.
и там и там это можно сделать. Скорость реализации зависит от компетентности программиста и там и там. И, опять же, и там и там это будет сделано если бизнес скажет "надо!".


Pzz>>>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.
S>>Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.
Pzz>Я все больше и больше убеждаюсь, что дурак — роль социальная. Т.е., если набрать в проект одних умных, они все равно расслоятся не небольшое количество граждан, которые ведут себя и поступают, как умные, а остальные будут дураками. Если дураков потом поувольнять, оставшиеся умные опять расслоятся. И так до тех пор, пока вообще никого не останется.
Ну, это уже про психологию а не про программирование и деплой.


S>>Скажу тогда тебе я: подобное случается достаточно редко при правильном управлении жизнью ОС. Настолько редко что считается форсмажором.
Pzz>Но тем не менее, случается.
Вероятность вообще чего угодно никогда не равна нулю. Но это не означает что не нужно стремится вероятность негативных последствий стремить к нулю.

Здравствуйте, Pzz, Вы писали:

Pzz>>>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.
S>>Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.
Pzz>Ну вообще-то говоря, этого совсем не следовало бы делать. Просто в таких местах происходит конфликт интересов между хорошим программированием и хорошим ведением бизнеса. И бизнес обычно побеждает.
Да, ты прав. Этого не следует делать. Но если бизнес победит программирование то и ты и я это сделаем в обоих случаях


Pzz>>>Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.
S>>Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?
Pzz>Потому, что вытащить внутренность в интерфейс заметно сложнее, чем открыть прямой доступ к памяти.
и там и там это можно сделать. Скорость реализации зависит от компетентности программиста и там и там. И, опять же, и там и там это будет сделано если бизнес скажет "надо!".
Более того, во втором случае это вдобавок ещё будет сделать сложнее.


Pzz>>>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.
S>>Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.
Pzz>Я все больше и больше убеждаюсь, что дурак — роль социальная. Т.е., если набрать в проект одних умных, они все равно расслоятся не небольшое количество граждан, которые ведут себя и поступают, как умные, а остальные будут дураками. Если дураков потом поувольнять, оставшиеся умные опять расслоятся. И так до тех пор, пока вообще никого не останется.
Ну, это уже про психологию а не про программирование и деплой.


S>>Скажу тогда тебе я: подобное случается достаточно редко при правильном управлении жизнью ОС. Настолько редко что считается форсмажором.
Pzz>Но тем не менее, случается.
Вероятность вообще чего угодно никогда не равна нулю. Но это не означает что не нужно стремится вероятность негативных последствий стремить к нулю.