Oberon space
General Category => Общий раздел => Тема начата: Freeman от Январь 26, 2013, 08:45:08 am
-
Увидел тему (http://forum.oberoncore.ru/viewtopic.php?f=28&t=4231#p77525) на OberonCore про нас. За рекламу большое спасибо. :)
А теперь вопрос: почему наследование не может быть одним из основополагающих принципов ОС?
-
А теперь вопрос: почему наследование не может быть одним из основополагающих принципов ОС?
Отвечу, как и полагается, вопросом на вопрос: а какое именно наследование подразумевается? Наследование чего? Интерфейсов? Классов? Объектов (да, бывает и такое)?
-
Увидел тему (http://forum.oberoncore.ru/viewtopic.php?f=28&t=4231#p77525) на OberonCore про нас. За рекламу большое спасибо. :)
Сейчас они вас там порвут как тузик грелку :). У них там исповедуется цензура на творчество:
http://forum.oberoncore.ru/viewtopic.php?f=26&t=3885 (http://forum.oberoncore.ru/viewtopic.php?f=26&t=3885)
Недавно перечитывал тему по ссылке. До обсуждения Джулии, правда, там дело не дошло, зато тема прекрасно раскрыла "кто есть who".
Вот, кстати, уже началось: http://forum.oberoncore.ru/viewtopic.php?f=28&t=4231#p77540 (http://forum.oberoncore.ru/viewtopic.php?f=28&t=4231#p77540)
-
От типичной реакции оберкора тошнит уже >:(
-
От типичной реакции оберкора тошнит уже >:(
Так то оно так, но в данном случае Freeman - использует известные термины в таких сочетаниях (по факту не разьясняя их ) что терзают меня смутные сомнения...- вообщем не вижу смысла обсуждать незрелые мысли, автор коих не готов их разьяснять и отстаивать публично... - ощущение такое.. что сунули носом в помойку.. дескать ройтесь на здоровье...
-
Так то оно так... :)
Но можно было хоть вопросы задать человеку прежде чем вываливать известную реакцию.
Илья кричит:
Всё, занавес
...финиш
http://forum.oberoncore.ru/viewtopic.php?f=28&t=4231#p77525
А цитата то безобидная:
Объектно-ориентированная ОС позволяет создавать программы наследованием.
если учесть контекст:
А что у нас с наследованием? В ООП наследование — возможность взять почти пригодный класс и расширить его функциональность до нужной, решив таким образом задачу. Можно ли в классических ОС создавать программы наследованием? Взять, например, «Блокнот», расширить его и получить WordPad, а потом расширить WordPad и получить Word?
Т.е. человек просто имел в виду подход ББ к расширению моделей.
-
Т.е. человек просто имел в виду подход ББ к расширению моделей.
беда в том , что эти выводы делает ВЫ а не он, а что он имел ввиду он САМ НЕ ЗНАЕТ.. а реакция.. - нормальному человеку она - урок.. назвался ГРУЗДЕМ - ПОЛЕЗАЙ В КУЗОВ. То есть если это не бред... то в следующий раз , можно будет надеется, что Фримен представит свои идеи в более презентабельном виде, и будет готов пояснить их и отвечать за них..
-
Наследование к расширению моделей имеет крайне косвенное отношение.
-
2 DIzer
OK, подождем комментариев гордона фримена :)
-
Наследование к расширению моделей имеет крайне косвенное отношение.
Можно подробнее?
-
Возьмём в качестве частного случая модель адиабадического процесса. (Не знаю почему, но это первое, что пришло в голову...).
Это изначальная модель, которую мы будем расширять. Что мы сейчас можем с ней сделать? Задать начальные условия, а потом изменять работу и получать из модели результат.
Затем, мы расширяем систему: теперь у нас модель воздействия работы на термодинамическую систему. Например, робот-пума, жмякающая поршень. То есть, работу мы теперь задаём не напряммую, а через промежуточное звено. Поэтому, в нашу расширенную модель мы заносим начальные данные исходной модели, начальные данные устройства, выполняющего работу. Теперь, например, изменение координаты по оси z сопровождается изменением работы (линейно или нет) и получением выходных данных по нашему процессу.
И где здесь было про наследование?
P.S. Физику благополучно забыл, поэтому не особо приглядывайтесь к примеру. Ведь здесь всё равно существенным моментом было совсем другое.
-
Не понял к чему вы вообще приплели физику, когда разговор идет о программировании.
Я говорил о модели данных...
-
Каких таких данных? Сферичных? Программирование - преимущественно прикладная область деятельности. И то, что я привёл, - и есть модель данных из прикладной области.
-
Можно подумать над другими примерами. Это был просто первый пришедший в голову.
-
А теперь вопрос: почему наследование не может быть одним из основополагающих принципов ОС?
Вообще я когда почитал ваши тезисы про наследование в ОС - тоже отнесся к ним крайне скептически. Но так как до конца идею не понял (про наследованию программ), то и критиковать было нечего :)
В моей практике (С++) классическое наследование реализации работает крайне плохо. Работает хорошо в исключительных случаях (но работает, поэтому я ни разу не предлагаю избавляться от него в ОО ЯП). Намного чаще приходится наоборот раздраконивать "красивые" иерархи в старом коде и делать так, чтоб работало :) Причем на анализ всего этого (перед тем как переписать) уходит масса времени. А переписывание обычно заключается в банальной декомпозиции по процедурам (даже не компонентам).
-
Valery Solovey, вот конкретный пример из ББ:
Stores.Store* = POINTER TO ABSTRACT RECORD
dlink: Domain;
era, id: INTEGER; (* externalization era and id *)
isElem: BOOLEAN (* to preserve file format: is this an elem in the old sense? *)
END;
...
Views.View* = POINTER TO ABSTRACT RECORD (Stores.Store)
context-: Models.Context; (** stable context # NIL **)
era: INTEGER;
guard: INTEGER; (* = TrapCount()+1 if view is addressee of ongoing broadcast *)
bad: SET
END;
...
Containers.View* = POINTER TO ABSTRACT RECORD (Views.View)
model: Model;
controller: Controller;
alienCtrl: Stores.Store (* alienCtrl = NIL OR controller = NIL *)
END;
...
TextViews.View* = POINTER TO ABSTRACT RECORD (Containers.View) END;
...
TextViews.StdView = POINTER TO RECORD (View)
(* model *)
text: TextModels.Model;
org: INTEGER;
dy: INTEGER; (* 0 <= dy < Height(first line) *)
defRuler: TextRulers.Ruler;
defAttr: TextModels.Attributes;
hideMarks: BOOLEAN;
(* general state *)
cachedRd: TextSetters.Reader;
(* line grid cache *)
trailer: Line; (* trailer # NIL => trailer.eot, trailer.next # trailer *)
bot: INTEGER; (* max(f : f seen by Restore : f.b) *)
(* setter *)
setter, setter0: TextSetters.Setter (* setter # setter0 lazily detects setter change *)
END;
Есть модель хранилища -->
Расширили до представления -->
Расширили до контейнера -->
Расширили до текстового представления.
-
В моей практике (С++) классическое наследование реализации работает крайне плохо.
А никто вроде и не говорил о наследовании реализации.
-
Так я же не говорю, что принципиально нельзя. Я говорю, что есть вещи, которые действительно управляют расширением модели, и они иногда приводят к наследованию. А если вспоминать только про наследование, то очень легко забыть (или не понять, если читает новичок) саму идею.
-
Вы меня не поняли.
Я просто заменяю "наследование" словом "расширение", т.к. это имхо более правильно звучит.
Да и в Оберонах вроде принято говорить "расширение типа" вместо "потомок класса"
-
Немного в сторону систем...
Первая проблема операционных систем в том, что они развивались... хаотично, стремясь как-то устранить несовершенство ЭВМ, облегчить взаимодействие с ними. Собственно, до сих пор мне не встречались работы, которые бы рассматривали данное программное обеспечение с системных позиций, как единое целое. Нужно было работать с внешними дисковыми устройствами, появились дисковые операционные системы; потребовалась работа с графикой, добавились графические модули; стало необходимым взаимодействие компьютеров, добавились сетевые модули, интернет, безопасность и пр. и пр. Такой подход к "расширению" имеет вполне очевидный минус... каждый раз надо переписывать огромное количество кода. И тем не менее, такой подход к созданию операционных "систем" сохраняется и видимо в ближайшей перспективе не изменится. Чтобы данный подход изменился требуется ответить на такие вопросы, какова цель вычислительной техники, на каком этапе её развития мы находимся, что нас ожидает в перспективе... В принципе, сегодня эти вопросы уже вполне обсуждаемы, поскольку основные тренды развития можно отслеживать и анализировать. Понимая цель, можно говорить о системе, можно рассматривать её составные части и связи между ними... т.е. можно говорить и той части, которая называется "операционная система", её структуре/архитектуре, функциональном наполнении и пр.
Теперь о наследовании...
Наследование - это важная часть концепции объектно-ориентированного программирования (ООП). Концепция ООП мало пригодна/эффективна для написания программ или модулей, но её мощь раскрывается при создании систем. Об этом я много говорил на oberoncore несколько лет назад, в частности при рассмотрении "инструментального подхода"... когда создаются не программы, решающие какие-то конкретные задачи, а инструменты, необходимые для решения классов задач. И здесь возможности, предоставляемые концепцией ООП, раскрываются в полной мере.
Если посмотреть на ООП с позиций больших (многоуровневых) систем, то оно и полезно, и эффективно, и надёжно. В большой системе несколько уровней. Соединение уровней происходит посредством декларированного интерфейса. Данный интерфейс в нижнем уровне может быть реализован одной или более иерархий классов, от самых простых - до комплексных (агрегированных). Продуманный интерфейс позволяет независимо менять реализации уровней, не нарушая надёжности каждого из уровней...
Если кто-то помнит... когда я рассказывал о предприятии, то я начал с того, что такое предприятие, из этого понятия легко выстроилась иерархия классов предприятий (абстрактное, финансовое, логистическое (торгово-транспортное), промышленное... в полном соответствии с концепцией ООП (добавлением к классу-наследнику новых элементов/подсистем). И можно говорить о классах (т.е. наследовании) каждой функциональной подсистемы...
Примерно то же самое можно было бы делать и на уровне операционной системы... и наследование было бы весьма полезно, но...
-
Вы меня не поняли.
Я просто заменяю "наследование" словом "расширение", т.к. это имхо более правильно звучит.
Да и в Оберонах вроде принято говорить "расширение типа" вместо "потомок класса"
Ну, если речь шла про расширение записей...
Но всё равно, "меня терзают смутные сомнения". Что это за зверь такой - "почти подходящий класс"? Почему некоторые думают, что можно его взять, "расширить" и обязательно получится "подходящий класс", а не "расширенный почти подходящий класс"?
-
Гадать смысла нет. Нужно ждать комментариев от автора.
-
Valery Solovey, вот конкретный пример из ББ:
...
Но это таки случай Framework - когда вам предоставили базовый набор "заготовок", от которых наследуетесь. Вообще, оно и тут нежелательно, просто в то время, когда закладывался ББ, осознание, что наследование реалиазации надо заменять декомпозицией, ещё толком не пришло....
Что оно сейчас приходит отнюдь не только в пространстве около Оберонов, я отметил здесь: http://oberspace.dyndns.org/index.php/topic,442.msg14062.html#msg14062
-
наследование реалиазации
Автор говорил именно о наследовании реализации?
-
Там упоминалась возможность наследования нескольких классов с несовпадающими реализациями -- видимо, что бы не создавать конфликтоа при наследовании...
-
А никто вроде и не говорил о наследовании реализации.
Я как раз так понял, что речь именно о наследовании реализации. Когда говорят о наследовании интерфейсов, то обычно говорят в контексте абстрагирования от реализации.
Впрочем, как я уже говорил, заметки автора весьма черновые. В частности, пример наследования программ в виде "блокнот -> WordPad -> Word", если воспринимать его дословно, не выдерживает никакой критики. Нечего там наследовать. Реализация будет совершенно разная. Можно, конечно, притянуть сюда за уши наследование интерфейсов (типа Word можно выставить через интерфейс блокнота). Но не понятно зачем - поэтому за уши.
-
Для тех, кто до конца не понимает, почему наследование реализации - зло и почему его сравнивают даже с goto.
Вот вам строка: obj.DoSomething. Если я знаю, что в системе нет наследования реализации, я понимаю, что именно будет выполненно. Процедура DoSomething того фактического типа, который имеет obj.
Ответьте на тот же вопрос, если система пронизана наследованием реализации. Попробуйте разобраться, как прыгает поток управления, даже при вызове метода одного объекта. Вызвали из своего метода свой же другой метод - управление упрыгало фиг знает в какого предка...
Это ещё один, кстати, пример, откуда потом берётся жирность IDE. Потому что распутывать клубок структуры программы в подобных случаях без поддержки IDE очень трудно.
Второй пример: у вас есть наследование реализации от какого-то типа X. И вдруг вам нужно завести несколько реализаций X. Более простой случай - если реализации не сосуществуют во время выполнения. Например, под разные ОС. Вам придётся иметь две версии одного исходника, как-то их переключать, вместо того, чтобы просто иметь два отдельных класса - реализации базового абстрактного. При наследовании только от абстрактных классов получается придерживаться принципа - каждый вариант реализации существует в виде своего модуля, класса, и т.п. А не дремучая вариативность на уровне исходников.
Ещё хуже, если вам нужно иметь во время выполнения разные реализации X. Т.е. некоторые экземпляры Y должны иметь в своей базе одну реализацию X, некоторые - другую.
Конечно же, знатоки скажут, что ответом на обе проблемы является идиома PImpl (Pointer to implementation), когда вся реализация X выносится в отдельный объект, который указывается при инициализации X. Ну так это и будет, други мои, хороший такой шаг к композиции вместо наследования. И в большинстве случаев будет непонятно, зачем сохранять X, если PImpl может содержать сразу класс, наследуемый от Y.
-
Для тех, кто до конца не понимает, почему наследование реализации - зло и почему его сравнивают даже с goto.
Я ни до конца... ни после начала не понимаю... :)
Вот вам строка: obj.DoSomething. Если я знаю, что в системе нет наследования реализации, я понимаю, что именно будет выполненно. Процедура DoSomething того фактического типа, который имеет obj.
Совершенно верно! Если в советское время мы шли покупать обувь, то однозначно покупали сапоги кирзовые 43 размера... Всем всё было понятно... но не всегда удобно (плата за однозначность понимания.. видимо?).
Ответьте на тот же вопрос, если система пронизана наследованием реализации. Попробуйте разобраться, как прыгает поток управления, даже при вызове метода одного объекта. Вызвали из своего метода свой же другой метод - управление упрыгало фиг знает в какого предка...
Если Вы не знаете, что хотите носить, то вызывайте именно "сапоги кирзовые 43 размера"... кто же против... А мне вот кроссовки нужны на лето...
Это ещё один, кстати, пример, откуда потом берётся жирность IDE. Потому что распутывать клубок структуры программы в подобных случаях без поддержки IDE очень трудно.
Да, иметь выбор всегда... несколько затратнее, чем не иметь оного... Но мы об удобстве или о "шашечках"?
Второй пример: у вас есть наследование реализации от какого-то типа X. И вдруг вам нужно завести несколько реализаций X. Более простой случай - если реализации не сосуществуют во время выполнения. Например, под разные ОС. Вам придётся иметь две версии одного исходника, как-то их переключать, вместо того, чтобы просто иметь два отдельных класса - реализации базового абстрактного. При наследовании только от абстрактных классов получается придерживаться принципа - каждый вариант реализации существует в виде своего модуля, класса, и т.п. А не дремучая вариативность на уровне исходников.
Какая разница... сосуществуют ли объекты во время исполнения или нет?.. Две версии, под каждую "ось" всё равно придётся иметь... И классы будут разными...
Ещё хуже, если вам нужно иметь во время выполнения разные реализации X. Т.е. некоторые экземпляры Y должны иметь в своей базе одну реализацию X, некоторые - другую.
Весьма странный вывод... Совершенно непонятно, на чём он основан... Какая разница для Y с каким экземпляром какого подкласса X он взаимодействует?..
Конечно же, знатоки скажут, что ответом на обе проблемы является идиома PImpl (Pointer to implementation), когда вся реализация X выносится в отдельный объект, который указывается при инициализации X. Ну так это и будет, други мои, хороший такой шаг к композиции вместо наследования. И в большинстве случаев будет непонятно, зачем сохранять X, если PImpl может содержать сразу класс, наследуемый от Y.
А ещё лучше научиться различать красное и горячее... Наследование реализации совсем не означает и не предполагает отсутствия интерфейсов. Просто интерфейсы - это спецификации, не более того.
-
Совершенно верно! Если в советское время мы шли покупать обувь, то однозначно покупали сапоги кирзовые 43 размера... Всем всё было понятно... но не всегда удобно (плата за однозначность понимания.. видимо?).
Ну так то же самое и с goto. То, что кому-то удаётся его успешно использовать, не отменяет того факта, что в большинстве случаев применения в массовой разработке оно будет вести к запутыванию.
Вы не ставите простоту понимания, ясность структуры программы на первое место?
Это ещё один, кстати, пример, откуда потом берётся жирность IDE. Потому что распутывать клубок структуры программы в подобных случаях без поддержки IDE очень трудно.
Да, иметь выбор всегда... несколько затратнее, чем не иметь оного... Но мы об удобстве или о "шашечках"?
Иметь столь запутанную структуру, которую нельзя понять простым изучением исходника и просто уложить в голову - Вы называете удобством?
Какая разница... сосуществуют ли объекты во время исполнения или нет?.. Две версии, под каждую "ось" всё равно придётся иметь... И классы будут разными...
Ещё хуже, если вам нужно иметь во время выполнения разные реализации X. Т.е. некоторые экземпляры Y должны иметь в своей базе одну реализацию X, некоторые - другую.
Пусть у Вас есть BaseButton, класс с реализацией. От него выстроено целое дерево наследования всяких разных кнопок. В стиле VCL. И внезапно нам нужна кроссплатформенность. У нас появляется две реализации BaseButton - под Винду и Линукс. Если мы так и оставим код реализации внутри класса BaseButton, то получим две параллельных версии одного класса, одного исходника. Проблему с управлением ими и проч. Большинству, конечно, не привыкать, но я так не хочу - потому что умею делать такие архитектуры, при которых каждый класс существует только в единственном варианте (только линейный порядок дорабатываемых версий). Любая вариативность делается отдельными классами.
Другой выход, как я и говорил, не оставлять код реализации внутри класса BaseButton, а сделать pointer to implementation. Интерфейс ButtonImpl, разные его реализации - и втыкать в BaseButton статическим полем указатель на реализацию.
Но я бы изначально не ввязался с этим Буттоном в трясину наследования.
Имел бы интерфейс AbstractButton и никому не видимую базовую реализацию BaseButton, создаваемую через фабрику.
И в любых расширенных кнопках просто имел бы поле base: AbstractButton, через которое агрегировал BaseButton.
Эффект ясности от такого стиля очень хороший - и мне назад в паутину наследования реализации не хочеццца.
-
Где-то год назад в разговоре с Вами я приводил пример, как архитектура, в которой классы реализаций сокрыты (известны только интерфейсы и фабрики) позволяет решать "системные вопросы". Вам тогда ещё, насколько я помню, понравилось.
Повторю здесь, думаю, уместно:
Строго говоря... элементы не должны взаимодействовать между собой... напрямую. Они должны делать только то, что им предписано... свыше. Сделали и отдали наверх, а кто там и как дальше работает, они не ведают. Если элемент (компонент/объект) А взаимодействует с элементом Б, то это взаимодействие должно быть определено, как минимум в элементе А, но, возможно, и в элементе Б, а это, в свою очередь, означает, что элемент А не может использоваться без элемента Б и, наоборот. Такая связь "цементирует" элементы и лишает систему гибкости (возможности перестраивать связи). "Слабые связи" в системе исчезают... а за ними и сама система становится монолитом, то есть, не-системой.
Конечно, это так. Но во многих случаях надсистема не занимается "ручной передачей" каждого события между компонентами. Надсистема соединяет их какими-нибудь коммуникациями, трубами. Коммуникации и их установление относятся к надсистеме, конечно. Но протекание события от одной подсистемы другой потом уже идёт без прямого вмешательства надсистемы (хотя она всегда может пересоединить, если что). Так что косвенный вызов через полиморфный указатель, когда вызывающий знает только абстрактный тип (интерфейс) и не знает, какая там реализация на другом конце вызова, как раз похож на такую трубу.
При активном использовании в качестве интерфейсов абстрактных типов и при полном сокрытии их реализаций (т.е. одноуровневое наследование, с полным скрытием неабстрактного наследника), и использовании композиции объектов всё получается системно.
В качестве "труб" между ними оказываются указатели и операции абстрактных интерфейсов, доступные через эти указатели.
MODULE Телефония;
TYPE
Линия* = POINTER TO ABSTRACT RECORD END;
Сеанс* = POINTER TO ABSTRACT RECORD END;
Реализация* = POINTER TO ABSTRACT RECORD END;
VAR
стандартная-: Реализация;
PROCEDURE (л: Линия) Звонить* (номер): Сеанс, NEW, ABSTRACT;
PROCEDURE (л: Линия) Входящий* (): Сеанс, NEW, ABSTRACT;
PROCEDURE (сн: Сеанс) Сказать* (сообщение), NEW, ABSTRACT;
PROCEDURE (сн: Сеанс) Слушать* (сообщение), NEW, ABSTRACT;
PROCEDURE (сн: Сеанс) Закрыть*, NEW, ABSTRACT;
PROCEDURE (р: Реализация) НоваяЛиния* (): Линия, NEW, ABSTRACT;
PROCEDURE ЗадатьСтандартную* (реализация: Реализация);
BEGIN
стандартная := реализация
END ЗадатьСтандартную;
END Телефония.
MODULE Секретари;
IMPORT Телефония;
TYPE
Секретарь* = ABSTRACT RECORD END;
Реализация* .... аналогично ....
VAR
стандартная*: Реализация;
.... разные процедуры секретаря ...
PROCEDURE (с: Секретарь) СестьНаТелефон* (линия: Телефония.Линия), NEW, ABSTRACT;
PROCEDURE (с: Секретарь) Помогать* (кому: Секретарь), NEW, ABSTRACT;
END Секретари.
Реальных реализаций телефонии и секретарей у нас может быть много. В разных модулях. Никто в системе, кроме конфигурирующих процедур, не знает про эти модули.
Стандартные реализации привязывает какой-нибудь конфигурирующий модуль:
MODULE Config;
PROCEDURE Setup;
BEGIN
Телефония.ЗадатьСтандартную(ТелефонияВариант1.реализация);
Секретари.ЗадатьСтандартную(СекретариВариант1.реализация)
END Setup;
END Config;
Специфические для нашего приложения особенности вынесем в наш модуль конфигурации:
MODULE НашиРесурсы;
IMPORT Телефония, СекретариВариантЭкстра;
VAR
телефония-: Телефония.Реализация;
секретари-: Секретари.Реализация;
PROCEDURE Иниц;
BEGIN
телефония := Телефония.стандартная;
секретари := СекретариВариантЭкстра.реализация;
END Иниц;
BEGIN
Иниц
END НашиРесурсы;
Наконец, есть наш прикладной модуль:
MODULE НашОфис;
IMPORT Телефония, Секретари, НашиРесурсы;
VAR
телЛиния: Телефония.Линия;
секретарь1, секретарь2: Секретари.Секретарь;
PROCEDURE Иниц;
BEGIN
телЛиния := НашиРесурсы.телефония.НоваяЛиния();
секретарь1 := НашиРесуры.секретари.НовыйСекретарь();
секретарь2 := НашиРесурсы.секретари.НовыйСекретарь();
секретарь1.СестьНаТелефон(телЛиния);
секретарь2.Помогать(секретарь1)
END Иниц;
END НашОфис.
Пожалуйста, ни реализация секретарей, ни реализация телефонии не знают друг про друга. Модуль НашОфис вообще ничего не знает, где реализованы эти компоненты. Он создаёт их экземпляры и соединяет. И они начинают вместе работать.
Модуль НашиРесурсы, как отдел обеспечения, знает немного больше про то, какие реализации используются. Но тщательно скрывает эти детали от модуля НашОфис. Но и то, телефонию он использует стандартную, и только для секретарей "заморачивается" знанием конкретной реализации.
Да, у нас сейчас офис и собрание наших ресурсов сделаны статично — как модули, это оправдано, если это верхний уровень системы — и мы гарантированно не захотим множить его экземпляры и варианты. Если же это промежуточный уровень системы, то мы продолжим абстрагировать понятие офиса и ресурсов офиса в том же духе, как телефонию и секретарь, с возможностью многих реализаций и т.п.
-
Совершенно верно! Если в советское время мы шли покупать обувь, то однозначно покупали сапоги кирзовые 43 размера... Всем всё было понятно... но не всегда удобно (плата за однозначность понимания.. видимо?).
Ну так то же самое и с goto. То, что кому-то удаётся его успешно использовать, не отменяет того факта, что в большинстве случаев применения в массовой разработке оно будет вести к запутыванию.
Вы не ставите простоту понимания, ясность структуры программы на первое место?
Во-первых, почему должно возникать "запутывание"? Что такое "массовая разработка"? Может быть речь о многократном использовании?
Во-вторых, я вообще не говорил о программах... А на ясность системы... наследование реализации и интерфейсы уровней системы (а не сущностей!) имеют только положительное влияние... Делают её и проще, и эффективнее, и удобнее.
Это ещё один, кстати, пример, откуда потом берётся жирность IDE. Потому что распутывать клубок структуры программы в подобных случаях без поддержки IDE очень трудно.
Да, иметь выбор всегда... несколько затратнее, чем не иметь оного... Но мы об удобстве или о "шашечках"?
Иметь столь запутанную структуру, которую нельзя понять простым изучением исходника и просто уложить в голову - Вы называете удобством?
Удобством я называю возможность использовать то, что наиболее подходит для данной ситуации. А неудобством... сапоги кирзовые 43 размера для всех ситуаций... Откуда берётся Ваш тезис о "запутанности структуры" для меня так и осталось загадкой.
Какая разница... сосуществуют ли объекты во время исполнения или нет?.. Две версии, под каждую "ось" всё равно придётся иметь... И классы будут разными...
Ещё хуже, если вам нужно иметь во время выполнения разные реализации X. Т.е. некоторые экземпляры Y должны иметь в своей базе одну реализацию X, некоторые - другую.
Пусть у Вас есть BaseButton, класс с реализацией. От него выстроено целое дерево наследования всяких разных кнопок. В стиле VCL. И внезапно нам нужна кроссплатформенность. У нас появляется две реализации BaseButton - под Винду и Линукс. Если мы так и оставим код реализации внутри класса BaseButton, то получим две параллельных версии одного класса, одного исходника. Проблему с управлением ими и проч.
Простите... тут я не понял... о каких "проблемах управления" идёт речь? О том, что ОС сообщает о том, что курсор "мышки" "наехал" на клавишу"... то, что пользователь нажал "клавишу"?.. То есть, проблема в том, что не был абстрагирован уровень взаимодействия с ОС?.. Ну, так о чём печаль-то?.. Надо просто поступать более обдуманно.
Большинству, конечно, не привыкать, но я так не хочу - потому что умею делать такие архитектуры, при которых каждый класс существует только в единственном варианте (только линейный порядок дорабатываемых версий).
Да, многие из нас родом из СССР... Я тоже так умею, но... не считаю, что это правильно.
Любая вариативность делается отдельными классами.
... посредством наследования реализации?..
Другой выход, как я и говорил, не оставлять код реализации внутри класса BaseButton, а сделать pointer to implementation. Интерфейс ButtonImpl, разные его реализации - и втыкать в BaseButton статическим полем указатель на реализацию.
Но я бы изначально не ввязался с этим Буттоном в трясину наследования.
Правильно... нечего баловать... сапоги кирзовые 43 размера... для всех... даже для тех у кого 38 размер... или 45...
Имел бы интерфейс AbstractButton и никому не видимую базовую реализацию BaseButton, создаваемую через фабрику.
И в любых расширенных кнопках просто имел бы поле base: AbstractButton, через которое агрегировал BaseButton.
Эффект ясности от такого стиля очень хороший - и мне назад в паутину наследования реализации не хочеццца.
Ну, что здесь скажешь... А я когда-то показывал простой пример... когда пользователю надоедали прямоугольные кнопки и он менял их эллипсоидные на всех формах, во всех приложениях... настраивал цвета и шрифты... если хотелось... А почему бы и нет?.. Код переписывать не приходилось, а пользователю виднее...
-
Где-то год назад в разговоре с Вами я приводил пример, как архитектура, в которой классы реализаций сокрыты (известны только интерфейсы и фабрики) позволяет решать "системные вопросы". Вам тогда ещё, насколько я помню, понравилось.
Мне и сейчас это нравится. Сокрытие реализации - весьма полезно. Интерфейсы специфицированы на определённом уровне системы. Всё правильно, давно отработано и удобно для использования и разработчиками и пользователями.
Повторю здесь, думаю, уместно:
Строго говоря... элементы не должны взаимодействовать между собой... напрямую. Они должны делать только то, что им предписано... свыше. Сделали и отдали наверх, а кто там и как дальше работает, они не ведают. Если элемент (компонент/объект) А взаимодействует с элементом Б, то это взаимодействие должно быть определено, как минимум в элементе А, но, возможно, и в элементе Б, а это, в свою очередь, означает, что элемент А не может использоваться без элемента Б и, наоборот. Такая связь "цементирует" элементы и лишает систему гибкости (возможности перестраивать связи). "Слабые связи" в системе исчезают... а за ними и сама система становится монолитом, то есть, не-системой.
Конечно, это так. Но во многих случаях надсистема не занимается "ручной передачей" каждого события между компонентами.
Ручной?.. Она просто передаёт события/сообщения от отправителя к получателю.
Надсистема соединяет их какими-нибудь коммуникациями, трубами. Коммуникации и их установление относятся к надсистеме, конечно. Но протекание события от одной подсистемы другой потом уже идёт без прямого вмешательства надсистемы (хотя она всегда может пересоединить, если что). Так что косвенный вызов через полиморфный указатель, когда вызывающий знает только абстрактный тип (интерфейс) и не знает, какая там реализация на другом конце вызова, как раз похож на такую трубу.
Совершенно верно.
При активном использовании в качестве интерфейсов абстрактных типов и при полном сокрытии их реализаций (т.е. одноуровневое наследование, с полным скрытием неабстрактного наследника), и использовании композиции объектов всё получается системно.
В качестве "труб" между ними оказываются указатели и операции абстрактных интерфейсов, доступные через эти указатели.
Тоже правильно.
А теперь добавьте вариабельность... от ситуации... и это добавит удобства/гибкости... при полном сохранении ясности. В чём проблема-то?..
Реальных реализаций телефонии и секретарей у нас может быть много. В разных модулях. Никто в системе, кроме конфигурирующих процедур, не знает про эти модули.
...
Пожалуйста, ни реализация секретарей, ни реализация телефонии не знают друг про друга. Модуль НашОфис вообще ничего не знает, где реализованы эти компоненты. Он создаёт их экземпляры и соединяет. И они начинают вместе работать.
Модуль НашиРесурсы, как отдел обеспечения, знает немного больше про то, какие реализации используются. Но тщательно скрывает эти детали от модуля НашОфис. Но и то, телефонию он использует стандартную, и только для секретарей "заморачивается" знанием конкретной реализации.
Да, ему и не надо знать о реализациях... ему достаточно знать о вариантах, существующих реализаций, то есть, вариантные спецификации... и всё.
-
Во-первых, почему должно возникать "запутывание"?
...
Откуда берётся Ваш тезис о "запутанности структуры" для меня так и осталось загадкой.
Ну это-то как раз легко понять:
Закон Мерфи. (http://lib.ru/ANEKDOTY/marphy.txt)
Если какая-нибудь неприятность может случиться, она случается.
-
Для тех, кто до конца не понимает, почему наследование реализации - зло и почему его сравнивают даже с goto.
...
Вы это кому повествуете?
Автор говорил именно о наследовании реализации?
-
Сокрытие реализации - весьма полезно.
Сокрытие реализации и наследование реализации исключают друг друга. В большинстве случаев.
-
Сокрытие реализации - весьма полезно.
Сокрытие реализации и наследование реализации исключают друг друга. В большинстве случаев.
Ни в коей мере...
-
Чтобы выполнить наследование реализации, к ней должен быть доступ. А чтобы иметь доступ, нужно как минимум отсутствие сокрытия.
-
Чтобы выполнить наследование реализации, к ней должен быть доступ. А чтобы иметь доступ, нужно как минимум отсутствие сокрытия.
Для наследования доступ не нужен. Берём то, что есть и добавляем то, что считаем необходимым.
-
В таком случае, я под наследованием реализации в этой теме понимал другое: наследуемся и используем список методов родителя как библиотеку.
-
В таком случае, я под наследованием реализации в этой теме понимал другое: наследуемся и используем список методов родителя как библиотеку.
Насколько я понимаю в данном вопросе... есть "наследование" интерфейса (interface inheritance) и наследование реализации (implementation inheritance).
Наследование интерфейса... это вообще говоря... не наследование, а получение (присвоение) сигнатуры. Зачем это обозвали "наследованием"... трудно объяснить, путаницу внесли... только.
Наследование реализации может иметь несколько "уровней" защиты кода.
-
Наследование реализации может иметь несколько "уровней" защиты кода.
Если не сложно, приведите, пожалуйста, пример, чтобы было более понятно. То что хотел сказать Илья из его примера вроде бы понято, а Ваши высказывания без примера не воспринимаются
-
Наследование реализации может иметь несколько "уровней" защиты кода.
Если не сложно, приведите, пожалуйста, пример, чтобы было более понятно. То что хотел сказать Илья из его примера вроде бы понято, а Ваши высказывания без примера не воспринимаются
Нет проблем... см. слова public, protected, private (С++, Java, Delphi etc.)...
-
Нет проблем... см. слова public, protected, private (С++, Java, Delphi etc.)...
К наследованию реализации имеет отношение только protected. Когда я его (protected) вижу в коде - у меня заранее начинает болеть голова и хочется идти за очередной чашкой кофе. Предстоит очередное распутывание кода с прыжками (goto, ага) между разными кусками куда, завязанными между собой самыми причудливыми образами.
-
Нет проблем... см. слова public, protected, private (С++, Java, Delphi etc.)...
К наследованию реализации имеет отношение только protected. Когда я его (protected) вижу в коде - у меня заранее начинает болеть голова и хочется идти за очередной чашкой кофе. Предстоит очередное распутывание кода с прыжками (goto, ага) между разными кусками куда, завязанными между собой самыми причудливыми образами.
Наследование реализации не зависит от этих... эпитетов... Это уровни защиты кода/ограничения видимости, не более того...
-
Для тех, кто до конца не понимает, почему наследование реализации - зло и почему его сравнивают даже с goto.
Вот вам строка: obj.DoSomething. Если я знаю, что в системе нет наследования реализации, я понимаю, что именно будет выполненно. Процедура DoSomething того фактического типа, который имеет obj.
Ответьте на тот же вопрос, если система пронизана наследованием реализации. Попробуйте разобраться, как прыгает поток управления, даже при вызове метода одного объекта. Вызвали из своего метода свой же другой метод - управление упрыгало фиг знает в какого предка...
Если мы имеем нечто вроде "A* obj" (пусть у нас С++), где A это конкретный (не абстрактный) класс, то даже если он от кого-то там унаследовался (по реализации естественно), то узнать что именно случится если будет вызвано obj->DoSomething() довольно просто - в худшем случае придется обойти ациклический ориентированный граф.
А вот если "A" - это интерфейс, то все, алес. Узнать что именно произойдет при вызове obj->DoSomething() не представляется возможным - там может быть абсолютно что угодно. В общем случае единственным способом узнать это - использовать пошаговый отладчик. В точности то же самое, что и в случае goto (и то же что и при использовании процедурных типов).
Когда я вижу в чужом коде активное использование интерфейсов - знаю сразу, будет головная боль и ползание под отладчиком (и не потому что что-то глючит, а потому что иначе разобраться в коде невозможно).
Это ещё один, кстати, пример, откуда потом берётся жирность IDE. Потому что распутывать клубок структуры программы в подобных случаях без поддержки IDE очень трудно.
Ну да, ну да. А если у нас интерфейсы, то хоть через жирную IDE, хоть без оной, распутать клубок не возможно даже теоретически. Поэтому там жиные IDE и не нужны :-)
(на самом деле "жирные" IDE нужны для проектов реального размера, то есть с полмиллиона строк кода)
Второй пример: у вас есть наследование реализации от какого-то типа X. И вдруг вам нужно завести несколько реализаций X. Более простой случай - если реализации не сосуществуют во время выполнения. Например, под разные ОС. Вам придётся иметь две версии одного исходника, как-то их переключать, вместо того, чтобы просто иметь два отдельных класса - реализации базового абстрактного. При наследовании только от абстрактных классов получается придерживаться принципа - каждый вариант реализации существует в виде своего модуля, класса, и т.п. А не дремучая вариативность на уровне исходников.
Ничего не понял. Не вижу разницы. Хоть у меня интерфейс и его реализация, хоть два класса в иерархии наследования реализации, один фиг для операционной системы A у меня будет исходник Xa, для операционной системы B у меня будет Xb, и все. Выбор реализации для сборки ложится на плечи системы сборки. Тот кто отнаследовался от X, тому глубоко будет пофиг что там внизу на самом деле - Xa, или Xb.
Ещё хуже, если вам нужно иметь во время выполнения разные реализации X. Т.е. некоторые экземпляры Y должны иметь в своей базе одну реализацию X, некоторые - другую.
А кто-то предлагал наследование реализации как ЕДИНСТВЕННЫЙ механизм для декомпозиции задачи?
PS. Проблема наследования реализации, да и вообще наследования, не в том что ты описываешь, а в том, что это слишком высокоуровневый и весьма специфичный механизм. Как и любой подобный механизм, оно с блеском решает ряд задач, и с блеском же проваливает другую часть задачек. Это как "контент как интерфейс" в ББ - для узкого ряда задач оно отлично работает, а для других задач оно не применимо в принципе (хотя можно попробовать натянуть, получив в результате неюзабельную переусложненную какашку). Но это же не повод отказываться от подобного мезанизма вообще?
-
Ничего не понял. Не вижу разницы. Хоть у меня интерфейс и его реализация, хоть два класса в иерархии наследования реализации, один фиг для операционной системы A у меня будет исходник Xa, для операционной системы B у меня будет Xb, и все. Выбор реализации для сборки ложится на плечи системы сборки. Тот кто отнаследовался от X, тому глубоко будет пофиг что там внизу на самом деле - Xa, или Xb.
А у меня вот никогда не бывает двух реализаций одного модуля. Они обособляются в модули (читай "классы") со своими именами. Например, X_win и X_lin. Более того, они могут присутствовать в готовом комплекте одновременно. Этим я могу достигать занятного эффекта, когда большинство откомпилированных модулей не имеют ОС-зависимого кода и потому бинарно совместимы и с Win, и c Lin; присутствуют не перекрывающиеся по именам модули ОС-зависимых реализаций - и два пускача, для каждой ОС. Т.е. бинарно совместимый с двумя ОС комплект.
Если в системе где-то затешется класс X, для которого должны быть две версии исходника - а нужную выбирает система сборки, то такое невозможно.
-
А вот если "A" - это интерфейс, то все, алес. Узнать что именно произойдет при вызове obj->DoSomething() не представляется возможным - там может быть абсолютно что угодно. В общем случае единственным способом узнать это - использовать пошаговый отладчик. В точности то же самое, что и в случае goto (и то же что и при использовании процедурных типов).
Илья, мне кажется это достаточно справедливо. Просто Вы работаете в основном на ББ, где все знаете от и до, причем на своих проектах. А если бы пришлось разбираться с аналогичным чужим кодом и причем не в блекбокс?
-
Ничего не понял. Не вижу разницы. Хоть у меня интерфейс и его реализация, хоть два класса в иерархии наследования реализации, один фиг для операционной системы A у меня будет исходник Xa, для операционной системы B у меня будет Xb, и все. Выбор реализации для сборки ложится на плечи системы сборки. Тот кто отнаследовался от X, тому глубоко будет пофиг что там внизу на самом деле - Xa, или Xb.
А у меня вот никогда не бывает двух реализаций одного модуля. Они обособляются в модули (читай "классы") со своими именами. Например, X_win и X_lin. Более того, они могут присутствовать в готовом комплекте одновременно. Этим я могу достигать занятного эффекта, когда большинство откомпилированных модулей не имеют ОС-зависимого кода и потому бинарно совместимы и с Win, и c Lin; присутствуют не перекрывающиеся по именам модули ОС-зависимых реализаций - и два пускача, для каждой ОС. Т.е. бинарно совместимый с двумя ОС комплект.
Дык это уже зависит от целей. Во многих случаях удобней иметь "деревянную" программу - то есть программу где все прибито гвоздями на этапе компиляции. Потому, что это надежнее и быстрее.
А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?
-
Наследование реализации не зависит от этих... эпитетов... Это уровни защиты кода/ограничения видимости, не более того...
Да, не зависит. protected - это просто такой индикатор того, что наследование реализации используется скорее всего не по делу и что задача плохо декомпозирована (базовый класс калечный и оставляет наследникам возможность поставить костыли).
-
Да, не зависит. protected - это просто такой индикатор того, что наследование реализации используется скорее всего не по делу и что задача плохо декомпозирована (базовый класс калечный и оставляет наследникам возможность поставить костыли).
Т.е., с тем же успехом можно писать public - но public для потрохов писать не кошерно (во всех книжках про это написано). Поэтому пишем protected - и инкапсуляция типа есть и думать лишний раз не надо.
-
Да, не зависит. protected - это просто такой индикатор того, что наследование реализации используется скорее всего не по делу и что задача плохо декомпозирована (базовый класс калечный и оставляет наследникам возможность поставить костыли).
С friend'ами, кстати, тоже самое. Инструмент точечного применения, который любят использовать не по делу. Лучше чем protected, потому что все левые сущности явно прописаны.
-
А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?
Хм, а это как?? Метамеханизмы всяких .NET-ов?
-
2 Alexus:
Про сокрытую реализацию Вы недопоняли.
Имеется в виду, что доступен для всех только абстрактный класс, допустим, AbstractButton. Любой конкретный Button недоступен в принципе. А могут быть только созданы его экземпляры через фабрику (функцию или фабричный объект). А работать с ним будут как с AbstractButton.
-
А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?
Хм, а это как?? Метамеханизмы всяких .NET-ов?
Да нет, никаких метамеханизмов дотнетов, обычный Smalltalk или даже возможно Objective-C.
Ну подумай сам, что тут нас может остановить? (если не зацикливаться на какой-то конкретной реализации наследования). Для подобного даже виртуальный машина не нужна.
Если мы желаем абсолютно все делать через ООП, то нам нужна полноценный его реализация, без искусственных ограничений. (к счастью в С++ никто никогда не предлагал делать все исключительно через ООП, в нем достаточно других, ортогональных методов)
-
2 Alexus:
Про сокрытую реализацию Вы недопоняли.
Имеется в виду, что доступен для всех только абстрактный класс, допустим, AbstractButton. Любой конкретный Button недоступен в принципе. А могут быть только созданы его экземпляры через фабрику (функцию или фабричный объект). А работать с ним будут как с AbstractButton.
Илья Евгеньевич, мне кажется, что это Вы недопоняли... Надо либо перестать использовать общеупотребимые термины, либо использовать их по назначению. А вкладывать своё понимание... без предупреждения читателей... не доблесть.
-
Илья Евгеньевич, мне кажется, что это Вы недопоняли... Надо либо перестать использовать общеупотребимые термины, либо использовать их по назначению
А в итоге просветите, пжста, Ваше отношение к "наследованию реализации" (или как это теперь правильно назвать?) совпадает с отношением к ним Ильи? Если нет, то я так и не понял, каково Ваше отношение к "наследованию реализации" в применении к проектированию программных систем, как именно оно может/должно использоваться.
-
Илья Евгеньевич, мне кажется, что это Вы недопоняли... Надо либо перестать использовать общеупотребимые термины, либо использовать их по назначению
А в итоге просветите, пжста, Ваше отношение к "наследованию реализации" (или как это теперь правильно назвать?) совпадает с отношением к ним Ильи? Если нет, то я так и не понял, каково Ваше отношение к "наследованию реализации" в применении к проектированию программных систем, как именно оно может/должно использоваться.
Наследование реализации, или просто наследование1 является очень эффективной парадигмой при разработке систем. Как это применяется я показывал на примере проекта СУБД (http://forum.oberoncore.ru/viewtopic.php?f=28&t=3500). Для разработки программ наследование необходимо в значительно меньшей степени.
То, что Илья Евгеньевич называет "наследованием" реализации... практической пользы не даёт по сравнению с тем, что в ООП называют наследованием. К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
---
1 "Наследование" интерфейсов опрометчиво назвали "наследованием", поскольку порождают этим путаницу.
-
Так в том-то и дело, что настоящее наследование к "наследованию реализации", отношения практически не имеет. И Илья с Вами согласен, что оно практической пользы не даёт.
-
Так в том-то и дело, что настоящее наследование к "наследованию реализации", отношения практически не имеет. И Илья с Вами согласен, что оно практической пользы не даёт.
Господа, вы меня совсем запутали.
Итак, раскладываем по полочкам:
1) alexus утверждает что наследование у интерфейсов это не наследование.
2) Valery Solovey утверждает что Илья согласен с alexus'ом (и видимо сам Valery Solovey тоже согласен) и что настоящее наследование к наследованию реализации не имеет отношения.
Пардон, а что тогда остается? Интерфейсов наследование отпадает (1), реализации наследование тоже отпадает (2). Ы?
-
То, что Илья Евгеньевич называет "наследованием" реализации... практической пользы не даёт по сравнению с тем, что в ООП называют наследованием. К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
А на чём ещё основаны "возможности ОО-концепции", как не в полиморфизме (возможности выразить отношения "род-вид" и потом обеспечить принцип Барбары Лисков:, если A` является разновидностью А, использовать его всюду, где и А) и в виртуализации (позднем связывании вызова)?
А повторное использование, извиняйте, и без наследования реализации обеспечить можно, при этом придётся больше подумать над структурой - и она будет лучше (потому что не будет соблазна пойти самым кратчайшим путём, "шоб только заработало побыстрее"). Я не сторонник запрещения наследования в языке (и в КП оно есть). Но я за ограничение его использования, как специфического средства.
-
Я не сторонник запрещения наследования в языке (и в КП оно есть). Но я за ограничение его использования, как специфического средства.
Вот конкретно тут - у нас консенсус. Слишком это мощное и страшное средство чтобы его использовать на право и на лево, как и динамическая загрузка модулей и активное использование метаинформации/рефлекшина (особенно страшно тут это все в сочетании). В 90% случаев использования динамической загрузки модулей за оную загрузку надо руки отрывать на месте. Потом разобраться в таком коде решительно не возможно.
-
Так в том-то и дело, что настоящее наследование к "наследованию реализации", отношения практически не имеет. И Илья с Вами согласен, что оно практической пользы не даёт.
Господа, вы меня совсем запутали.
Итак, раскладываем по полочкам:
1) alexus утверждает что наследование у интерфейсов это не наследование.
Естественно... (А запутали Вас не мы, а тот кто эти совершенно разные понятия обозвал одинаково...)
2) Valery Solovey утверждает что Илья согласен с alexus'ом (и видимо сам Valery Solovey тоже согласен) и что настоящее наследование к наследованию реализации не имеет отношения.
Пардон, а что тогда остается? Интерфейсов наследование отпадает (1), реализации наследование тоже отпадает (2). Ы?
Илья Евгеньевич говорит о некоем специфическом "наследовании", которое он почему-то называет "наследованием реализации"
Имеется в виду, что доступен для всех только абстрактный класс, допустим, AbstractButton. Любой конкретный Button недоступен в принципе. А могут быть только созданы его экземпляры через фабрику (функцию или фабричный объект). А работать с ним будут как с AbstractButton.
Но полноценное/нормальное наследование реализации в ООП не запрещает создавать классы-потомки и наследоваться от них... сколько угодно... То "наследование", о котором говорит Илья Евгеньевич, я считаю ущербным и практически бесполезным (по-крайней мере, в сравнении с нормальным наследованием).
-
Собственно, мощным и страшным его делает только принцип подстановки.
Ибо появляется динамический тип, а отсюда и динамический полиморфизм.
Соответственно, напрашивается вопрос: а не сделать ли это дело явно управляемым в языке.
То есть, добавить типа ключевое слово, по которому принцип подстановки для данного типа разрешен.
А по умолчанию - запрещен. Как наследование в КП.
-
То, что Илья Евгеньевич называет "наследованием" реализации... практической пользы не даёт по сравнению с тем, что в ООП называют наследованием. К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
А на чём ещё основаны "возможности ОО-концепции", как не в полиморфизме (возможности выразить отношения "род-вид" и потом обеспечить принцип Барбары Лисков:, если A` является разновидностью А, использовать его всюду, где и А) и в виртуализации (позднем связывании вызова)?
ОО-концепция основана на "трёх китах"
- полиморфизм;
- инкапсуляция;
- наследование.
Полиморфизм обеспечивает многообразие форм одного и того же. По сути, полиморфными могут быть не только методы, но и сами объекты. Полиморфизм может существовать не только в рамках иерархии классов, но и как самостоятельное явление. Собственно, "наследование интерфейсов" - это частный случай проявления полиморфизма.
Инкапсуляция в ООП решает две большие задачи: объединение кода и данных, а также их сокрытие (защита от "дурака").
Наконец, наследование... позволяет создавать новые классы на основе существующих, без переписывания последних.
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается. Использовать надо объект того класса, который нужен... Класс-потомок можно использовать вместо класса-предка, но поведение класса-потомка может кардинально отличаться от поведения класса-предка (поэтому "использовать всюду"... нонсенс).
А повторное использование, извиняйте, и без наследования реализации обеспечить можно, при этом придётся больше подумать над структурой - и она будет лучше (потому что не будет соблазна пойти самым кратчайшим путём, "шоб только заработало побыстрее"). Я не сторонник запрещения наследования в языке (и в КП оно есть). Но я за ограничение его использования, как специфического средства.
Любой инструмент надо использовать по назначению.
Любым инструментом надо уметь пользоваться.
... и надо представлять, какие инструменты нужны для решения каждой конкретной задачи...
(так легче жить... и шишек меньше, IMHO)
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается.
Лисков - это она.
-
Любой инструмент надо использовать по назначению.
Любым инструментом надо уметь пользоваться.
... и надо представлять, какие инструменты нужны для решения каждой конкретной задачи...
(так легче жить... и шишек меньше, IMHO)
Вы рассуждаете почему-то только с позиций "умного себя". Так и структурное программирование, если Вашими рассуждениями следовать, нафиг не сдалось.
На самом деле, насколько меньше ошибок стало в ПО и насколько оно стало сопровождаемей - общеизвестный факт.
Потому что 90% ПО, нас окружающего, создают не "умные Вы", а люди, которые, в лучшем случае, ещё только идут к уровню экспертов, а в худшем - никуда не идущие.
Если не выработать дисциплинирующие рекомендации, помогающие избежать граблей в основной массе задач, то люди так и будут набивать шишки себе и другим :)
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается.
Лисков - это она.
А она не может быть автором?..
-
Любой инструмент надо использовать по назначению.
Любым инструментом надо уметь пользоваться.
... и надо представлять, какие инструменты нужны для решения каждой конкретной задачи...
(так легче жить... и шишек меньше, IMHO)
Вы рассуждаете почему-то только с позиций "умного себя". Так и структурное программирование, если Вашими рассуждениями следовать, нафиг не сдалось.
Где это я плохо высказывался о структурном программировании? С чего бы это "нафиг не сдалось"? Думаю, что Вы следуете не моим рассуждениям, а неким собственным представлениям об оных...
На самом деле, насколько меньше ошибок стало в ПО и насколько оно стало сопровождаемей - общеизвестный факт.
Именно...
Потому что 90% ПО, нас окружающего, создают не "умные Вы", а люди, которые, в лучшем случае, ещё только идут к уровню экспертов, а в худшем - никуда не идущие.
Ну, я о людях плохо не думаю... априори...
Если не выработать дисциплинирующие рекомендации, помогающие избежать граблей в основной массе задач, то люди так и будут набивать шишки себе и другим :)
Рекомендации рекомендациям рознь... равно, как и дисциплины...
-
Наконец, наследование... позволяет создавать новые классы на основе существующих, без переписывания последних.
Это можно сделать и без наследования. Паттерн Wrapper - я внутри своего MegaButton буду иметь агрегированный SimpleButton (но, конечно, работая с ним как с AbstractButton, ибо тип SimpleButton нигде не используется, всё только через фабрику) и обращаться к нему, когда мне нужно использование его поведения. Вместо супервызова - явный вызов сокрытого внутри объекта.
Проект СУБД я помню, внимательно смотрел, погляжу ещё раз и попробую переформулировать без наследования :)
-
Наконец, наследование... позволяет создавать новые классы на основе существующих, без переписывания последних.
Это можно сделать и без наследования.
Да, можно... Вопрос: ЗАЧЕМ?
Проект СУБД я помню, внимательно смотрел, погляжу ещё раз и попробую переформулировать без наследования :)
Хм?.. А перевести в мирное русло... не пробовали?
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается.
Лисков - это она.
А она не может быть автором?..
Сочетание "ссылка на Б. Лискова" подразумевает, что это "он".
-
Это можно сделать и без наследования.
Да, можно... Вопрос: ЗАЧЕМ?
[/quote]
Потому что это будет явно и прозрачно, с полной ответственностью программиста за то, что он делает.
Он объявляет свой MegaButton как расширение AbstractButton - он должен определить ВСЕ методы AbstractButton, подумать над ними - может быть, значительная часть из них и будет тупо состоять из вызова this.base.Method() (что тут является аналогом супервызова) - но он будет явно принимать это решение.
А не тупо "перекрыть-переклепать" то, что ему там не нравится, в надежде, что всё остальное будет "дёргаться" автоматически.
Конечно, не надо создавать такие классы, как в VCL - с десятками методов. В большинстве случаев, если у объекта больше десятка методов, его уже пора "резать" на несколько.
Проект СУБД я помню, внимательно смотрел, погляжу ещё раз и попробую переформулировать без наследования :)
Хм?.. А перевести в мирное русло... не пробовали?
[/quote]
Посмотрел. Там наследование, например, применяется для реализации разных типов атрибутов.
Атрибут (Фиксированный размер (числа, временные), Произвольный размер (строки, blob)).
Конечно, наследование тут полезно, но не обязательно реализации.
Можем сделать для них дерево абстрактных классов без реализаций.
Затем уже делаем реализацию каждого "терминального" класса из дерева. Реализации полностью независимы друг от друга, ничего не знают друг про друга. Потом замечаем, что реализация, допустим, блоба, в чём-то начинает повторять код реализации строк. Мы сразу же выносим этот код в некоторую базовую библиотеку, состоящую из функций или наших служебных классов. Т.е. код, который бы хотелось наследовать (засунуть в класс "Произвольный размер", чтобы потом от притащился автоматом при наследовании и в строки, и в блобы) мы просто выносим отдельно в свои служебные модули. Возникнут какие-то внутрение служебные классы, в которых будет зафиксирована вот эта общность реализаций разных атрибутов.
-
Наконец, наследование... позволяет создавать новые классы на основе существующих, без переписывания последних.
Это можно сделать и без наследования. Паттерн Wrapper - я внутри своего MegaButton буду иметь агрегированный SimpleButton (но, конечно, работая с ним как с AbstractButton, ибо тип SimpleButton нигде не используется, всё только через фабрику) и обращаться к нему, когда мне нужно использование его поведения. Вместо супервызова - явный вызов сокрытого внутри объекта.
Если принцип подстановки не использовать НИКОГДА, то можно обйтись и без наследования.
Но вопрос требует более тщательного изучения: так ли уж нужен этот самый принцип подстановки ? В конце-концов, обходились же раньше без него... :)
-
К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
Как по-Вашему, в каких языках наиболее правильно реализованы концепции ООП?
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается.
Лисков - это она.
А она не может быть автором?..
Сочетание "ссылка на Б. Лискова" подразумевает, что это "он".
Да, ошибся, простите.
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается. Использовать надо объект того класса, который нужен... Класс-потомок можно использовать вместо класса-предка, но поведение класса-потомка может кардинально отличаться от поведения класса-предка (поэтому "использовать всюду"... нонсенс).
http://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков (http://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков)
Пусть является свойством, верным относительно объектов некоторого типа . Тогда также должно быть верным для объектов типа , где является подтипом типа .
Роберт С. Мартин определил[3] этот принцип так:
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом.
...
Более простыми словами можно сказать, что поведение наследуемых классов не должно противоречить поведению, заданному базовым классом, то есть поведение наследуемых классов должно быть ожидаемым для кода, использующего переменную базового типа.
Если "поведение класса-потомка может кардинально отличаться от поведения класса-предка", то это являетя нарушением принципа подстановки Лисков.
А если так подумать, то может быть такому потомку нечего делать в этой иерархии классов?
-
Потому что это будет явно и прозрачно, с полной ответственностью программиста за то, что он делает.
Он объявляет свой MegaButton как расширение AbstractButton - он должен определить ВСЕ методы AbstractButton, подумать над ними - может быть, значительная часть из них и будет тупо состоять из вызова this.base.Method() (что тут является аналогом супервызова) - но он будет явно принимать это решение.
А не тупо "перекрыть-переклепать" то, что ему там не нравится, в надежде, что всё остальное будет "дёргаться" автоматически.
Конечно, не надо создавать такие классы, как в VCL - с десятками методов. В большинстве случаев, если у объекта больше десятка методов, его уже пора "резать" на несколько.
То есть, "обжегшить на молоке... дуем на воду"? Зачем надо каждый раз переопределять ВСЕ методы, если требуется добавить один новый или переопределить один существующий? К чему приведёт такая практика? Очевидно, к частому использованию "copy & paste", со всеми вытекающими...
Проблемы VCL, конечно, ощутимы, но связаны они, IMHO, с другими факторами. Первый фактор - желание максимально использовать готовые "элементы управления" (controls), которые есть в Windows. По сути, часть VCL просто "обёртка" над этими "элементами управления"... не слишком удачно связанная иерархией наследования. Второй фактор - отсутствие полноценной агрегации, примером чему являются меню, toolbuttons, grids и пр. Третий фактор - включение в VCL не визуальных (левых) элементов. И т.д. и т.п.
Другими словами, у VCL типичная проблема с архитектурой... желание быстрого результата с минимальными усилиями...
Посмотрел. Там наследование, например, применяется для реализации разных типов атрибутов.
[Речь о проекте СУБД]
Не только, и разных типов отношений (таблиц)... Можно наследовать и более высокоуровневые агрегаты, но об этом не говорилось...
Атрибут (Фиксированный размер (числа, временные), Произвольный размер (строки, blob)).
Конечно, наследование тут полезно, но не обязательно реализации.
Можем сделать для них дерево абстрактных классов без реализаций.
Зачем?.. Предположим, что мы реализовали класс "Текстовая Строка", от неё можно наследовать классы специфических строк, например URL, e-mail и пр. При этом вся логика работы со строками сохраняется... Зачем всё переписывать?
Затем уже делаем реализацию каждого "терминального" класса из дерева. Реализации полностью независимы друг от друга, ничего не знают друг про друга. Потом замечаем, что реализация, допустим, блоба, в чём-то начинает повторять код реализации строк. Мы сразу же выносим этот код в некоторую базовую библиотеку, состоящую из функций или наших служебных классов. Т.е. код, который бы хотелось наследовать (засунуть в класс "Произвольный размер", чтобы потом от притащился автоматом при наследовании и в строки, и в блобы) мы просто выносим отдельно в свои служебные модули. Возникнут какие-то внутрение служебные классы, в которых будет зафиксирована вот эта общность реализаций разных атрибутов.
Не получится... Дело в том, что "засунуть в библиотеку" можно простой алгоритм... а если этот алгоритм требует активной работы с полями класса/объекта? То как быть? Представлять все нужные поля классов в виде формальных параметров? А обращения к другим методам класса, заменять обращением к библиотечным подпрограммам?.. каждый раз передавая огромное количество параметров?.. И Вы считаете, что такая практика способна снизить количество ошибок?..
Илья Евгеньевич, попробуйте подумать в таком направлении... В своё время структурное программирование сыграло огромную позитивную роль в наведении порядка в коде программ. Достигался порядок, прежде всего, за счёт декомпозиции кода по подпрограммам и вынесения общих подпрограмм в библиотеки. Помимо порядка... повышалась надёжность. Но... Подпрограмма без данных... это очень частный случай. А данные были в программе и могли быть "случайно" изменены... Требовалось защитить часть данных, нужных подпрограмме для корректной работы. И вот... (дальнейшие рассуждения я опускаю, Вы с ними знакомы)... логически пришли к классам/объектам, где данные и код инкапсулированы. Теперь надо обеспечить расширяемость классов, так, чтобы повторно не переписывать уже отлаженный код. Появилось наследование... А Вы говорите: "Долой наследование! Давайте каждый раз будем переписывать код!". Зачем?.. Класс - это логичное продолжение декомпозиции, но не только кода, но и данных... наряду с механизмами развития (уточнения под конкретные условия применения). Но это и иная плоскость мышления... Написание библиотек (общего пользования) кардинально отличается от написания программ. Написание иерархии классов... тем более. Классы (иерархии классов) в программах избыточны, они нужны в системах. Для написания программ, как правило, достаточно подпрограмм (библиотек)... Это мы тоже обсуждали.
-
К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
Как по-Вашему, в каких языках наиболее правильно реализованы концепции ООП?
SmallTalk
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается. Использовать надо объект того класса, который нужен... Класс-потомок можно использовать вместо класса-предка, но поведение класса-потомка может кардинально отличаться от поведения класса-предка (поэтому "использовать всюду"... нонсенс).
http://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков (http://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков)
Пусть является свойством, верным относительно объектов некоторого типа . Тогда также должно быть верным для объектов типа , где является подтипом типа .
Роберт С. Мартин определил[3] этот принцип так:
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом.
...
Более простыми словами можно сказать, что поведение наследуемых классов не должно противоречить поведению, заданному базовым классом, то есть поведение наследуемых классов должно быть ожидаемым для кода, использующего переменную базового типа.
Если "поведение класса-потомка может кардинально отличаться от поведения класса-предка", то это являетя нарушением принципа подстановки Лисков.
А если так подумать, то может быть такому потомку нечего делать в этой иерархии классов?
Эти рассуждения порочны по своей сути. Класс-предок задаёт "обобщённое поведение", классы-наследники уточняют поведение. При этом уточнение может кардинально отличаться от того, что замышлялось при создании класса-предка. Предположим, что мы говорим о транспорте. Когда создавалась первая телега... вряд ли кто-то серьёзно думал о пассажирских самолётах. То есть, создавая абстракцию, "транспортное средство" трудно предположить, во что оно может вылиться... Правильнее думать о сути: "перемещение людей и грузов на расстояние", а не о "поведении", как таковом.
Другими словами, предположения о схожести "поведения" предка и потомка являются надуманными (если уж говорить, то у функциональном подобии предка и потомка, а не о их поведении).
-
К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.
Как по-Вашему, в каких языках наиболее правильно реализованы концепции ООП?
SmallTalk
Видимо, SmallTalk-80 и далее? (В SmallTalk-72, например, не было наследования...)
-
Класс-предок задаёт "обобщённое поведение", классы-наследники уточняют поведение. При этом уточнение может кардинально отличаться от того, что замышлялось при создании класса-предка. Предположим, что мы говорим о транспорте. Когда создавалась первая телега... вряд ли кто-то серьёзно думал о пассажирских самолётах. То есть, создавая абстракцию, "транспортное средство" трудно предположить, во что оно может вылиться... Правильнее думать о сути: "перемещение людей и грузов на расстояние", а не о "поведении", как таковом.
Другими словами, предположения о схожести "поведения" предка и потомка являются надуманными (если уж говорить, то у функциональном подобии предка и потомка, а не о их поведении).
Тогда, может быть, следует делать так:
Использовать наследование структуры и приватных методов для уточнения поведения объектов, но при этом использовать реализацию интерфейсов для полиморфного использования объектов?
Тогда, по идее, и принцип подстановки не будет нарушен, если функция, использующая этот объект, сможет дёргать только методы интерфейса.
-
Если принцип подстановки не использовать НИКОГДА, то можно обйтись и без наследования.
Но вопрос требует более тщательного изучения: так ли уж нужен этот самый принцип подстановки ? В конце-концов, обходились же раньше без него... :)
В смысле, Вы хотите отказаться от полиморфизма? Это полностью убивает суть ООП, как основы для расширяемых систем.
Речь-то идёт не про "без наследования", а про "не делайте неабстрактные классы доступными для наследования, не позволяйте от них наследоваться никому. А в абстрактных классах не делайте реализацию никаких функций, или только совершенного минимума функций. Не используйте нигде в программе имена неабстрактных классов, в том числе в new, используйте фабрики, фабрики, ещё раз фабрики".
-
Не получится... Дело в том, что "засунуть в библиотеку" можно простой алгоритм... а если этот алгоритм требует активной работы с полями класса/объекта? То как быть? Представлять все нужные поля классов в виде формальных параметров? А обращения к другим методам класса, заменять обращением к библиотечным подпрограммам?.. каждый раз передавая огромное количество параметров?.. И Вы считаете, что такая практика способна снизить количество ошибок?..
А это будет объектно-ориентированная библиотека.
Например, если у строки и блоба есть что-то общее в хранении данных, то возникнет некий класс технического назначения BinaryStorage, допустим, и мы будем его использовать и внутри реализации строки, и внутри реализации блоба.
И вот... (дальнейшие рассуждения я опускаю, Вы с ними знакомы)... логически пришли к классам/объектам, где данные и код инкапсулированы. Теперь надо обеспечить расширяемость классов, так, чтобы повторно не переписывать уже отлаженный код. Появилось наследование... А Вы говорите: "Долой наследование! Давайте каждый раз будем переписывать код!".
Здесь Вы пропустили логический этап: сначала расширяемость классов нужна, чтобы выражать отношения "род-вид" (и обеспечивать полиморфизм, расширяемость системы, когда я могу всюду, где нужна "рыба", дать и хоть "селёдку", хоть "камбалу"). То, что в Симуле при этом сразу же решили через это проблему и повторного использования кода из базовых классов, не означает автоматически, что это лучшее решение. Позже появился подход (не уверен, кто его начал первым пропагандировать - возможно всё же Гамма и Ко. в книге "Паттерны ООП"), рекомендующий устанавливать отношения наследования между абстрактными классами, а классы, реализующие эти абстракции, делать "финальными" и недоступными "по имени".
Вопрос "зачем"? Я придерживаюсь этого подхода потому, что он вынуждает разбивать систему на более мелкие части и значительно понижает зависимость между частями. Финальные классы, которые содержат реализацию, ничего не знают друг о друге (я могу жонглировать разными реализациями хоть прямо во время выполнения, просто "воткнув" другую фабрику, а попробуйте Вы подмените на ходу реализацию String или Blob. Даже попробуйте просто поддерживать 2-3 реализации String. У Вас возникнет 2-3 версии ОДНОГО КЛАССА, а значит - ОДНОГО ФАЙЛА. Бррр. А у меня эти 2-3 реализации будут в разных финальных классах и жить будут параллельной жизнью).
Если применять наследование реализации в случае с атрибутами, то, например, та самая техническая абстракция BinaryStorage, являющаяся "общим знаменателем" и для String, и для Blob, просто не возникнет. Её код будет "вмазан" в абстракцию "Атрибут переменной длины" (вмазан в абстрактное понятие!!!).
А так этот BinaryStorage становится полезным техническим средством и, заметьте, совершенно независимым от других абстракций Вашей СУБД. Вы его можете отделить от своей СУБД и "подарить" кому-нибудь, кто делает другую СУБД :)
И, кстати, ещё спорный вопрос, понадобятся ли классы "Атрибут переменной длины" и "Атрибут постоянной". Они понадобятся, только если будут выражать какую-то общность в интерфейсах этих атрибутов. А сейчас, возможно, они присутствуют только потому, что выражают общность реализации.
Вот тоже важная концептуальная проблема - в случае наследования реализации по какому признаку-то строим обобщающую иерархию - по признаку общности интерфейса или по признаку общности реализации - "можно удобно впендючить в этот пром. класс полезную функцию для всех его потомков"? Мешаются в кучу кони и люди.
-
Вот пример того, как могут возникать противоречия при использовании наследования реализации.
Ниже пример - условен, поэтому просьба не "въедаться" в духе "а зачем в СУБД такое" и проч.
Пусть в нашей СУБД вдруг появляется тип "целое неограниченной длины". Куда мы его засунем? По своему интерфейсу это - целое число. Операции к нему применяются такие же, как к числу. Но по реализации это - атрибут переменной длины.
Куда же мы его отнесём?
И таких случаев много, когда, казалось бы, "гармоничное" дерево наследования рушится при введении какого-то класса, который попадает и туда, и туда. Это может происходить даже и при наследовании абстрактных классов (по признаку общности интерфейса). Но если в дерево наследования подмешан признак общности реализации, то это будет обязательно.
Мы засунули в дерево наследования развилку "атрибут постоянной длины" - "атрибут переменной длины" в первую очередь не по принципу того, что такие атрибуты похожи "снаружи", а потому, что нам удобно обобщить их по реализации, будет класс, в который "засунуть" общий код.
И получили почву для будущих противоречий.
Лучше спроектировать дерево абстракций без примешивания вопросов повторного использования кода. А для повторного использования кода потом ввести внутреннюю систему классов.
-
Если принцип подстановки не использовать НИКОГДА, то можно обйтись и без наследования.
Но вопрос требует более тщательного изучения: так ли уж нужен этот самый принцип подстановки ? В конце-концов, обходились же раньше без него... :)
В смысле, Вы хотите отказаться от полиморфизма? Это полностью убивает суть ООП, как основы для расширяемых систем.
Речь-то идёт не про "без наследования", а про "не делайте неабстрактные классы доступными для наследования, не позволяйте от них наследоваться никому. А в абстрактных классах не делайте реализацию никаких функций, или только совершенного минимума функций. Не используйте нигде в программе имена неабстрактных классов, в том числе в new, используйте фабрики, фабрики, ещё раз фабрики".
Нет. От полиморфизма отказываться как-то не хочется.
Но вот непосредственно из ваших слов следует, что возможно непосредственно в языке или в IDE должны быть запретительные средства. Как в КП наследование по умолчанию запрещено.
Возможно, настал момент для более тонких запретительных средств. Например, наследование от неабстрактного класса - запрещено. :) Имеется ввиду - в корне иерархии.
-
Особенно доставляет "веселье" наследование от неабстрактного класса для объектов которого написан свой менеджер памяти (в "деструкторе" указатели на объекты пихаются в кэш для последующего повторного использования).
-
Особенно доставляет "веселье" наследование от неабстрактного класса для объектов которого написан свой менеджер памяти (в "деструкторе" указатели на объекты пихаются в кэш для последующего повторного использования).
Это шарповое что-то?
В той же Аде много культурней все это делается.
-
Класс-предок задаёт "обобщённое поведение", классы-наследники уточняют поведение. При этом уточнение может кардинально отличаться от того, что замышлялось при создании класса-предка. Предположим, что мы говорим о транспорте. Когда создавалась первая телега... вряд ли кто-то серьёзно думал о пассажирских самолётах. То есть, создавая абстракцию, "транспортное средство" трудно предположить, во что оно может вылиться... Правильнее думать о сути: "перемещение людей и грузов на расстояние", а не о "поведении", как таковом.
Другими словами, предположения о схожести "поведения" предка и потомка являются надуманными (если уж говорить, то у функциональном подобии предка и потомка, а не о их поведении).
Тогда, может быть, следует делать так:
Использовать наследование структуры и приватных методов для уточнения поведения объектов, но при этом использовать реализацию интерфейсов для полиморфного использования объектов?
Тогда, по идее, и принцип подстановки не будет нарушен, если функция, использующая этот объект, сможет дёргать только методы интерфейса.
Собственно, так и делается... Открытые (public) методы и представляют собой интерфейс класса. Другое дело, что полиморфными могут быть методы у нескольких классов, при этом эти классы могут не иметь предка с данными методами. Простой пример. Летать могут птицы и самолёты, но не факт, что они вообще имеют (в рамках некоторой системы) общего предка.... и даже если такой предок есть, не факт, что он тоже умеет летать. Поэтому свойство летать - полиморфно и может быть реализовано у совершенно разных (по смыслу) классов.
Такой полиморфизм (вне наследования) "ломает" структуру привычных виртуальных таблиц, но он вполне допустим, если работа с объектами строится на сообщениях.
-
Особенно доставляет "веселье" наследование от неабстрактного класса для объектов которого написан свой менеджер памяти (в "деструкторе" указатели на объекты пихаются в кэш для последующего повторного использования).
Это шарповое что-то?
В той же Аде много культурней все это делается.
Это моё. Когда надо создать новый объект, то сначала смотрю в кэше. Если кэш не пустой, то выдаю указатель на готовый объект. Если кэш пустой, то создаю объект по-настоящему. Когда объект "удаляется", то помещаю указатель в кэш для повторного использования. Пишу на C#, но C# тут не при чём.
А в Аде чего?
-
Особенно доставляет "веселье" наследование от неабстрактного класса для объектов которого написан свой менеджер памяти (в "деструкторе" указатели на объекты пихаются в кэш для последующего повторного использования).
Это шарповое что-то?
В той же Аде много культурней все это делается.
Это моё. Когда надо создать новый объект, то сначала смотрю в кэше. Если кэш не пустой, то выдаю указатель на готовый объект. Если кэш пустой, то создаю объект по-настоящему. Когда объект "удаляется", то помещаю указатель в кэш для повторного использования. Пишу на C#, но C# тут не при чём.
А в Аде чего?
В Аде, сколь я помню, есть полноценные Storage_Pool'ы. В том числе там есть ограничения, что ссылки у тех кто сидит внутри такого пула могут быть только на тех кто в том же пуле. Это проверка статическая, компилятором.
По сути, это такие отдельные кучи/кучки внутри программы.
-
Не получится... Дело в том, что "засунуть в библиотеку" можно простой алгоритм... а если этот алгоритм требует активной работы с полями класса/объекта? То как быть? Представлять все нужные поля классов в виде формальных параметров? А обращения к другим методам класса, заменять обращением к библиотечным подпрограммам?.. каждый раз передавая огромное количество параметров?.. И Вы считаете, что такая практика способна снизить количество ошибок?..
А это будет объектно-ориентированная библиотека.
Например, если у строки и блоба есть что-то общее в хранении данных, то возникнет некий класс технического назначения BinaryStorage, допустим, и мы будем его использовать и внутри реализации строки, и внутри реализации блоба.
Да, всё бы ничего... Но объект типа pool имел порядка 15 полей (если мне память не изменяет), и Вы предлагаете передавать эти данные в виде формально/фактических параметров в каждую подпрограмму Вашей библиотеки?.. А как же... инкапсуляция?..
И вот... (дальнейшие рассуждения я опускаю, Вы с ними знакомы)... логически пришли к классам/объектам, где данные и код инкапсулированы. Теперь надо обеспечить расширяемость классов, так, чтобы повторно не переписывать уже отлаженный код. Появилось наследование... А Вы говорите: "Долой наследование! Давайте каждый раз будем переписывать код!".
Здесь Вы пропустили логический этап: сначала расширяемость классов нужна, чтобы выражать отношения "род-вид" (и обеспечивать полиморфизм, расширяемость системы, когда я могу всюду, где нужна "рыба", дать и хоть "селёдку", хоть "камбалу"). То, что в Симуле при этом сразу же решили через это проблему и повторного использования кода из базовых классов, не означает автоматически, что это лучшее решение. Позже появился подход (не уверен, кто его начал первым пропагандировать - возможно всё же Гамма и Ко. в книге "Паттерны ООП"), рекомендующий устанавливать отношения наследования между абстрактными классами, а классы, реализующие эти абстракции, делать "финальными" и недоступными "по имени".
Да не пропускал я никаких отношений "род-вид" - надуманно это... IMHO. Речь шла о логическом развитии идей структурного программирования в ООП.
Вопрос "зачем"? Я придерживаюсь этого подхода потому, что он вынуждает разбивать систему на более мелкие части и значительно понижает зависимость между частями.
Ничего подобного...
Финальные классы, которые содержат реализацию, ничего не знают друг о друге (я могу жонглировать разными реализациями хоть прямо во время выполнения, просто "воткнув" другую фабрику, а попробуйте Вы подмените на ходу реализацию String или Blob. Даже попробуйте просто поддерживать 2-3 реализации String. У Вас возникнет 2-3 версии ОДНОГО КЛАССА, а значит - ОДНОГО ФАЙЛА. Бррр. А у меня эти 2-3 реализации будут в разных финальных классах и жить будут параллельной жизнью).
Подмена одних классов другими происходит очень просто. Я уже говорил о полиморфизме на уровне классов/объектов.
Если применять наследование реализации в случае с атрибутами, то, например, та самая техническая абстракция BinaryStorage, являющаяся "общим знаменателем" и для String, и для Blob, просто не возникнет. Её код будет "вмазан" в абстракцию "Атрибут переменной длины" (вмазан в абстрактное понятие!!!).
Зачем?.. А если появится ещё один класс атрибута переменного размера... снова будете ручками "вмазывать"? Для чего эти проблемы? Какую задачу Вы решаете... таким образом?
А так этот BinaryStorage становится полезным техническим средством и, заметьте, совершенно независимым от других абстракций Вашей СУБД. Вы его можете отделить от своей СУБД и "подарить" кому-нибудь, кто делает другую СУБД :)
Эта абстракция имеет смысл в рамках данной иерархии, вне иерархии она не имеет смысла...
И, кстати, ещё спорный вопрос, понадобятся ли классы "Атрибут переменной длины" и "Атрибут постоянной". Они понадобятся, только если будут выражать какую-то общность в интерфейсах этих атрибутов. А сейчас, возможно, они присутствуют только потому, что выражают общность реализации.
Они нужны поскольку имеют смысл в предметной области, а не потому, что они мне понравились...
Вот тоже важная концептуальная проблема - в случае наследования реализации по какому признаку-то строим обобщающую иерархию - по признаку общности интерфейса или по признаку общности реализации - "можно удобно впендючить в этот пром. класс полезную функцию для всех его потомков"? Мешаются в кучу кони и люди.
Иерархия строится на основе... смысла... (или замысла).
-
В Аде, сколь я помню, есть полноценные Storage_Pool'ы. В том числе там есть ограничения, что ссылки у тех кто сидит внутри такого пула могут быть только на тех кто в том же пуле. Это проверка статическая, компилятором.
По сути, это такие отдельные кучи/кучки внутри программы.
Про ссылки только внутри пула не понял. Вот есть класс Телефонов, и есть класс Звонков. У каждого свой кэш для повторного использования объектов. Каждый кэш создаёт и удаляет объекты за O(1). Во время работы Звонки имеют указатели на Телефоны, а Телефоны имеют указатели на Звонки. На Аде это нельзя будет написать через какие-то там полноценные Storage_Pool'ы?
-
В Аде, сколь я помню, есть полноценные Storage_Pool'ы. В том числе там есть ограничения, что ссылки у тех кто сидит внутри такого пула могут быть только на тех кто в том же пуле. Это проверка статическая, компилятором.
По сути, это такие отдельные кучи/кучки внутри программы.
Про ссылки только внутри пула не понял. Вот есть класс Телефонов, и есть класс Звонков. У каждого свой кэш для повторного использования объектов. Каждый кэш создаёт и удаляет объекты за O(1). Во время работы Звонки имеют указатели на Телефоны, а Телефоны имеют указатели на Звонки. На Аде это нельзя будет написать через какие-то там полноценные Storage_Pool'ы?
Не могу четко ответить на вопрос. Нужно поковыряться.
-
Кстати, ссылка на Б. Лискова либо некорректна, либо... автор заблуждается.
Лисков - это она.
И иностранные женские фамилии в русском языке не склоняются по падежам.
-
И иностранные женские фамилии в русском языке не склоняются по падежам.
Очень может быть, что на самом деле она все-таки Лискова :) Например, в штатах дочка в семье Лисковых будет фигурировать в свидетельстве о рождении как "Лисков". Просто потому, что англоязычным бюрократам трудно объяснить, что фамилия может склоняться и надо записать "Лискова".
-
И иностранные женские фамилии в русском языке не склоняются по падежам.
Очень может быть, что на самом деле она все-таки Лискова :) Например, в штатах дочка в семье Лисковых будет фигурировать в свидетельстве о рождении как "Лисков". Просто потому, что англоязычным бюрократам трудно объяснить, что фамилия может склоняться и надо записать "Лискова".
Девичья фамилия у неё вообще Губерман, предки по отцу -- выходцы из России.
Лисков по мужу, так что видимо не стоит склонять (как, например, Ада Лавлейс или там Джейн Остин)...
-
Пусть в нашей СУБД вдруг появляется тип "целое неограниченной длины". Куда мы его засунем? По своему интерфейсу это - целое число. Операции к нему применяются такие же, как к числу. Но по реализации это - атрибут переменной длины.
Куда же мы его отнесём?
И таких случаев много, когда, казалось бы, "гармоничное" дерево наследования рушится при введении какого-то класса, который попадает и туда, и туда. Это может происходить даже и при наследовании абстрактных классов (по признаку общности интерфейса). Но если в дерево наследования подмешан признак общности реализации, то это будет обязательно.
Мы засунули в дерево наследования развилку "атрибут постоянной длины" - "атрибут переменной длины" в первую очередь не по принципу того, что такие атрибуты похожи "снаружи", а потому, что нам удобно обобщить их по реализации, будет класс, в который "засунуть" общий код.
И получили почву для будущих противоречий.
Лучше спроектировать дерево абстракций без примешивания вопросов повторного использования кода. А для повторного использования кода потом ввести внутреннюю систему классов.
Когда смысл утрачивается... почему-то всё становится сложным и непонятным :)
Давайте по порядку... Для чего нужна СУБД? (Речь идёт именно о СУБД, не так ли?). Смею предположить, что СУБД необходима для (в порядке убывания значимости): надёжного хранения информации (даже в случае отказа техники, данные должны быть сохранены); для быстрого поиска и извлечения информации; для выполнения простейших преобразований данных.
Исходя из декларированных целей, необходимо разработать механизмы СУБД (снова в порядке убывания важности): хранения, поиска, извлечения и преобразования. И предложенная в проекте СУБД иерархия типов данных, подчинена решению именно этих задач. Деление иерархии на две ветки: данные фиксированного размера и данные произвольного размера подчёркивают приоритет задач хранения, поиска и извлечения информации, над задачами преобразования информации. Поэтому никакой двусмысленности Ваш пример не вносит, сначала обеспечиваем решение более приоритетных задач, потом менее приоритетных.
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Теперь о решениях... Целочисленные данные произвольного размера будут отнесены к данным произвольного размера, чтобы была возможность наследования механизмов хранения, поиска и извлечения информации. На полученный, таким образом, класс будут наложены все необходимые арифметические и прочие операции. Точно также, как если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
В любом случае, и Ваше и моё решение приведут к получению разреженной двумерной матрицы, по одной стороне которой будут отложены все типы данных, а по другой - все типы операций. И Ваше решение, в плане заполнения и развития этой матрицы, не имеет никаких преимуществ перед моим. (Обратное неверно!).
-
И иностранные женские фамилии в русском языке не склоняются по падежам.
Так это же русская фамилия. Вообще говоря, иностранность слова определяется не гражданством.
-
И иностранные женские фамилии в русском языке не склоняются по падежам.
Так это же русская фамилия. Вообще говоря, иностранность слова определяется не гражданством.
Варвара Лискова (а то и Лисицына) :-)
-
И иностранные женские фамилии в русском языке не склоняются по падежам.
Так это же русская фамилия. Вообще говоря, иностранность слова определяется не гражданством.
Лисков -- русская фамилия? о_О Да такого слова -- "лиск(а)" -- в русском языке даже нету.
http://dic.academic.ru/dic.nsf/brokgauz_efron/61637/Лисков
Лисков
(Христиан-Людвиг Liscow) — нем. сатирик (1701-1760).
-
... если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?
-
... если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?
Вот тоже хотел об этом спросить.
Правда, варианты у меня другие были -- реализация интерфейсов, реализующие арифметические операции и операции работы со строками,
или же множественное наследование.
-
... если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?
Наложены - реализованы в классах.
Наверное, надо отметить, что СУБД создавалась на ассемблере (TASM), было это в начале 90-х... Объектность и многое другое реализовывались через макросы. Позже появился TASM 3.0 с поддержкой ООП, но он был очень глючный. Более или менее работоспособный TASM 3.1 появился ещё позже, когда проектом уже не занимались.
-
Да, всё бы ничего... Но объект типа pool имел порядка 15 полей (если мне память не изменяет), и Вы предлагаете передавать эти данные в виде формально/фактических параметров в каждую подпрограмму Вашей библиотеки?.. А как же... инкапсуляция?..
Так большая часть этих полей и пойдёт внутрь "технического объекта", видимо.
Они нужны поскольку имеют смысл в предметной области, а не потому, что они мне понравились...
....
Иерархия строится на основе... смысла... (или замысла).
А почему класс "числовые" является подклассом "постоянной длины"? Насколько это основано "на смысле"?
Разве для пользователя СУБД важно, что он "постоянной длины"?
Это разные классификационные признаки - способ реализации и какие-то ещё категории атрибутов (числовые и др.) А они оказываются в одном дереве.
А Вася будет разрабатывать СУБД на базе какого-нибудь движка хранения - и для него окажется существенным деление не на переменной длины и постоянной длины, а на "реализованы в движке" - "будут реализовываться мной". И он это тоже впендючит в Самое Главное Дерево Классов своей программы.
Таким образом, способ реализации начинает влиять на дерево главных абстракций, что не есть хорошо.
Я бы, возможно, сделал разные классы атрибутов (разумеется, абстрактные классы) просто расширением базового класса "атрибут". Ну, с промежуточным уровнем для целых, вещественных и т.п. Но не глубже. Вообще, глубокие иерархии (больше трёх уровней) пахнут обычно произволом, необоснованностью разбиения.
-
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Вот это мне и не нравится в Вашем примере (и вообще в других случаях с наследованием реализации). То, что следовало бы отделить друг от друга (абстракции и их реализацию), оказывается замешано в одном общем дереве.
Я предпочитаю иметь отдельно дерево абстрактных классов - и отдельно его реализации. И технические абстракции уровня реализации.
Кстати, я так и не понял, как именно Вы будете поступать, если у Вас для методов, реализованных в классе "Атрибут переменной длины", появится несколько вариантов реализации. Как Вы будете оформлять и управлять этими вариантами.
-
... если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?
Наложены - реализованы в классах.
Я, наверно, неточно спросил... В каких конкретно классах?
Вот, у нас есть класс "целое число". Дальше мы переопределяем его, добавляя ко множеству существующих методов новую операцию? Или создаём новый класс, назначение которого - выполнять данную операцию над числами?
-
Да, всё бы ничего... Но объект типа pool имел порядка 15 полей (если мне память не изменяет), и Вы предлагаете передавать эти данные в виде формально/фактических параметров в каждую подпрограмму Вашей библиотеки?.. А как же... инкапсуляция?..
Так большая часть этих полей и пойдёт внутрь "технического объекта", видимо.
Что такое "технический объект"? Чем он отличается от обычного объекта?
Они нужны поскольку имеют смысл в предметной области, а не потому, что они мне понравились...
....
Иерархия строится на основе... смысла... (или замысла).
А почему класс "числовые" является подклассом "постоянной длины"? Насколько это основано "на смысле"?
Разве для пользователя СУБД важно, что он "постоянной длины"?
Пользователь СУБД, равно, как и её разработчики, должны знать... стандарты... SQL 89/92 (для того времени)...
Это разные классификационные признаки - способ реализации и какие-то ещё категории атрибутов (числовые и др.) А они оказываются в одном дереве.
Илья Евгеньевич, мы с Вами хорошо понимаем, что если человек не желает видеть, то очки ему не помеха...
Выше я написал Вам, какие признаки/свойства/атрибуты для разработчика СУБД являются наиболее приоритетными, объяснил - почему это так. Вы этого по-прежнему видеть не хотите... Что же с этим можно поделать?..
А Вася будет разрабатывать СУБД на базе какого-нибудь движка хранения - и для него окажется существенным деление не на переменной длины и постоянной длины, а на "реализованы в движке" - "будут реализовываться мной". И он это тоже впендючит в Самое Главное Дерево Классов своей программы.
Таким образом, способ реализации начинает влиять на дерево главных абстракций, что не есть хорошо.
Я не знаю, кто такой Вася, что он хочет делать, и почему он это хочет делать. Я написал Вам в чём состоит смысл СУБД... безотносительно меня, Вас или Васи...
Я бы, возможно, сделал разные классы атрибутов (разумеется, абстрактные классы) просто расширением базового класса "атрибут". Ну, с промежуточным уровнем для целых, вещественных и т.п. Но не глубже. Вообще, глубокие иерархии (больше трёх уровней) пахнут обычно произволом, необоснованностью разбиения.
Ваша "обоснование" просто убивает своей логической стройностью и обоснованностью... :)
-
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Вот это мне и не нравится в Вашем примере (и вообще в других случаях с наследованием реализации). То, что следовало бы отделить друг от друга (абстракции и их реализацию), оказывается замешано в одном общем дереве.
Ну, не нравится... так не нравится. О вкусовых предпочтениях спорить бесполезно. Пока я так и не увидел, чем Ваше решение лучше.
Я предпочитаю иметь отдельно дерево абстрактных классов - и отдельно его реализации. И технические абстракции уровня реализации.
... и руками поддерживать соответствия этих двух разных частей...
Кстати, я так и не понял, как именно Вы будете поступать, если у Вас для методов, реализованных в классе "Атрибут переменной длины", появится несколько вариантов реализации. Как Вы будете оформлять и управлять этими вариантами.
Что значит "несколько вариантов реализации методов"?..
-
... если бы для фиксированных целых чисел понадобилось бы выполнение операций присущих строкам (конкатенация, поиск (битовой) подстроки и т.п.), то эти операции были бы просто наложены на существующие классы целых чисел.
Каким образом эти операции были бы наложены? С помощью наследования (получение нового класса целых чисел с дополнительными методами)?
Наложены - реализованы в классах.
Я, наверно, неточно спросил... В каких конкретно классах?
Вот, у нас есть класс "целое число". Дальше мы переопределяем его, добавляя ко множеству существующих методов новую операцию? Или создаём новый класс, назначение которого - выполнять данную операцию над числами?
Это зависит от задачи. Если мы создаём новый класс "новое целое число", то для него (пере)определяем все операции, полученные от его класса-предка, и добавляем новые операции, если необходимо. Если же мы хотим просто добавить новую операцию к существующим классам, то добавляем её к тому классу, где она должна быть/относительно которого она определена. Классы-наследники получают данную операцию от своего предка и при необходимости переопределяют.
-
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Вот это мне и не нравится в Вашем примере (и вообще в других случаях с наследованием реализации). То, что следовало бы отделить друг от друга (абстракции и их реализацию), оказывается замешано в одном общем дереве.
О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.
-
О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.
Да на практике нет никакой "одной кучи".
При объектно-ориентированной разработке у тебя будут модули, играющие роль спецификаций (как .h-файл), в которых только ABSTRACT-типы плюс минимум какой-то "обслуги" (константы, процедуры "синт. сахара", применимые к объектам данного модуля).
И будут модули, которые вообще практически не имеют экспортированной части, но содержат реализацию ABSTRACT-типов из первых модулей.
-
Что значит "несколько вариантов реализации методов"?..
У Вас есть вот этот класс "Атрибут переменной длины".
У него - какой-то метод Method1.
И Вы сначала (как у Вас и предлагается) реализуете его самым простым способом.
А потом возникнет более оптимальная его реализация.
А, может быть, несколько реализаций (с различными свойствами).
Как Вы организуете эту вариативность, где и как будете хранить разные варианты?
У меня-то всё просто - у меня никогда не бывает двух реализаций одноимённой сущности. У меня это будут два разных конкретных потомка абстрактного класса.
-
Это зависит от задачи. Если мы создаём новый класс "новое целое число", то для него (пере)определяем все операции, полученные от его класса-предка, и добавляем новые операции, если необходимо. Если же мы хотим просто добавить новую операцию к существующим классам, то добавляем её к тому классу, где она должна быть/относительно которого она определена. Классы-наследники получают данную операцию от своего предка и при необходимости переопределяют.
Вот что ещё не нравится: при развитии системы и появлении новых атрибутов может понадобиться трогать код базового класса, да ещё и по-крупному: например, вводить новые методы.
С моей точки зрения, это очень неприятное вмешательство, которого следует избегать. В частности, при компонентном подходе может так сложиться, что базовые классы разрабатывает разработчик А, а расширения - разработчик Б, при этом они ничего не знают друг про друга. Невмешательство в базовые классы при появлении классов-расширений - очень важный принцип в компонентно устроенном ПО.
Конечно, на практике пройдёт несколько итераций, пока базовые классы полностью стабилизируются - но потом они должы жить "долго и счастливо", без всяких изменений.
-
О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.
Да на практике нет никакой "одной кучи".
При объектно-ориентированной разработке у тебя будут модули, играющие роль спецификаций (как .h-файл), в которых только ABSTRACT-типы плюс минимум какой-то "обслуги" (константы, процедуры "синт. сахара", применимые к объектам данного модуля).
И будут модули, которые вообще практически не имеют экспортированной части, но содержат реализацию ABSTRACT-типов из первых модулей.
Моя лично практика показывает другое. На практике мы имеем исходники ББ, компилятора Вирта и всяких там Astrobe-модулей. И там все густо замешано в кучу.
Нет, наверно если писать код в одиночку, то в конце концов с самим собой можно прийти к соглашению и научиться оформлять код так, чтобы было удобно и чтабельно (тебе). Но программирование это все же работа коллективная. В том числе это работа авторов не знакомых друг с другом лично (и иногда даже по переписке не знакомых).
Кроме того, я не вижу смысла ограничивать себя ООП-стилем. ООП+паттерны (в том числе фабрики, работа с метаинфой, загрузка-выгрузка динамическая) = жуть кромешная. Я этого накушался в свое время. Больше не хочу.
-
То есть, "обжегшить на молоке... дуем на воду"?
Возможно :) У меня очень богатый опыт работы с кодом в стиле "ООП ради ООП".
Зачем надо каждый раз переопределять ВСЕ методы, если требуется добавить один новый или переопределить один существующий?
Нельзя переопределить один существующий. Я тут согласен с Ильей - переопределяешь все и берешь на себя ответственность за каждый (хотя я бы хотел иметь в языке сахар для редиректа). Накушался я такого подхода. Есть базовый класс, который вызывает в какой-то последовательности перегруженные методы. И есть наследники, которые "подстраиваются" так, чтоб это все в итоге работало. Со временем это все обрастает соплями, потому что, естественно, на момент написания базового класса всех возможных особенностей наследников не было предусмотрено. И поменять в базовом уже ничего нельзя, потому что есть какое-то количество наследников (и наследников наследников), которые завязаны вот точно на такое "нелогичное" (со свежей точки зрения) дергание методов из базового класса. Чего-то рефакторить уже бесполезно, нужно по крупицам (прыгая по всей цепочке наследования реализации) собирать воедино всю логику (попутно избавляясь от хэков, которые заставляли все это работать) и писать просто заново. Без наследования и без надуманных иерархий. В итоге, когда все распутано, кода оказывается в разы меньше, а главное сразу видно что откуда, куда и как работает.
Конечно можно сказать, что с самого начала базовый класс делал херню и можно было сделать по-нормальному. Но я предпочитаю другой подход. Просто не плодить иерархий, пока без них ну вот никак. И что интересно, таких случаев (когда никак) исчезающе мало.
Конкретный пример. Если вам хочется перегрузить виртуальный метод (один), чтобы изменить один аспект поведения в наследнике - ну вынесите этот аспект в отдельный колбэк. А если у вас несколько аспектов - то получится небольшой и понятный интерфейс. От такого подхода (без наследования только ради возможности менять поведение базового класса) вы получите пользу прямо здесь и сейчас - вы сможете тестировать (юнит) ваш аспект даже если базовый класс тестированию не поддается (потому что это гуйня или какая-нибудь база данных). Это помимо отсутствия будущей головной боли, если вы простой человек и таки не смогли задизайнить правильно базовый класс с самого начала :)
Предположим, что мы реализовали класс "Текстовая Строка", от неё можно наследовать классы специфических строк, например URL, e-mail и пр. При этом вся логика работы со строками сохраняется... Зачем всё переписывать?
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
-
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Вот это мне и не нравится в Вашем примере (и вообще в других случаях с наследованием реализации). То, что следовало бы отделить друг от друга (абстракции и их реализацию), оказывается замешано в одном общем дереве.
О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.
Хаскелл в этом плане не лучше оберонов -- в нём нет выделенной спецификации модуля, в отличие от Ады, Модулы/2 или SML/Ocaml.
Единственное что там есть -- это возможность перечислить в шапке модуля экспортируемые им сущности. Но это всё же нельзя считать полноценной спецификацией...
-
Я предпочитаю иметь отдельно дерево абстрактных классов - и отдельно его реализации. И технические абстракции уровня реализации.
Так ведь это не от тебя зависит, а от задачи.
Пример наследования реализации: иерархия объектов сообщений с сериализаторами и десериализаторами. В сериализаторе (десериализаторе) потомка надо сделать супервызов сериализатора (десериализатора) предка. И, кстати, именно так в Блэкбоксе реализован Stores.Store. К этой же иерархии легко присобачивается виртуальный "деструктор" и виртуальная процедура для обхода достижимых объектов - и там и там нужны супервызовы.
-
Если бы стояла задача обеспечить максимально быстрое, гибкое, эффективное... преобразование данных, то иерархия была бы иной. Объектная иерархия классов - это инструмент, которым надо пользоваться по назначению, исходя из задач и условий.
Вот это мне и не нравится в Вашем примере (и вообще в других случаях с наследованием реализации). То, что следовало бы отделить друг от друга (абстракции и их реализацию), оказывается замешано в одном общем дереве.
О! А именно это ведь мне и не нравится в Обероновских модулях - и реализация и спецификация - все в одной куче. Фи. Вот то ли дело Haskell например, ну или там Ада/Модула-3.
Хаскелл в этом плане не лучше оберонов -- в нём нет выделенной спецификации модуля, в отличие от Ады, Модулы/2 или SML/Ocaml.
Единственное что там есть -- это возможность перечислить в шапке модуля экспортируемые им сущности. Но это всё же нельзя считать полноценной спецификацией...
У хаскелля намного лучше чем в Оберонов - у него есть выделенная спецификация модуля - она отдельной секцией идет в начале исходника (и без нее не обойтись). Спецификация, таким образом, пишется ручками и отделена от реализации. А в отдельном она файле, или в отдельной секции, или на отдельном сервере лежит - дело десятое на самом деле. Важно что она пишется ручками и она всегда согласована с реализацией.
-
У хаскелля намного лучше чем в Оберонов - у него есть выделенная спецификация модуля - она отдельной секцией идет в начале исходника (и без нее не обойтись). Спецификация, таким образом, пишется ручками и отделена от реализации. А в отдельном она файле, или в отдельной секции, или на отдельном сервере лежит - дело десятое на самом деле. Важно что она пишется ручками и она всегда согласована с реализацией.
Если бы в этой секции можно было бы хотя бы типы экспортируемых сущностей указывать, то да, а так толку мало от такой согласованности...
-
Если кэш пустой, то создаю объект по-настоящему. Когда объект "удаляется", то помещаю указатель в кэш для повторного использования.
А что, в данном случае, означает "удаляется"? Кем и когда "удаляется"?
-
У хаскелля намного лучше чем в Оберонов - у него есть выделенная спецификация модуля - она отдельной секцией идет в начале исходника (и без нее не обойтись). Спецификация, таким образом, пишется ручками и отделена от реализации. А в отдельном она файле, или в отдельной секции, или на отдельном сервере лежит - дело десятое на самом деле. Важно что она пишется ручками и она всегда согласована с реализацией.
Если бы в этой секции можно было бы хотя бы типы экспортируемых сущностей указывать, то да, а так толку мало от такой согласованности...
Толк все равно есть - намного проще узнать что он вообще экспортирует. Да и назначение модуля по этой секции определяется проще.
Но конечно есть еще куда расти.
-
А что, в данном случае, означает "удаляется"? Кем и когда "удаляется"?
У меня телефонная станция. Человек трубку повесил, в программу пришло сообщение, что звонок завершён, объект Звонок больше не нужен, он "удаляется". "Удаляется" значит из всех-всех-всех мест программы (из всех словарей и списков) удаляются указатели на этот объект. Развесистая структура данных (телефонов, звонков и т.п.) организована так, что добавление и удаление объекта делается примерно за О(1), для этого используются двухсвязные списки (это точно О(1)) и огромные хэштаблицы в виде массива списков (это примерно О(1) если длина массива в пару раз больше чем количество объектов).
-
Ага, понятно, без GC.
-
Предположим, что мы реализовали класс "Текстовая Строка", от неё можно наследовать классы специфических строк, например URL, e-mail и пр. При этом вся логика работы со строками сохраняется... Зачем всё переписывать?
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Кстати, я тоже так считаю. По мне, так здесь больше подходит агрегация.
-
Что значит "несколько вариантов реализации методов"?..
У Вас есть вот этот класс "Атрибут переменной длины".
У него - какой-то метод Method1.
И Вы сначала (как у Вас и предлагается) реализуете его самым простым способом.
А потом возникнет более оптимальная его реализация.
А, может быть, несколько реализаций (с различными свойствами).
Как Вы организуете эту вариативность, где и как будете хранить разные варианты?
Метод? Это (принципиально) разные классы и подклассы, имеющие общего предка.
Какие проблемы с хранением?.. Конкретный метод хранения определяется средой разработки (если речь о проекте СУБД, то она создавалась под DOS со всеми вытекающими ограничениями на наименования, каталоги и пр.). Если говорить про сегодняшние реалии, то проекты надо хранить в базе данных. Просто и удобно.
У меня-то всё просто - у меня никогда не бывает двух реализаций одноимённой сущности. У меня это будут два разных конкретных потомка абстрактного класса.
И здесь разные потомки, только не от одного абстрактного класса, а от вполне реальных классов.
Хорошо, попробую подойти с другой стороны... Вы помните проект системы управления предприятием? Там в самом начале приводится иерархия классов предприятия. Начиная с абстрактного1 предприятия, потом финансовое, логистическое (торговотранспортное) и, наконец, промышленное. Это вполне себе... объектная иерархия, где каждый класс (включая абстрактное предприятие) имеет свою реализацию. Так абстрактное предприятие включает в себя бухгалтерию и отдел кадров (но может включать и другие подсистемы, если это будет востребовано внешней средой!). Финансовое предприятие включает в свой состав всё, что есть у абстрактного предприятия и добавляет к этому финансовую подсистему. Логистическое предприятие наследует всё, что есть у финансового предприятия и добавляет логистические подсистемы (сбыт, снабжение, склады). Наконец, промышленное предприятие состоит из логистического + подсистема производства. Чем это плохо? Зачем что-то мудрить с какими-то абстракциями?..
-----
1 Абстрактное предприятие в контексте данного проекта означает не выдуманное, не несуществующее, а любое предприятие.
-
Это зависит от задачи. Если мы создаём новый класс "новое целое число", то для него (пере)определяем все операции, полученные от его класса-предка, и добавляем новые операции, если необходимо. Если же мы хотим просто добавить новую операцию к существующим классам, то добавляем её к тому классу, где она должна быть/относительно которого она определена. Классы-наследники получают данную операцию от своего предка и при необходимости переопределяют.
Вот что ещё не нравится: при развитии системы и появлении новых атрибутов может понадобиться трогать код базового класса, да ещё и по-крупному: например, вводить новые методы.
С моей точки зрения, это очень неприятное вмешательство, которого следует избегать. В частности, при компонентном подходе может так сложиться, что базовые классы разрабатывает разработчик А, а расширения - разработчик Б, при этом они ничего не знают друг про друга. Невмешательство в базовые классы при появлении классов-расширений - очень важный принцип в компонентно устроенном ПО.
Конечно, на практике пройдёт несколько итераций, пока базовые классы полностью стабилизируются - но потом они должы жить "долго и счастливо", без всяких изменений.
Ерунда... какая-то... Илья Евгеньевич, мне кажется, что Вы путаете два совершенно разных понятия... интерфейсы и ООП... Я могу согласиться с тем, что интерфейсы не должны меняться... Но классы, в том числе и те, которые реализуют интерфейсы могут (а иногда, в случае больших систем, - должны) меняться.
Во избежание неясностей поясню о чём идёт речь. Предположим, что мы рассматриваем два уровня системы. Взаимодействие между этими уровнями происходит через интерфейсы. Незыблемость интерфейсов - залог работоспособности системы. Но вот мы начинает реализацию этих интерфейсов на нижнем (из рассматриваемых) уровней. На основе заданных интерфейсов проектируем иерархию классов, часть методов которых являются публичными, соответствующими заявленным интерфейсам. И вот эта иерархия классов может меняться, так как необходимо разработчикам, например, от простейших реализаций к изощрённым, обеспечивающим высокие показатели экономичности, скорости, надёжности и пр.
-
Зачем надо каждый раз переопределять ВСЕ методы, если требуется добавить один новый или переопределить один существующий?
Нельзя переопределить один существующий. Я тут согласен с Ильей - переопределяешь все и берешь на себя ответственность за каждый (хотя я бы хотел иметь в языке сахар для редиректа). Накушался я такого подхода. Есть базовый класс, который вызывает в какой-то последовательности перегруженные методы. И есть наследники, которые "подстраиваются" так, чтоб это все в итоге работало. Со временем это все обрастает соплями, потому что, естественно, на момент написания базового класса всех возможных особенностей наследников не было предусмотрено.
Ну, так мы далеко уйдём... Какой смысл обсуждать какие-то технологии, если всегда найдётся некто, кто скажет: "Я вам напишу такой код, что никакие ваши технологии вам не помогут его разобрать, сопровождать и развивать". Да, я согласен, что плохих решений для любой задачи может быть бесконечно много. Но является ли это поводом для отказа от поиска, создания и использования технологий, как таковых?..
Если Вы столкнулись с плохим решением, не имея возможности его изменить, то это не повод хвататься за "костыли", приступая к решению новой задачи. И я постоянно почёркиваю, что ООП - это, прежде всего, Проектирование, а только потом Программирование. И здесь я обсуждаю проекты, а не... косяки в коде.
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
-
Во избежание неясностей поясню о чём идёт речь. Предположим, что мы рассматриваем два уровня системы. Взаимодействие между этими уровнями происходит через интерфейсы. Незыблемость интерфейсов - залог работоспособности системы. Но вот мы начинает реализацию этих интерфейсов на нижнем (из рассматриваемых) уровней. На основе заданных интерфейсов проектируем иерархию классов, часть методов которых являются публичными, соответствующими заявленным интерфейсам.
Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?
-
Во избежание неясностей поясню о чём идёт речь. Предположим, что мы рассматриваем два уровня системы. Взаимодействие между этими уровнями происходит через интерфейсы. Незыблемость интерфейсов - залог работоспособности системы. Но вот мы начинает реализацию этих интерфейсов на нижнем (из рассматриваемых) уровней. На основе заданных интерфейсов проектируем иерархию классов, часть методов которых являются публичными, соответствующими заявленным интерфейсам.
Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД, о котором говорилось. Первоначально атрибуты были организованы примитивно просто - массивы однородных данных. Для уровня отношений (таблиц) совершенно безразлично, как устроены атрибуты отношения (таблицы), оно обращается к атрибутам однозначно (найти, выбрать, добавить, заменить и т.д.). Быстрая (хоть и примитивная) реализация атрибутов (хотя бы одного типа!), позволяет разрабатывать и отлаживать логику уровня отношений совершенно независимо от атрибутов. Аналогично логика базы данных разрабатывается совершенно независимо от уровня отношений (таблиц). Всё это хорошо, но... для реальной СУБД неприменимо. И тогда начинается внутреннее развитие уровней, где используются более изощрённые механизмы (и соответствующие методы). Но влияет ли такое развитие на логику смежных уровней? Нет, не влияет. Теперь мы реализовали то, что нужно реальной СУБД, она эффективно хранит информацию, быстро её ищет и извлекает, умеет добавлять, изменять и удалять информацию. Здорово! Пришло время подумать о сервисных функциях... И тогда мы расширяем интерфейсы уровней, добавляя в них новые элементы, и точно также можем сначала реализовать простейшие варианты, а потом их улучшать...
Означает ли это, что простейшие варианты повисают в системе "мёртвым грузом"? Нет, не означает. Они могут использоваться самой системой. Те же атрибуты, которые представлялись простым массивом однородных данных вполне пригодились для... реализации отношений. Ведь отношение - это массив атрибутов, а атрибуты (независимо от их типа) внутри отношения представляются просто, как "атрибут". Аналогично и с другими простыми реализациями... они все оказались востребованными.
-
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Он представим в виде строки. Но разве он является строкой?
-
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Он представим в виде строки. Но разве он является строкой?
В базе данных, конечно, является.
-
Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД...
Не очень понятно... Но для прояснения ситуации хотелось бы сначала определиться с развитием и расширением интерфейса. Это одно и то же? И обозначает, что в, например, интерфейсе из 3 функций появилась ещё одна или несколько?
-
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Он представим в виде строки. Но разве он является строкой?
В базе данных, конечно, является.
Всё равно как-то непонятно. В соответствии с протоколом, адрес электронной почты записывается особым образом. Он содержит имена (пользователь, домен), разделённые особыми символами. Имена - это строки, которые по протоколу должны содержать ограниченный набор символов. Из-за этого понятно, почему в БД почта может быть отдельным типом. Но непонятно, почему почтовый адрес является потомком строки.
-
Ну а как тогда использовать преимущества (или дополнения) у наследников, если интерфейс между уровнями у нас задан жёстко? Или другими словами - как вызвать методы, которые появились у наследников?
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
Если же речь идёт о развитии интерфейса, то под-уровень, реализует это развитие у себя, а над-уровень, обращается к расширенному интерфейсу.
Поясню на примере проекта СУБД...
Не очень понятно... Но для прояснения ситуации хотелось бы сначала определиться с развитием и расширением интерфейса. Это одно и то же? И обозначает, что в, например, интерфейсе из 3 функций появилась ещё одна или несколько?
Если интерфейс правильно спроектирован, то его развитие связано только с расширением (добавлением новых элементов).
-
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Он представим в виде строки. Но разве он является строкой?
В базе данных, конечно, является.
Всё равно как-то непонятно. В соответствии с протоколом, адрес электронной почты записывается особым образом. Он содержит имена (пользователь, домен), разделённые особыми символами. Имена - это строки, которые по протоколу должны содержать ограниченный набор символов. Из-за этого понятно, почему в БД почта может быть отдельным типом. Но непонятно, почему почтовый адрес является потомком строки.
Потому, что электронный адрес - частный случай строки.
-
Может быть, частный случай абстрактной строки.
Но никак не конкретной реализации, с конкретной длиной, разрядностью 8 бит или 16 бит и т.п.
Почему я должен, вводя новую абстракцию "E-Mail", наследовать её от частной реализации строки?
-
Если Вы столкнулись с плохим решением, не имея возможности его изменить, то это не повод хвататься за "костыли", приступая к решению новой задачи. И я постоянно почёркиваю, что ООП - это, прежде всего, Проектирование, а только потом Программирование. И здесь я обсуждаю проекты, а не... косяки в коде.
А. Ну тогда на этом можно и закончить. Потому как у меня претензии только к легкости получения косяков с помощью данного средства (при внешней видимости ООП), а не к самому средству (наследованию реализации) в вакууме.
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Все зависит от того, что же такое строка. Если байты, которые можно хранить/отображать в виде символов - то да, почему бы и нет. Если у строки появляются более интересные операции, например добавление/удаление символов, то я однозначно назову такое наследование ошибкой проектирования.
-
А. Ну тогда на этом можно и закончить. Потому как у меня претензии только к легкости получения косяков с помощью данного средства (при внешней видимости ООП), а не к самому средству (наследованию реализации) в вакууме.
При том, что ценность данного средства при нормальном проектировании и нормальной декомпозиции - чисто оптимизационная + чуть меньше кода писать. Т.е., наследование интерфейсов (если оно нужно) покрывает те же архитектурные аспекты.
-
Может быть, частный случай абстрактной строки.
Но никак не конкретной реализации, с конкретной длиной, разрядностью 8 бит или 16 бит и т.п.
Почему я должен, вводя новую абстракцию "E-Mail", наследовать её от частной реализации строки?
Хм... ответ, вроде как, очевиден... данное наследование позволяет наследовать для e-mail все методы, которые используются для строки.
В Вашем случае, как я его понимаю, придётся реализовывать все методы у частной реализации строки, а потом их же реализовывать у e-mail... Вот радость-то... для разработчика...
-
Не знаю как применительно к базе данных, но в общем случае наследование емыла от строки выглядит крайне странно.
Что же странного? Для базы данных e-mail - это просто строка... со своими особенностями, и всё что справедливо для строк, вполне справедливо для e-mail (обратное неверно).
Все зависит от того, что же такое строка. Если байты, которые можно хранить/отображать в виде символов - то да, почему бы и нет. Если у строки появляются более интересные операции, например добавление/удаление символов, то я однозначно назову такое наследование ошибкой проектирования.
Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...
-
Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...
"Вырезать домен" и "вырезать подстроку" - совершенно разные операции. Разные по названию, по смыслу и даже по количеству параметров. Предоставление клиентам емыла через такой интерфейс чревато ошибками в рантайме, если пытаться поддержать инварианты (валидность) емыла. А если не пытаться поддерживать валидность емыла, то это не емыл, а просто строка.
-
Речь идёт о проекте СУБД. В стандартах SQL нет строковых функций добавления или удаления символов.
Но если такие функции появятся, то я не вижу причин, по которым их нельзя применять к e-mail. Например, получить/вырезать домен из e-mail адреса...
"Вырезать домен" и "вырезать подстроку" - совершенно разные операции. Разные по названию, по смыслу и даже по количеству параметров.
Предоставление клиентам емыла через такой интерфейс чревато ошибками в рантайме, если пытаться поддержать инварианты (валидность) емыла. А если не пытаться поддерживать валидность емыла, то это не емыл, а просто строка.
Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие. Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.
-
Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие.
Дык, мы ж тут вспоминали товарща Лисков с ее принципом. Если емыл наследник строки, то для него справедливы (имеют смысл) все операции (строковые) родителя. "Вырезать подстроку" - не имеет смысла для емыла. Значит емыл не может быть наследником строки.
Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.
А зачем тогда вводить тип "емыл" для СУБД? Может достаточно названия колонки? А в каком-то другом месте (ORM) иметь нормальную типизацию на нормальном ООП языке (не SQL).
-
Зачем сопоставлять разные функции: вырезать домен и вырезать подстроку? Представление e-mail, в виде строки, добавляет новые возможности, а не замещает существующие.
Дык, мы ж тут вспоминали товарща Лисков с ее принципом. Если емыл наследник строки, то для него справедливы (имеют смысл) все операции (строковые) родителя. "Вырезать подстроку" - не имеет смысла для емыла. Значит емыл не может быть наследником строки.
Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..
Зачем СУБД заниматься проверкой валидности e-mail?.. Для СУБД адрес e-mail - частный случай строки.
А зачем тогда вводить тип "емыл" для СУБД? Может достаточно названия колонки? А в каком-то другом месте (ORM) иметь нормальную типизацию на нормальном ООП языке (не SQL).
Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..
-
Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..
Потому что осмысленность этой операции применительно к емылу стремится к нулю. С одной стороны. С другой стороны мы с хорошей вероятностью получим невалидный емыл (или исключение). С третьей стороны, дизайн "класса емыл" при котором "для вырезания домена" (со стороны пользователей этого класса) сначала, например, определяются позиции домена, а потом по этим позициям вырезается подстрока - является очевидным нарушением инкапсуляции (вываливанием потрохов реализации на голову использующего это безобразие программиста).
Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..
Не знаю. У меня вообще с типами в SQL как-то не сложилось. Конкретно в M$ всякая типизация неюзабельна в принципе, если предполагается хоть какое-то изменение созданных типов. Сильно проще рассматривать СУБД как нетипизированное хранилище с минимальным контролем целостности. А все интересное делать в ORM и выше.
-
Почему из строки e-mail'а не имеет смысла вырезать подстроку?.. Где/кем об этом говорилось?..
Потому что осмысленность этой операции применительно к емылу стремится к нулю.
Почему? Например, нужен только ник пользователя...
С другой стороны мы с хорошей вероятностью получим невалидный емыл (или исключение).
Проверку на правильность адреса вряд ли можно отнести к функциям СУБД.
С третьей стороны, дизайн "класса емыл" при котором "для вырезания домена" (со стороны пользователей этого класса) сначала, например, определяются позиции домена, а потом по этим позициям вырезается подстрока - является очевидным нарушением инкапсуляции (вываливанием потрохов реализации на голову использующего это безобразие программиста).
Какая инкапсуляция? Мы говорим про реляционную СУБД, где данные открыты для пользователей (при наличии у пользователей прав, разумеется). Если считаете необходимым "вырезать" домен, то можно предусмотреть для типа данных e-mail, соответствующие функции. Об этом же и речь.
Этот тип вводился только в качестве примера... Не нравится, не рассматривайте. Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..
Не знаю. У меня вообще с типами в SQL как-то не сложилось.
Это видно...
Конкретно в M$ всякая типизация неюзабельна в принципе, если предполагается хоть какое-то изменение созданных типов.
Про MS SQL ничего сказать не могу, я ориентируюсь только на стандарты и при разработке БД и при проектировании СУБД тоже.
Сильно проще рассматривать СУБД как нетипизированное хранилище с минимальным контролем целостности. А все интересное делать в ORM и выше.
Несогласен.
-
Всё же наверное правильнее для типа email агрегировать строку, а не наследоваться от неё.
Для строк имеют смысл такие операции, как выделение подстроки, поиск символа/подстроки, конкатенация строк.
Для емейла эти операции смысла не имеют, а нужны операции выделения имени пользователя и имени домена (в виде строк), ну и на случай каких-то специальных обработок -- операция конвертирования в строку (возможно, просто возвращающая внутреннее представление в виде строки).
Зачем наследовать емейл от строки -- совершенно непонятно...
-
Всё же наверное правильнее для типа email агрегировать строку, а не наследоваться от неё.
Для строк имеют смысл такие операции, как выделение подстроки, поиск символа/подстроки, конкатенация строк.
Для емейла эти операции смысла не имеют, а нужны операции выделения имени пользователя и имени домена (в виде строк), ну и на случай каких-то специальных обработок -- операция конвертирования в строку (возможно, просто возвращающая внутреннее представление в виде строки).
Зачем наследовать емейл от строки -- совершенно непонятно...
SELECT 'Уважаемый ' || SUBSTR(C.ADDRESS FROM 1, FINDSUBSTR(C.ADDRESS, '@')) || ' пишу Вам по адресу: ' || C.ADDRESS FROM CLIENTS C WHERE UPPER(EMAIL_DOMAIN(C.ADDRESS)) = 'RU';
где
SUBSTR и UPPER - стандартные функции SQL;
FINDSUBSTR и EMAIL_DOMAIN - выдуманные названия функций, первая принимает строки, вторая только e-mail.
-
Поскольку разговор идет вокруг выкусывания кусков из e-mail, да еще "быстро":
Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..
, то во всех дальнейших рассуждениях присутствует банальная ошибка.
А именно: данные предполагается хранить не в первой нормальной форме.
-
Поскольку разговор идет вокруг выкусывания кусков из e-mail, да еще "быстро":
Но если, например, для пользователей удобно иметь быстрый поиск/выборку по доменам, указанным в адресе, то почему бы не иметь специальный тип?..
, то во всех дальнейших рассуждениях присутствует банальная ошибка.
А именно: данные предполагается хранить не в первой нормальной форме.
Угу... равно, как и даты (год + месяц + день), время и пр.
-
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
А кто ещё будет вызывать методы, если не надуровень? Да, методы нового класса не входят в интерфейс между уровнями, потому что это методы одного из классов в иерархии классов. А не все классы иерархии имеют одинаковое количество или одинаковые названия для новых методов. И ещё: поля класса скрыты от внешнего наблюдателя, поэтому мы можем влиять на них только через имеющиеся методы. Если мы наследуемся от класса, то ко внутреннему состоянию доступа иметь не будем (если разработчик класса об этом не позаботился). Как мы сможем расширить состояние? Мне в голову варианты, полезные на практике, не приходят. Состояние, которое будет добавлено в класс, окажется независимым от состояния исходного класса, а потому, вполне сможет существовать в качестве отдельной сущности (ещё одного класса).
Вот, у Вас в качестве примера представлена схема реализации атрибутов. Первоначально, как Вы говорите, используется простейшая реализация на массивах. Она не будет использоваться в законченной БД, но очень полезна на этапе реализации. Но когда доходит дело до эффективной реализации атрибутов, то мы оказываемся перед выбором одного из двух вариантов. (В общем случае вариантов может оказаться больше, но меня интересует именно этот частный случай.) Первый вариант - использовать исходный класс в качестве базового для более эффективного. Ко всем сокрытым полям мы доступа не имеем, да и массив нам, в общем-то, не нужен, поэтому мы переопределяем все открытые методы для работы с новой структурой данных. Второй вариант - сделать ещё один класс, имеющий такой же интерфейс, как и первоначальный простой класс. Для того, чтобы языки вроде Java считали интерфейсы этих классов одинаковыми, нужен либо общий предок (обычно, abstract), либо отдельное объявление интерфейса, на которое есть отсылка в исходниках обоих классов. Я отдаю предпочтение второму варианту, а Вы?
-
И ещё: поля класса скрыты от внешнего наблюдателя, поэтому мы можем влиять на них только через имеющиеся методы. Если мы наследуемся от класса, то ко внутреннему состоянию доступа иметь не будем (если разработчик класса об этом не позаботился).
Иногда скрыты, иногда нет.
Представьте себе иерархию классов объектов сообщений. Кому придёт в голову сделать поля объектов сообщений приватными? :)
-
Зачем наследовать емейл от строки -- совершенно непонятно...
Я просто сделал большую поправку на СУБД. Типа там так положено :) Возможно в силу непосредственной завязки на способ хранения. Потому как просто общими рассуждениями к такому ОО дизайну придти трудно.
-
Если методы появились вне интерфейса, то зачем их вызывать извне?.. Над-уровень об этих методах и сущностях ничего не знает и знать ему не положено.
А кто ещё будет вызывать методы, если не надуровень?
Методы может вызывать сам объект, может вызывать система, но если это публичный метод. Имеется ввиду та часть системы, которая обслуживает данный уровень, я обозначу эту часть, как "служебная часть системы".
Да, методы нового класса не входят в интерфейс между уровнями, потому что это методы одного из классов в иерархии классов. А не все классы иерархии имеют одинаковое количество или одинаковые названия для новых методов.
Любой класс иерархии создаётся с целью реализовывать интерфейсы с над-уровнем, вне этого служения ни один класс не имеет смысла.
И ещё: поля класса скрыты от внешнего наблюдателя, поэтому мы можем влиять на них только через имеющиеся методы. Если мы наследуемся от класса, то ко внутреннему состоянию доступа иметь не будем (если разработчик класса об этом не позаботился). Как мы сможем расширить состояние? Мне в голову варианты, полезные на практике, не приходят. Состояние, которое будет добавлено в класс, окажется независимым от состояния исходного класса, а потому, вполне сможет существовать в качестве отдельной сущности (ещё одного класса).
Не все элементы (данные и методы) закрыты для наследования. При разработке класса, надо учитывать возможности его специализации/расширения. Я понимаю, что опять посыплются вопросы о том, что мы заранее не знаем, кто и как будет специализировать/расширять класс... Поэтому сразу отмечу, что развитие иерархии подчинено интерфейсам, интерфейсы определяются архитектурой системы, а архитектура системы, в свою очередь, определяется теми целями и задачами, которые поставлены при создании системы. Это достаточно строгий подход, который вполне поддаётся формализации. (Если я всё же сумею дописать тему "проектирование подсистемы "Сбыт", то там основной акцент делается именно на этом подходе...). Другими словами, рассуждая о развитии понятий атрибуты, отношения, базы данных, нельзя предаваться фантазиям на тему... надо рассуждать строго в рамках заданной темы. Тема любого уровня определяется интерфейсами... как сказано выше.
Вот, у Вас в качестве примера представлена схема реализации атрибутов. Первоначально, как Вы говорите, используется простейшая реализация на массивах. Она не будет использоваться в законченной БД, но очень полезна на этапе реализации. Но когда доходит дело до эффективной реализации атрибутов, то мы оказываемся перед выбором одного из двух вариантов. (В общем случае вариантов может оказаться больше, но меня интересует именно этот частный случай.) Первый вариант - использовать исходный класс в качестве базового для более эффективного. Ко всем сокрытым полям мы доступа не имеем, да и массив нам, в общем-то, не нужен, поэтому мы переопределяем все открытые методы для работы с новой структурой данных. Второй вариант - сделать ещё один класс, имеющий такой же интерфейс, как и первоначальный простой класс. Для того, чтобы языки вроде Java считали интерфейсы этих классов одинаковыми, нужен либо общий предок (обычно, abstract), либо отдельное объявление интерфейса, на которое есть отсылка в исходниках обоих классов. Я отдаю предпочтение второму варианту, а Вы?
Повторю... взаимодействие с любым классом происходит через интерфейсы уровня, никакого прямого обращения к методам или данным объектов нет и быть не может (кроме случаев указанных выше).
Попробуйте рассуждать таким образом... Есть интерфейс, наша задача создать такую иерархию классов, которая позволила бы работать посредством данного интерфейса с определёнными типами данных (для уровня атрибутов), с любыми типами отношений/таблиц (для уровня отношений), с любыми типами баз данных (для уровня баз данных).