«Богатый берёт в кредит мегавнедорожник — получает понты (которые, несомненно, продают) и, как ни крути — удобство, после чего под залог мегавнедорожника берёт другой кредит, который уже пускает в оборот — покупает товар для магазина, сырьё для завода и т.д.»
Для меня это тоже прозрение, спасибо. Понты в кредит, чтобы не отвечать по этому кредиту ничем кроме этих самых понтов — это хорошая придумка.
И не надейтесь, нет и не будет такой литературы. Это как затариваться в московских бутиках: те, кто реально хочет купить что-то не позапрошлогоднее и не втридорога, едут в загранку или заказывают из загранки по почте. Переводчик — это как «лимитчица»-продавщица в московском бутике: апломба куча, а в предмете не разбирается (ибо и не до того, и не надо: раз покупатель — лох (а другого и не бывает, ибо не-лохи тарятся по другим каналам), то «зъйист шо дают»).
Гоблин — «исправлятель мира», любитель с драйвом. Мотивирован неденежно. Исключение.
Предлагаете нагнуться вперёд и нагрузить позвоночник на лишние полтонны или сделать по бокам выступающие подставки под локти (а-ля «вырез в столе под пузо»)?
Да, и наличие у объектов сложных методов и наследование — это в значительной мере tight coupling (многие теоретики по части ООП пишут о необходимости предпочитать агрегацию наследованию), и, поэтому, bad style.
Способы взаимодействия с объектом (то есть т.н. методы) в реляционных СУБД вообще нереализуемы
А там надо что-то сложнее геттеров и сеттеров, т.е. процедур и функций, в которых все аргументы — примитивного, а не объектного типа? А то потом возникает проблема, к какому объекту отнести метод — типа перевода со счёта на счёт — к тому куда переводят, к тому с которого переводят или вообще к сумме (валюта + количество)? Так постепенно логика выносится в «менеджеры» с методом перевестиСумму(Сумма сумма, Счёт с, Счёт на), они же «визиторы» (если по глупости уcпели создать метод (Счёт с).перевестиСуммуНа(Сумма сумма, Счёт на) или (Счёт на).пополнитьСоСчёта(Сумма сумма, Счёт счёт) или (Сумма сумма).перевести(Счёт с, Счёт на) в одном из классов-участников). Если логику «менеджеров» приходится менять, то «менеджеры» «объинтерфейсиваются», чтоб можно было легко менять реализацию.
Так что вместо методов лучше сразу делать доменные функции и доменные процедуры.
Хранение данных об 1 объекте в десятках таблиц, с использованием промежуточных и т.д. — это никак не похоже на ООП-подход, когда объект инкапсулируется внутри себя.
Хранение данных об одном объекте в десятках классов со сложным управлением обратными сссылками — это сильно проще (на счёт инкапсуляции см. в т.ч. выше про «методы»)?
Наследование данных
1) Через constraints и FK (ну да, придётся ещё триггер на вставку делать) 2) В PostfreSQL и так есть.
Полиморфизм
Это, в общем, заимствование из функциональных языков программирования. Изврат на тему косвенного вызова функции — типа вызва функции в С по указателю, только безопаснее. Если нужно, можно нагородить что-то типа CLOS, но по отношению к «персистнутым» в БД данным.
Да, «строка» = «ряд» имелась в виду в таблице БД. Способы взаимодействия с объектами (=их взаимоотношения) и множественные свойства, как и прочие отношения многие-ко-многим моделируются через таблицу пересечений. Если это делать с нормализацией, многое по мере проектирования проясняется.
Для объектно-ориентированных баз данных, если для них есть понятие «класса», и методы есть только у класса, расклад не должен сильно отличаться от реляционных БД. Объект в такой базе хорошо соответствует ряду в таблице РСУБД.
Ну, Ябл-и-Гугл реально настолько крут, чтоб иметь моральное право навязывать тупым юзерам своё видение того, что такое Щастье… А вы — нет. Поэтому он может позволить себе делать интерфейс не как на третьей картинке. А вы — нет.
На самом деле, автоматизированный дебаггинг — это ТЕМА. Жаль (и странно), что я (за других тут говорить не осмелюсь) до сих пор не знаю относительно удобных и простых тулов по этой части…
Я занёс этот ваш коммент в избранное. Интересный challenge. Постараюсь вскоре экспериментально опровергнуть этот тезис которому вас «учили», и написать об этом пост. Если меня не опередит автор этого поста ;-)
1) Переводчик не может быть профессионалом. Это халтурщик для бедных.
2) Любой перевод это халтура за 15 копеек. «Подработка». Советские переводчики напиарили вокруг своей халтурной деятельности вавилоны лжи, а советский перевод был конечно гораздо хуже дореволюционного, на 90% делаемого незнамо кем.
Некоторое (гораздо меньшее чем официально считается) исключение составляют академические переводы древних классиков — из-за особенностей генезиса литературы нового времени. Там действительно требуется (и имеется в наличии) квалификация и эрудиция.
И не надейтесь, нет и не будет такой литературы. Это как затариваться в московских бутиках: те, кто реально хочет купить что-то не позапрошлогоднее и не втридорога, едут в загранку или заказывают из загранки по почте. Переводчик — это как «лимитчица»-продавщица в московском бутике: апломба куча, а в предмете не разбирается (ибо и не до того, и не надо: раз покупатель — лох (а другого и не бывает, ибо не-лохи тарятся по другим каналам), то «зъйист шо дают»).
Гоблин — «исправлятель мира», любитель с драйвом. Мотивирован неденежно. Исключение.
, а
Да, и наличие у объектов сложных методов и наследование — это в значительной мере tight coupling (многие теоретики по части ООП пишут о необходимости предпочитать агрегацию наследованию), и, поэтому, bad style.
перевестиСумму(Сумма сумма, Счёт с, Счёт на), они же «визиторы» (если по глупости уcпели создать метод(Счёт с).перевестиСуммуНа(Сумма сумма, Счёт на)или(Счёт на).пополнитьСоСчёта(Сумма сумма, Счёт счёт)или(Сумма сумма).перевести(Счёт с, Счёт на)в одном из классов-участников). Если логику «менеджеров» приходится менять, то «менеджеры» «объинтерфейсиваются», чтоб можно было легко менять реализацию.Так что вместо методов лучше сразу делать доменные функции и доменные процедуры.
Хранение данных об одном объекте в десятках классов со сложным управлением обратными сссылками — это сильно проще (на счёт инкапсуляции см. в т.ч. выше про «методы»)?
1) Через constraints и FK (ну да, придётся ещё триггер на вставку делать) 2) В PostfreSQL и так есть.
Это, в общем, заимствование из функциональных языков программирования. Изврат на тему косвенного вызова функции — типа вызва функции в С по указателю, только безопаснее. Если нужно, можно нагородить что-то типа CLOS, но по отношению к «персистнутым» в БД данным.
Для объектно-ориентированных баз данных, если для них есть понятие «класса», и методы есть только у класса, расклад не должен сильно отличаться от реляционных БД. Объект в такой базе хорошо соответствует ряду в таблице РСУБД.
Не-БД будет лучше коррелировать с не-ООП.