Абстрактная статья об абстрактных машинах, о сабже практически ни слова. Ну нельзя же так разочаровывать, скажите, что продолжение — более подробное — все же следует! Об организации памяти, об областях памяти, о сборщике мусора и какими алгоритмами он выполняет свою работу, как представлены в памяти классы и объекты и сколько они живут, о синхронизации и совместном использовании ресурсов, о хитростях компилятора и JIT, какие грабли ждут разработчиков и как поменьше по ним гулять…
К примеру, сегодня мы с коллегами обсуждали (на правах светского трепа) такие не шибко заковыристые вопросы:
— как представлены в Java ссылки на объекты
— сколько памяти занимает ссылка?
— каков максимальный размер массива? списка?
— сколько памяти занимает байтовая переменная? булева переменная? а байтовый массив?
— почему программа при запуске сразу отжирает приличный кусок (1-16Г) памяти?
— где хранится стек вызовов
— переполнение памяти и переполнение стека вызовов (StackOverflowException и OutOfMemoryException)
было бы интересно почитать об этом, не сказочку на ночь для самых маленьких программистов.
PHP, конечно, не без недостатков, но язык развивается, и 7ая версия совсем не так плоха, насколько была 4ая (или даже 5.0)
Но огорчает другое. Как известно, PHP процесс оживает при каждом запросе и умирает, только затем, чтобы отрендерить страницу или обработать данные (AJAX/REST) — это должно делаться за миллисекунды. Так зачем за эти миллисекунды заставляют поднимать кучу библиотек фреймворков со всей магией (ORM, процессинг аннотаций и т.д.) — на каждый запрос! Если это уместно на «долгоживущих» платформах, то неуместно на платформе PHP (и даже язык тут не имеет значения, а именно платформа)
С точки зрения меня, как программиста, мы хотим построить завод, который будет по заказу производить разнообразные чашки, кружки и бокалы.
И тут вдруг один завод по заповедям тру-ООП должен уметь всё это производить.
кастрированный ООП(привет Javascript, Go)
JS все-таки ОП, а не ООП.
инкапсуляцию, наследование, полиморфизм… Просто собралась куча дурачков и придумали три сложных слова...
Ну и на что будет похоже ООП, если это выкинуть из него?
На самом деле, просто ООП не умеют готовить. Вот некоторые проблемы:
Инкапсуляция. Ярчайший пример злоупотреблением — Java Beans. Которые не содержат ничего, кроме скрытых полей и простых методов доступа к ним. Они ничего не делают, но ведь ООП, делать публичные поля религия ООП не позволяет. Более того, чаще, чем желательно, из благоговейного трепета перед святой Инкапсуляцией зачастую плодят другие проблемы — нарушают принцип разделения ответственности, привносят кучу жестких зависимостей и т.д.
Наследование. Стоит ли упоминать, как умудряются делать длинные иерархии абстрактных классов, по чуть-чуть добавляя поведение, или, наоборот, делают общего предка у совершенно логически разных объектов только потому, что у них есть похожий код, вместо той же декомпозиции. Чуть менее известна проблема, когда делают абстрактный класс вместо интерфейса, заставляя наследоваться от него и переопределять поведение, чтобы оно работало как надо. И даже интерфейсы — проблема, когда у класса появляется 2 интерфейса с конфликтующей сигнатурой.
Полиморфизм
. Интересно, что на собеседованиях более всего затрудняются объяснить это слово, а на практике проблем с ним все же меньше. В основном, непонимание приводит к примерно такому коду:
И именно так можно изгадить ООП, но без этих принципов не обойтись. Еще хуже, что еще чаще объектами стали пользоваться как 1.структурами 2.процедурными модулями. Особенно часто такое доводилось видеть в PHP.
Но ООП от этого не перестает быть ООП. Можно писать плохо, можно писать хорошо. Можно придумать крутую архитектуру, а потом с болью наблюдать за ее конвульсиями и переписать все к чертовой матери, мало оглядываясь на ООП, шаблоны проектирования и другие умные аббревиатуры.
И да, мы, программисты, скорее инженеры-конструкторы, чем писатели, и это не зависит от парадигмы.
Я думаю, это надо понимать так: сначала для многозадачных приложений приходилось использовать процессы уровня ОС, дергая соответствующий системный вызов.
Видимо, на основе «нам нужно, чтобы люди читали вот это». А что не очень нужно — на всякий случай под фильтр.
И похоже, даже если блокировки грозят полным коллапсом бизнеса и страны.
Низы некомпетентны не только в том, что выбирают таких управленцев, но и… в целом некомпетентны. В самом деле — все мои друзья, знакомые и коллеги — в том числе айтишники — все придерживаются мнений от «заблокировали — и ладно, найдем как обойти блокировки» до «заблокировали — и правильно, стало меньше терроризма\дп» и никакие доводы не помогают — наверное, пока работают ВК и ОК. Что говорить о людях, более далеких от компьютеров — видимо, пока есть доступ к ВК и ОК, они даже не заметят и Чебурашку.
Что тут скажешь… Грустно и досадно, что люди готовы чуть ли не с красным бантиком отдать все свои пароли и номера кредиток любому чиновнику и человеку в погонах — ведь «я ничего не нарушаю» да «кому я интересен»… Остается только ждать «писем счастья» да «пока постучат».
> Вот только дамы выходят за них не для того, чтобы быть с мужчиной, а для того, чтобы иметь ребёнка-lite.
А Вы упорный. Подгоняете суждения под своё мнение.
Некоторые суть айтишники инфантильны
Некоторые суть айтишники женаты
— [Вы почему-то выводите] Все женатые айтишники инфантильны.
Перестаньте, в конце-концов, манипулировать фактами.
А факты таковы, как подтверждает психология, что любая нормальная женщина ОЧЕНЬ быстро устает иметь такого, по Вашему определению, «ребёнка-lite», что неминуемо влечет распадение такого союза. А поскольку очень много устойчивых браков с айтишниками, то Ваша теория неверна в своём обобщении.
Не все с этим согласны
К примеру, сегодня мы с коллегами обсуждали (на правах светского трепа) такие не шибко заковыристые вопросы:
— как представлены в Java ссылки на объекты
— сколько памяти занимает ссылка?
— каков максимальный размер массива? списка?
— сколько памяти занимает байтовая переменная? булева переменная? а байтовый массив?
— почему программа при запуске сразу отжирает приличный кусок (1-16Г) памяти?
— где хранится стек вызовов
— переполнение памяти и переполнение стека вызовов (StackOverflowException и OutOfMemoryException)
было бы интересно почитать об этом, не сказочку на ночь для самых маленьких
программистов.Но огорчает другое. Как известно, PHP процесс оживает при каждом запросе и умирает, только затем, чтобы отрендерить страницу или обработать данные (AJAX/REST) — это должно делаться за миллисекунды. Так зачем за эти миллисекунды заставляют поднимать кучу библиотек фреймворков со всей магией (ORM, процессинг аннотаций и т.д.) — на каждый запрос! Если это уместно на «долгоживущих» платформах, то неуместно на платформе PHP (и даже язык тут не имеет значения, а именно платформа)
Дожили… «Как написать ОС: include 'os';»!
А для меня вот такая ассоциация тех времен останется навсегда: http://dynamicdrive.com/dynamicindex4/bats.htm
И тут вдруг один завод по заповедям тру-ООП должен уметь всё это производить.
JS все-таки ОП, а не ООП.
Ну и на что будет похоже ООП, если это выкинуть из него?
На самом деле, просто ООП не умеют готовить. Вот некоторые проблемы:
Инкапсуляция. Ярчайший пример злоупотреблением — Java Beans. Которые не содержат ничего, кроме скрытых полей и простых методов доступа к ним. Они ничего не делают, но ведь ООП, делать публичные поля религия ООП не позволяет. Более того, чаще, чем желательно, из благоговейного трепета перед святой Инкапсуляцией зачастую плодят другие проблемы — нарушают принцип разделения ответственности, привносят кучу жестких зависимостей и т.д.
Наследование. Стоит ли упоминать, как умудряются делать длинные иерархии абстрактных классов, по чуть-чуть добавляя поведение, или, наоборот, делают общего предка у совершенно логически разных объектов только потому, что у них есть похожий код, вместо той же декомпозиции. Чуть менее известна проблема, когда делают абстрактный класс вместо интерфейса, заставляя наследоваться от него и переопределять поведение, чтобы оно работало как надо. И даже интерфейсы — проблема, когда у класса появляется 2 интерфейса с конфликтующей сигнатурой.
. Интересно, что на собеседованиях более всего затрудняются объяснить это слово, а на практике проблем с ним все же меньше. В основном, непонимание приводит к примерно такому коду:
И именно так можно изгадить ООП, но без этих принципов не обойтись. Еще хуже, что еще чаще объектами стали пользоваться как 1.структурами 2.процедурными модулями. Особенно часто такое доводилось видеть в PHP.
Но ООП от этого не перестает быть ООП. Можно писать плохо, можно писать хорошо. Можно придумать крутую архитектуру, а потом с болью наблюдать за ее конвульсиями и переписать все к чертовой матери, мало оглядываясь на ООП, шаблоны проектирования и другие умные аббревиатуры.
И да, мы, программисты, скорее инженеры-конструкторы, чем писатели, и это не зависит от парадигмы.
а в чем, по-вашему, отличие взрослого от ребенка? :)
И похоже, даже если блокировки грозят полным коллапсом бизнеса и страны.
Что тут скажешь… Грустно и досадно, что люди готовы чуть ли не с красным бантиком отдать все свои пароли и номера кредиток любому чиновнику и человеку в погонах — ведь «я ничего не нарушаю» да «кому я интересен»… Остается только ждать «писем счастья» да «пока постучат».
Ваша выборка нерепрезентативна.
А Вы упорный. Подгоняете суждения под своё мнение.
Некоторые суть айтишники инфантильны
Некоторые суть айтишники женаты
— [Вы почему-то выводите] Все женатые айтишники инфантильны.
Перестаньте, в конце-концов, манипулировать фактами.
А факты таковы, как подтверждает психология, что любая нормальная женщина ОЧЕНЬ быстро устает иметь такого, по Вашему определению, «ребёнка-lite», что неминуемо влечет распадение такого союза. А поскольку очень много устойчивых браков с айтишниками, то Ваша теория неверна в своём обобщении.