Такое возможно, но тогда это ещё хуже. Основная суть ООП заключается всего в трёх "нужно"
1)Нужно стандартизированное поведение - Различные паттерны проектирования: интерфейсов, структур данных(списки\массивы\деревья\...), буферов, преобразователей, слушателей, и т.д. и т.п.
2)Нужно разделить проект на большую команду и\или многие организации и\или обеспечить долговременную поддержку проекта (т.е. обеспечить масштабирование, диверсификацию и сменяемость разработчиков)
3)Нужно предоставить возможность расширения функциональности с сохранением обратной совместимости(при этом не должно быть ничего "лишнего")(расширять функциональность могут и сторонние разработчики)
По сути все три "нужно" вращаются вокруг UML схем, паттернов проектирования и их проблемах, пользе, преимуществах и недостатках. Вот тут как раз авторы и нарушают третье "нужно" и этим засирают мозги слушателей. Вообще пример пункта "3" это позиция->товар_1->наследуемый товар_2->наследуемый товар_3 где ВНИМАНИЕ: товары два и три появляются после выхода основного продукта и представляют собой классы структурированные согласно системе семантического версионирования в данном примере тут идёт объединение нескольких паттернов, а именно "интерфейс" и "структура данных". Вот в таком варианте ООП и получает преимущества.
Нет вы не правы, есть специальные тетради\блокноты со специальными защёлками где можно вытаскивать\перемещать\удалять\добавлять листы, туда-же можно вставлять закладки, метки, и даже файлики(я про прозрачные полиэтиленовые) куда можно положить сложенный в несколько раз большой лист, а ещё можно на принтере намечатать заготовок\шаблонов и набить в них дырки. НУ И САМОЕ ГЛАВНОЕ! это МЕХАНИЧЕСКИЙ КАРАНДАШ диаметром 0,2-0,4мм с подвижным носиком-предохранителем, а в идеале с механизмом авто-падачи грифеля при письме и механизмом переключения письмо-рисование.
Затем что когда просматриваешь видео с лекциями\конференциями\etc и ставишь на паузу видео для более пристального просмотра информации то панель управления перекрывает часть информации. Потому приходится или ждать убирания(что не эффективно) или скачивать видео и смотреть в другом плеере.
Зелим Бельтоев: я пока не отказался от юнити, хотя в данный момент изучаю UE4, мне важна как кросплатформенность (PC, консоли, мобильники) так и возможность переделать движок по части клиент-серверных оптимизаций. Так как цель: реализовать MMO-TPS в масштабах звёздной системы с учётом поверхности планет и их орбит, и тут доступность исходника UE очень радует.
Игорь Касперский: а какой уровень знаний у вашего брата?
1)в программировании вообще (образование? работа?)
2)завершенные проекты в юнити?
3)на чём специализируется?
и ещё
4) про какую версию юнити идёт речь?
@trerums ну комментарий действительно странный, так как vk написан на "С" точнее на KPHP - это php из которого вырезали ООП и сделали компиляцию в "С" через адаптер к GCC, а фейсбук написан на "HHVM" (могу ошибаться в названии) который компилируется в байт-код Java. По крайней мере, так я понял эти два языка, описанные много раз на хабре.
"ООП" и "ООП паттерны" были придуманы для того что бы понизить сложность вверх по цепочке использования, но из-за этого сильно вырос "порог вхождения".
@Vlad161 как верно заметил @gzhernov учёбу бросать нельзя, потому выход только один это делать свой проект. Проект должен быть коммерческим (не надо делать новый фотошоп или "programName", но нужно сделать что-то за что люди готовы будут вам заплатить), или open source (например допилить что то у существующего проекта). После создания своего проекта можно выходить на фриланс.
1)Нужно стандартизированное поведение - Различные паттерны проектирования: интерфейсов, структур данных(списки\массивы\деревья\...), буферов, преобразователей, слушателей, и т.д. и т.п.
2)Нужно разделить проект на большую команду и\или многие организации и\или обеспечить долговременную поддержку проекта (т.е. обеспечить масштабирование, диверсификацию и сменяемость разработчиков)
3)Нужно предоставить возможность расширения функциональности с сохранением обратной совместимости(при этом не должно быть ничего "лишнего")(расширять функциональность могут и сторонние разработчики)
По сути все три "нужно" вращаются вокруг UML схем, паттернов проектирования и их проблемах, пользе, преимуществах и недостатках. Вот тут как раз авторы и нарушают третье "нужно" и этим засирают мозги слушателей. Вообще пример пункта "3" это позиция->товар_1->наследуемый товар_2->наследуемый товар_3 где ВНИМАНИЕ: товары два и три появляются после выхода основного продукта и представляют собой классы структурированные согласно системе семантического версионирования в данном примере тут идёт объединение нескольких паттернов, а именно "интерфейс" и "структура данных". Вот в таком варианте ООП и получает преимущества.