В этой заметке я бы хотел обратить внимание на иерархию подчинения, часто обделенную вниманием со стороны дизайнеров языков программирования.
Все сущее, по моему разумению можно смотреть в трех разрезах:
Агрегация (что в чем).
Классификация (принадлежность к классу, одинаковость свойств и поведения объектов).
Подчинение (кто кому или что чему подчиняется).
Если первые два волнующих разреза более-менее реализованы в ООП языках, то последний несправедливо обделен нашим вниманием. Не знаю, быть может это влияние демократии и гуманизма нашего общества, на насилии поставлено мистическое табу. А зря.
Нет, конечно, есть ограничения раздачи приказаний, мы сделали public, protected и private привилегии при объявлении методов объекта.
Private — только я сам могу собой управлять. Ну, простите это и так ясно, назвать это привилегией сложно, это просто внутренняя реализация, никто её не видит.
Остается только, public -методы доступные абсолютно всем и protected — доступные наследникам. И все! А почему такая привилегия именно наследникам? Чем наследники так выделились, что им сделали отдельные права? Чем они лучше скажем объекта агрегатора? Почему для него нет никакого слова?
Иерархия подчинения так же реальна как агрегация, куда реальней классификации и должна быть реализована в первую очередь. Из-за того что мы её не выделили в отдельный вектор бытия, нам приходится местами её подменять классовой иерархией или ссылаться на агрегацию. Путаница полная, дискомфорт и депрессия. Все таки это отдельная система отношений объектов. Подменять власть агрегацией нельзя не обязательно то, что внутри нас находится под нашей властью.
Например, комментарии к фотоальбому находятся внутри альбома, альбом находится внутри пользователя, но другие пользователи могу оставлять и распоряжаться созданными комментариями, несмотря на то что они не находятся внутри них. Администратор сервера имеет доступ ко всем ресурсам и объектом, хотя он ни агрегирует их, ни является наследником.
Правило у подчинения то же, что и у агрегации: подчиняться можно только одному объекту. Правило не гласное, но только так можно избежать конфликтов в управлении.
Реализовать эту возможность несложно, и нужно это сделать именно на уровне языка.
Здесь я бы хотел уделить немного внимания агрегации, которую также часто упускают из вида, правда, не при программировании, а при проектировании структуры баз данных.
Почему агрегация? В общем, природа стремиться к простым решениям и «задумана» по одной общей формуле, законы математики повторяются всюду, во всех областях и похожим образом. Есть правила, которые нарушить мы не можем, кроме как в нашем воображении.
В природе так задумано, что одни объекты могут содержать другие неспроста! Это очень удобно. Легко найти апельсин, лежащий в коробке, если знать что он там находится и знать, где находится коробка. В реальном мире не происходит так, что апельсин есть просто объект, существующий незнай где, не имея координат, и уж подавно архитектура не допустит, чтобы один и тот же апельсин находился в двух разных коробках одновременно (ну только если одна коробка не находится внутри другой, что не нарушает строгости иерархии).
Создатель задумал так: всему есть место! И это чертовски мудрое решение. Главный инженер вселенной пошел дальше и ради порядка даже запретил копирование объектов! Но это тема отдельная, тоже очень интересная.
Определи всему место. Реши, что в чем находится. При удалении у объекта удаляется все содержимое. При перемещении они все движутся вместе. Так построены сложные системы, это позволяет на любом уровне сложности не терять контроля, вы наверно и сами заметили, апельсины и мозг человека весьма стабильны, не требуют отладки и не влияют друг на друга не предсказуемым образом. Какой бы сложной система не была — у нее всегда есть границы. Если что-то пошло не так — удали объект целиком со всем его содержимом и забудь о проблеме.
Впрочем создатель дал маху, не просчитал он всего… Не предположил он что на базе его стройной безошибочной иерархии возникнет то, что выйдет из под контроля — человеческое «познание».Не увидел он сразу, что на базе памяти, на базе состояний элементов начнется эмуляция объектов и их взаимодействий. О том что обезьяна возомнит себя творцом и начнет выводит абстракции, определять категории, погрязнув в этом мутном деле на века. Знай он об этом, наверняка наложил бы табу на такой произвол.
Просчитался и бог с ним, нам на руку. Мы дерзнем, подсмотрим идеи, и сделаем лучше.
Если объектно-ориентированный язык как-то заставляет придерживаться строгости агрегации, то при планировании баз данных этот нюанс обычно упускается из виду. Мы норовим всюду проставить ссылки на другие сущности, не задумавшись о том, что в чем находится. Мир рушится на глазах, нарушаются базовые правила мироздания и проект обречен на смерть…
Все сущее, по моему разумению можно смотреть в трех разрезах:
Агрегация (что в чем).
Классификация (принадлежность к классу, одинаковость свойств и поведения объектов).
Подчинение (кто кому или что чему подчиняется).
Если первые два волнующих разреза более-менее реализованы в ООП языках, то последний несправедливо обделен нашим вниманием. Не знаю, быть может это влияние демократии и гуманизма нашего общества, на насилии поставлено мистическое табу. А зря.
Нет, конечно, есть ограничения раздачи приказаний, мы сделали public, protected и private привилегии при объявлении методов объекта.
Private — только я сам могу собой управлять. Ну, простите это и так ясно, назвать это привилегией сложно, это просто внутренняя реализация, никто её не видит.
Остается только, public -методы доступные абсолютно всем и protected — доступные наследникам. И все! А почему такая привилегия именно наследникам? Чем наследники так выделились, что им сделали отдельные права? Чем они лучше скажем объекта агрегатора? Почему для него нет никакого слова?
Иерархия подчинения так же реальна как агрегация, куда реальней классификации и должна быть реализована в первую очередь. Из-за того что мы её не выделили в отдельный вектор бытия, нам приходится местами её подменять классовой иерархией или ссылаться на агрегацию. Путаница полная, дискомфорт и депрессия. Все таки это отдельная система отношений объектов. Подменять власть агрегацией нельзя не обязательно то, что внутри нас находится под нашей властью.
Например, комментарии к фотоальбому находятся внутри альбома, альбом находится внутри пользователя, но другие пользователи могу оставлять и распоряжаться созданными комментариями, несмотря на то что они не находятся внутри них. Администратор сервера имеет доступ ко всем ресурсам и объектом, хотя он ни агрегирует их, ни является наследником.
Правило у подчинения то же, что и у агрегации: подчиняться можно только одному объекту. Правило не гласное, но только так можно избежать конфликтов в управлении.
Реализовать эту возможность несложно, и нужно это сделать именно на уровне языка.
Здесь я бы хотел уделить немного внимания агрегации, которую также часто упускают из вида, правда, не при программировании, а при проектировании структуры баз данных.
Почему агрегация? В общем, природа стремиться к простым решениям и «задумана» по одной общей формуле, законы математики повторяются всюду, во всех областях и похожим образом. Есть правила, которые нарушить мы не можем, кроме как в нашем воображении.
В природе так задумано, что одни объекты могут содержать другие неспроста! Это очень удобно. Легко найти апельсин, лежащий в коробке, если знать что он там находится и знать, где находится коробка. В реальном мире не происходит так, что апельсин есть просто объект, существующий незнай где, не имея координат, и уж подавно архитектура не допустит, чтобы один и тот же апельсин находился в двух разных коробках одновременно (ну только если одна коробка не находится внутри другой, что не нарушает строгости иерархии).
Создатель задумал так: всему есть место! И это чертовски мудрое решение. Главный инженер вселенной пошел дальше и ради порядка даже запретил копирование объектов! Но это тема отдельная, тоже очень интересная.
Определи всему место. Реши, что в чем находится. При удалении у объекта удаляется все содержимое. При перемещении они все движутся вместе. Так построены сложные системы, это позволяет на любом уровне сложности не терять контроля, вы наверно и сами заметили, апельсины и мозг человека весьма стабильны, не требуют отладки и не влияют друг на друга не предсказуемым образом. Какой бы сложной система не была — у нее всегда есть границы. Если что-то пошло не так — удали объект целиком со всем его содержимом и забудь о проблеме.
Впрочем создатель дал маху, не просчитал он всего… Не предположил он что на базе его стройной безошибочной иерархии возникнет то, что выйдет из под контроля — человеческое «познание».Не увидел он сразу, что на базе памяти, на базе состояний элементов начнется эмуляция объектов и их взаимодействий. О том что обезьяна возомнит себя творцом и начнет выводит абстракции, определять категории, погрязнув в этом мутном деле на века. Знай он об этом, наверняка наложил бы табу на такой произвол.
Просчитался и бог с ним, нам на руку. Мы дерзнем, подсмотрим идеи, и сделаем лучше.
Если объектно-ориентированный язык как-то заставляет придерживаться строгости агрегации, то при планировании баз данных этот нюанс обычно упускается из виду. Мы норовим всюду проставить ссылки на другие сущности, не задумавшись о том, что в чем находится. Мир рушится на глазах, нарушаются базовые правила мироздания и проект обречен на смерть…