Да практически в любом. Только не нужно упрощённо понимать под закрытыми данными private переменные. Закрытыми данными, к примеру, может являться реализация некоего интерфейсного метода. Унаследовав класс мы можете её переопределить, не переопределив правильно другие методы которые он пользует. Всё это есть нарушение инкапсуляции (сокрытия).
В жизни квадрат является частным случаем прямоугольника. И у него МОЖНО изменить длину и ширину. Но в отличие от прямоугольника это изменение должно делаться сразу для обоих величин (ибо они равны). Так что всё верно. Как и то, что карточка является ключом. Даже ввод пароля на Хабр с абстрактной точки зрения также есть реализация Ключа. Учимся-учимся мыслить абстрактно.:-)
Наследование потому нарушает инкакпсуляцию, что может давать способ доступиться к данным, которые закрыты. Технически это порой удобно, канонически - принцип нарушает.
Мы не переопределяем метод Открыть. Мы его реализуем. Потому как его застолбил интерфейс. И карточка и амбарный ключ действительно реализуют интерфейс Ключ. Всё у автора верно. Воду из ведёрка он не черпает. :-)
Верно. Человек изначально поступил правильно. Только вроде как эта кнопочка "купить" была на некоем англоязычном сайте. Видимо некий дистрибутор/продавец. Но далее, вместо того, что бы пойти в местный магазин, человек стал звонить непосредственно в головную компанию. Они редко продают напрямую, ибо тогда подорвут свою диллерскую сеть. Или вы также покупаете автомобили непосредственно на заводе изготовителе?
Не хотелось бы показаться фанатом Микрософта, но в голове возник вопрос - Вы вот когда 200 граммов колбасы покупаете, Вы также делаете это непосредственно через Главбуха мясокомбината?
...Но когда строится иерархия однотипных, похожих друг на друга классов полезно применять наследование...
------------------------------------
А какие ещё способы построения иерархии (помимо наследования) вы практикуете?
Смысл интерфейса не в построении иерархий, а в жёстком затребовании от класса реализации необходимой функциональности, которая при этом будет доступна строго определённым образом. Если есть общая реализация, то можно ввести дополнительный слой в виде абстрактного класса для некоей ветви.
Понимаете, тусовать набор возможностей, вырванных из разных языков, в надежде получить новый удобный язык, дело несложное, но достаточно неблагодарное. Вариантов уж очень много. Посему принято иметь концепцию, которую нужно уметь чётко пояснить (защитить, по сути). Не просто перечислить что было перетасовано, а внятно пояснить ЗАЧЕМ это было сделано. очертить какие преимущества и в каких случаях дают те или иные возможности (или мешают, если вы их убираете). К примеру, руль в автомобиле можно поставить сбоку, педали сзади, а зеркала на уровне бампера. Всё это обозвать крутым концепт-каром и пытаться ездить, поглядывая какие-такие преимущества это привнесло в процесс вождения. Одно из преимуществ видно сразу – греющий пятки экстрим и драйв в вождении. :-)
Этому процессу очень хорошо помогает осмысление того, с какой целью изменяемые возможности были введены в уже существующие языки и каких преимуществ от этого добилось прогрессивное человечество в процессе эволюции. :-)
Скажу больше, в глобальном смысле, в большинстве случаев цель одна – помочь справиться со сложностью систем. Посему, когда вы говорите ... выкинуть понятие глобальных переменных... это понятно и альтернативные варианты легко обосновываются. Когда вы говорите ...выкинуть понятие классов... то хочется спросить, а чем же ваш одинавсеслучаи-класс-объект-мутант лучше? Классы, это дополнительный уровень абстракции, причём отражающий специфику мышления человеческого мозга (мы классифицируем окружающие предметы). Имея классы, можно в пять секунд сэмулировать вашу концепцию. Достаточно ввести один класс на всё приложение, снабдить его парой динамических структур и пихать в них всё что вздумается.
Вуаля, типизации больше нет. Нет больше телевизоров, табуреток и унитазов. Есть один предмет обихода – мутант, который может выполнять все функции. Натыкаясь на него в темноте будете путём сообщений выяснять в каком он сейчас статусе. То ли его включить, то ли в него помочиться. Но забавно и прикольно, только зачем нужно в подавляющем большинстве случаев? Сталкеризм видимо весёлое развлечение, но не в промышленных масштабах. В масштабах цивилизации это называется словом хаос.
С передачей сообщений примерно такая же картинка (вызов метода, кстати, если абстрагироваться, также не более чем передача сообщения). Легко моделируется там где надо, а где не надо – используется простой и понятный подход. Который к тому же намного более эффективен.
Посему я и написал, что такие перетасовки не более чем забавное хобби. Ну или вы способны именно пояснить преимущества новых вещей, сопоставив с тем что уже есть, и почему вам кажется, что это действительно удобней, эффективней, безопасней и позволит вам реализовывать более сложные системы. Просто же описывать механику работы вряд ли целесообразно. Это как описывать каким болтом укрепить руль сбоку на двери, не пояснив предварительно зачем и кому это нужно.
Забавно. Подростки переосмысливают ООП в духе - мы Буча не читали, но свое придумаем и скажем, по своему обзовём, войдём в историю...
Если наберётся ещё достаточное количество чайников не способных промыслить базовые принципы то оно и прокатит. Наивные безграмотные чудики не способные промыслить концепцию. Бла-бла-бла... вставили пробел... бла-бла-бла... Интроспекция вызова... бла-бла-бла... создает специальный объект Locals...
Ребят, вы если действительно понимаете основные базовые принципы, то напишите вменяемый текст, чётко и внятно описывающий новые достижения. Ото эти мутные примеры в духе ...Если нужный слот нигде не найден, то запускается поиск слота forward... Мне абсолютно всё равно поиск какого слота там запускается. Я не пишу на этом языке, но я хочу уловить мысль. Мне может и интересно, но научитесь писать вменяемым языком. Я читал предыдущие статьи, но таки и не понял ключевую мысль. Сакцентируйтесь на этом, а не перечисляйте названия операторов. Я, по своей простоте, полагаю, что для большинства людей это сейчас бесполезно.
Эти вот ваши ...мы можем манипулировать кодом как нам угодно: передавать, хранить, выполнять в произвольных контекстах...
Не поверите, но я тож манипулирую кодом как мне угодно... передаю, храню, выполняю в произвольном контексте...
Грубо говоря - прочтите фундаментальный учебник ООП и чётко и внятно изложите в чём есть достижения. Если уж хотите пропагандировать... Да. :-)
PS: Бля, как же серёзно глючит Хабр. Стыдно за него.
Хрен победишь отчего народ так остервенело минусует. :-)
Видимо слабо-эрудированная часть Хабра решила тут пересчитаться.
Для этой дремучей части я поясняю - я привёл канонический вариант этого анека про консалтов которому уже едва ли не десяток лет. Тогда ещё и MS SQL видимо небыло. И ODBC только появилcя. А иметь ноут и спутниковый мобил было о-очень круто.
Cтоит пастух - пасет овец. Вдруг останавливается новенький Jeep Cherokee, из него выходит молодец в костюме от Briоni, ботинках от Gucci, очках Ray Ban и галстуке YSL. И предлагает: если я точно скажу тебе число овец в твоем стаде, ты отдашь мне одну овцу. Пастух соглашается. Яппи достает notebook из машины, присоединяет мобильный телефон, ... - GPS - NASA - Excel - ... наконец печатает отчет на 150 страниц и говорит пастуху: "В стаде ровно 1586 овец". Пастух соглашается, предлагает забрать одну овцу, наблюдает за выбором яппи и как он тащит овцу в машину. Вдруг пастух говорит: "Если я точно назову твой бизнес, отдашь мне овцу назад?" Яппи: "Давай". Пастух: "Ты - консультант". Яппи: "Как ты догадался?". Пастух: "Легко. Ты приперся, хотя тебя никто не звал. Ты хотел получить плату за ответ, который я так знал. И ты ни хрена не понимаешь в моем бизнесе, потому что ты выбрал себе мою собаку".
Но что интересно, теперь, помимо Excel, стали вдруг фигурировать ODBC и MS-SQL. Что уже забавно. Как это старина Джобс пропустил? Очевидно же, что у Яппи должен был быть яблочный ноут. Вот Андерсен Консалт часто любил своё имя добавлять в эту байку.
Угу-угу. Скажу более – вообще говоря и сами данные можно хранить где угодно. Скажем, в текстовых файлах на диске. О-очень гибко получается. Но почему-то используют СУБД. Наверное по привычке. С целью списания бюджетных средств на покупку дорогостоящих серверов баз данных. :-)
MikhailEdoshin абсолютно прав. Ваша идея имеет крайне опосредованное отношение к паттерну Composite. И по сути, она описывается одним предложением, а именно – вы вынесли хранение всех отношений предметной области один ко многим и многое-ко-многим в одну общую таблицу. Тем самым лишив сервер БД возможности полноценно поддерживать логическую целостность ваших данных (в данном случае ссылочную) и эффективно строить запросы. Поскольку логическую целостность поддерживать приходится, то вам придётся это делать руками в самом приложении. Заодно беспокоясь об изолированности транзакции и эффективности изменений данных в БД. Об эффективности написания и выполнения поисковых запросов теперь даже и упоминать неприлично.
Такие решения иногда приходится использовать, но для них нужны крайне веские основания. К примеру, если отношения между сущностями непрерывно меняются. Непрерывно, это не значит что несколько раз в месяц или год, это значит несколько раз в час или даже минуту. Скажем при проектировании некой детали в САПР системе. Но в таким случаях, как правило, и не применяют реляционные СУБД.
Верно. Ибо нежелающие давать результат в тех условиях, могли быть быстро перемещены в места (и условия) с ещё более нормированным режимом и централизованным питанием заметно худшего качества.
------------------------------------
А какие ещё способы построения иерархии (помимо наследования) вы практикуете?
Смысл интерфейса не в построении иерархий, а в жёстком затребовании от класса реализации необходимой функциональности, которая при этом будет доступна строго определённым образом. Если есть общая реализация, то можно ввести дополнительный слой в виде абстрактного класса для некоей ветви.
Этому процессу очень хорошо помогает осмысление того, с какой целью изменяемые возможности были введены в уже существующие языки и каких преимуществ от этого добилось прогрессивное человечество в процессе эволюции. :-)
Скажу больше, в глобальном смысле, в большинстве случаев цель одна – помочь справиться со сложностью систем. Посему, когда вы говорите ... выкинуть понятие глобальных переменных... это понятно и альтернативные варианты легко обосновываются. Когда вы говорите ...выкинуть понятие классов... то хочется спросить, а чем же ваш одинавсеслучаи-класс-объект-мутант лучше? Классы, это дополнительный уровень абстракции, причём отражающий специфику мышления человеческого мозга (мы классифицируем окружающие предметы). Имея классы, можно в пять секунд сэмулировать вашу концепцию. Достаточно ввести один класс на всё приложение, снабдить его парой динамических структур и пихать в них всё что вздумается.
Вуаля, типизации больше нет. Нет больше телевизоров, табуреток и унитазов. Есть один предмет обихода – мутант, который может выполнять все функции. Натыкаясь на него в темноте будете путём сообщений выяснять в каком он сейчас статусе. То ли его включить, то ли в него помочиться. Но забавно и прикольно, только зачем нужно в подавляющем большинстве случаев? Сталкеризм видимо весёлое развлечение, но не в промышленных масштабах. В масштабах цивилизации это называется словом хаос.
С передачей сообщений примерно такая же картинка (вызов метода, кстати, если абстрагироваться, также не более чем передача сообщения). Легко моделируется там где надо, а где не надо – используется простой и понятный подход. Который к тому же намного более эффективен.
Посему я и написал, что такие перетасовки не более чем забавное хобби. Ну или вы способны именно пояснить преимущества новых вещей, сопоставив с тем что уже есть, и почему вам кажется, что это действительно удобней, эффективней, безопасней и позволит вам реализовывать более сложные системы. Просто же описывать механику работы вряд ли целесообразно. Это как описывать каким болтом укрепить руль сбоку на двери, не пояснив предварительно зачем и кому это нужно.
ВИ просит Петьку достать банан с дерева. Рядом стоит палка. Но Петька лихорадочно трясёт дерево.
ВИ: Ну думай же, Петька, думай!
Петька: А хуля тут думать?! Трясти надо!!!
Если наберётся ещё достаточное количество чайников не способных промыслить базовые принципы то оно и прокатит. Наивные безграмотные чудики не способные промыслить концепцию. Бла-бла-бла... вставили пробел... бла-бла-бла... Интроспекция вызова... бла-бла-бла... создает специальный объект Locals...
Ребят, вы если действительно понимаете основные базовые принципы, то напишите вменяемый текст, чётко и внятно описывающий новые достижения. Ото эти мутные примеры в духе ...Если нужный слот нигде не найден, то запускается поиск слота forward... Мне абсолютно всё равно поиск какого слота там запускается. Я не пишу на этом языке, но я хочу уловить мысль. Мне может и интересно, но научитесь писать вменяемым языком. Я читал предыдущие статьи, но таки и не понял ключевую мысль. Сакцентируйтесь на этом, а не перечисляйте названия операторов. Я, по своей простоте, полагаю, что для большинства людей это сейчас бесполезно.
Эти вот ваши ...мы можем манипулировать кодом как нам угодно: передавать, хранить, выполнять в произвольных контекстах...
Не поверите, но я тож манипулирую кодом как мне угодно... передаю, храню, выполняю в произвольном контексте...
Грубо говоря - прочтите фундаментальный учебник ООП и чётко и внятно изложите в чём есть достижения. Если уж хотите пропагандировать... Да. :-)
PS: Бля, как же серёзно глючит Хабр. Стыдно за него.
Видимо слабо-эрудированная часть Хабра решила тут пересчитаться.
Для этой дремучей части я поясняю - я привёл канонический вариант этого анека про консалтов которому уже едва ли не десяток лет. Тогда ещё и MS SQL видимо небыло. И ODBC только появилcя. А иметь ноут и спутниковый мобил было о-очень круто.
Cтоит пастух - пасет овец. Вдруг останавливается новенький Jeep Cherokee, из него выходит молодец в костюме от Briоni, ботинках от Gucci, очках Ray Ban и галстуке YSL. И предлагает: если я точно скажу тебе число овец в твоем стаде, ты отдашь мне одну овцу. Пастух соглашается. Яппи достает notebook из машины, присоединяет мобильный телефон, ... - GPS - NASA - Excel - ... наконец печатает отчет на 150 страниц и говорит пастуху: "В стаде ровно 1586 овец". Пастух соглашается, предлагает забрать одну овцу, наблюдает за выбором яппи и как он тащит овцу в машину. Вдруг пастух говорит: "Если я точно назову твой бизнес, отдашь мне овцу назад?" Яппи: "Давай". Пастух: "Ты - консультант". Яппи: "Как ты догадался?". Пастух: "Легко. Ты приперся, хотя тебя никто не звал. Ты хотел получить плату за ответ, который я так знал. И ты ни хрена не понимаешь в моем бизнесе, потому что ты выбрал себе мою собаку".
Но что интересно, теперь, помимо Excel, стали вдруг фигурировать ODBC и MS-SQL. Что уже забавно. Как это старина Джобс пропустил? Очевидно же, что у Яппи должен был быть яблочный ноут. Вот Андерсен Консалт часто любил своё имя добавлять в эту байку.
MikhailEdoshin абсолютно прав. Ваша идея имеет крайне опосредованное отношение к паттерну Composite. И по сути, она описывается одним предложением, а именно – вы вынесли хранение всех отношений предметной области один ко многим и многое-ко-многим в одну общую таблицу. Тем самым лишив сервер БД возможности полноценно поддерживать логическую целостность ваших данных (в данном случае ссылочную) и эффективно строить запросы. Поскольку логическую целостность поддерживать приходится, то вам придётся это делать руками в самом приложении. Заодно беспокоясь об изолированности транзакции и эффективности изменений данных в БД. Об эффективности написания и выполнения поисковых запросов теперь даже и упоминать неприлично.
Такие решения иногда приходится использовать, но для них нужны крайне веские основания. К примеру, если отношения между сущностями непрерывно меняются. Непрерывно, это не значит что несколько раз в месяц или год, это значит несколько раз в час или даже минуту. Скажем при проектировании некой детали в САПР системе. Но в таким случаях, как правило, и не применяют реляционные СУБД.
Кажется эта идея уже была реализована в истории. И вроде её неплохо описал Солженицын. :-)