FatCat, любопытная инфа! То есть специальность очень широкопрофильная, я так понимаю. А кто обычно в карете ездит вместе с врачом? Практикант какой-нибудь или полноценный медицинский работник (фельдшер, например)?

Интересно, насколько вреден общий наркоз тем же ксеноном по сравнению с разовой дозой какого-нибудь нарика. Или пропофол, что гораздо ближе по "замыслу".

Полностью укомплектованная бригада скорой 4 человека. Врач, фельдшер, медбрат и санитар-водитель.

Для наркоза, как и для любых других лекарств, смотрим не "вред", а риски и меры их снижения.
С пропофолом не работал, а например при гексенале риск острой сердечной недостаточности возрастает в 10 раз с каждым увеличением дозы на грамм. Поэтому 1 грамм с риском 1 на миллион даем спокойно, второй тоже без особых проблем, третий лишь в исключительных случаях, а четвертый не даем никогда, переходим на другие препараты.

_____________
Бесплатному сыру в дырки не заглядывают...

Интересно! Спасибо.

Весь ООП в о одном объекте. Заключается в грамотном отделении мух от котлет, для унификации приложения с целью никогда не возвращаться к рефакторингу архитектуры при расширении проекта, а не в стиле написания строк кода.

Объектом может считаться минимально самодостаточный механизм. Объект может быть "клетка", работающий в системе спроектированной как человек, но не объект человек. Человек, рука, нога, кровеносная система, скелет и т.п. не могут считаться объектом, так как являются подсистемами функционирования самодостаточного объекта "клетка", изменение свойств которого повлечет изменения во всей архитектуре, в том числе и в этих подсистемах.

Объектом может считаться человек, лишь как минимально самодостаточный механизм другой системы, в которой архитектура человека не имеет никакого значения. Например чтобы построить дом, нужно N человек профессий а,б,в,г,д,е... Если человек "а" умер, берем на работу другой объект с профессией "а", способный завершить работу по строительству. Заказчику строительства не нужно знать о деталях устройства объекта "человек" из системы объектов клетка.

При разработке проекта вселенная потребуется более низкоуровневый объект чем клетка, например объект "атом", устанавливающий свойства взаимодействия между собой, контекст, физику, химию, систему координат...

Пример. При реанимации объекта "человек" пытаются в контексте проекта "больница" повлиять химико/физическими методами на взаимодейсвие функциональности атомов, через свойства объектов "клетки". В кратце - тупо хаками. Сложный вопрос для обсуждения... Проехали...

Правильный выбор основополагающего объекта и устройства систем дальнейшего их взаимодействия - лишь одна из проблем современного, рождающегося умирать софта, которая находится на стадии поиска архитектуры избежания смерти. Намного бОльшая проблема - психологическая, в отношении к наличичию проблемы и важности ее значения. Большинство хочет завести собачку, которая поживет, умрет, чтобы потом завести новую. И лишь единицы хотят чтобы собачка никогда не умирала.

И пожалуй, Twin здесь единственный, кто рассматривает бессмертие собачки как потенциально возможный вариант, а не убеждает что она умрет и ничего с этим не поделать. У кого собачка умрет тот не ...

Собственно речь шла не о том, что считать объектом. И как они взаимодействуют. Вообще вся теория ООП изначально ошибочна. Если рассматривать мир, как множество объектов, то это будет мертвый мир, где нет взаимодействий. При взаимодействиях обязателен еще и субъект.

Субъект, это то, что принимает решения. Объект - то, что выполняет действия. Нельзя построить дом, имея все необходимые объекты - кирпичи, цемент, шифер и так далее. Должен быть субъект - строитель, который расположит их в нужном порядке.

Так вот. Вся проблема в том, что программирование, это не проекция мира. Если рассуждать с точки зрения "всё - объект", получается либо куцо, либо будет противоречить канонам. Допустим можно делегировать выгул собачки какому-нибудь выгул-менеджеру. Его можно представить объектом. А если нужно её покормить? Как представить себе объект, который вместо собачки кушает вискас?

Но еще раз, не в этом дело. Пусть адепты делают объекты-кушатели. Их право. Дело в том, что нет никаких четких определений. Где начинается, где заканчивается и что содержит в себе ООП. Максимум что обычно говорят ООПэшники - нужно научиться думать объектами. Чушь. Нужно научиться думать шире и абстрактнее. А одними объектами - это рамки.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Собственно вот. https://www.youtube.com/watch?v=LoyjUdH1QW4

Прочел статью. Кроме холирава она ничего не даст, потому что в ней просто нечего взять. Есть теория, а есть практика. Есть случаи, когда использовать ООП в разы удобнее для сопровождения и понимания.
Я видел, как функциями заменяли класс, но от этого работоспособность программы не изменилась, зато менялась степень понимание кода.

Если мне нравится ездить на тойоте, зачем мне пересаживаться на мазду.. точнее, не так, зачем меня убеждать пересесть на мазду? я от этого что, буду лучше водить?

Статью следовало назвать "Почему я для себя решил не использовать ООП".

Статья писалась не для того, чтобы кого-то в чем то убедить. Тем паче там нет противопоставлений. Статья писалась для того, чтобы развеять миф о том, что ООП - серебряная пуля. Что это "наше всё". Что это передвая передовых. А кто не юзает - тот лох.

Только и всего. Просто люди говорят о том, чего сами не знают. Ни кто ни где ни разу не дал четкого определения ООП. Но во то, что ООП это круто - знают все.

Получается "пойди туда, не знаю куда, принеси то, не знаю что, но это чтобы это было круто".

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

После прочтения у меня именно такое впечатление. Началось с интервью, которое проводилось где-то в "нужных условиях".

НО проблема с использованием не является проблемой самого ооп, а упражнения в теории, ну мы можем договориться до чего угодно, согласитесь.

..Есть люди которые суют шаблоны/классы/функции везде, превращая код в не читаемую кучу чего-то, но от этого приемы не теряют своей "силы".
Самая большая, на мой взгляд, ошибка наша в том, что мы соглашаемся с противопоставлением и начинаем дискутировать. Хотя, по сути оно из разряда "а крестовая ответка лучше чем не крестовая", но это все равно что сравнивать мягкое с пресным. Достаточно донести, что все инструменты сделаны для чего-то и не надо "сувать" их туда, где без них проще, а потом доказывать, как я круто сунул.

Мне показалось или это действительно так, что только один Николай дал четкие и полные ответы на вопросы, да там были еще тройку ответов, но в основном я это увидел от Николая, или же просто остальные устали холиварить в эту область, тогда зачем было вообще писать что либо