Comments 8
Программные интерфейсы — это, пожалуй, самая явная формализованная абстракция. Отсекается все лишнее и остаётся только «что оно делает» без «как оно делает».Не совсем так.
Во-первых, формализации как таковой — интерфейсы никак не касаются вообще. Формализация — это вообще другая «опера».
Во-вторых, вы пишете «остаётся только «что оно делает»», но это не так. Потому что в более широком логическом смысле интерфейс может быть и не реализован, и тут вы верно пишете «без «как оно делает»», но у всего этого тогда появляется третий смысл, в случае если интерфейс не реализован. И он явно следует, например, из английского образования «имен» интерфейсов, когда «приматывается» окончание -able. А оно обозначает допустимую возможность, и это самое важное в логике интерфейсного наследования.
Пример: банальный интерфейс формы может быть реализован, и это тривиально;
далее есть интерфейс формы, и он не реализован, и будет реализован возможно, или же не будет — это уже второй смысл;
и третий смысл — ОН САМЫЙ ГЛАВНЫЙ — у объекта наследующего интерфейс — есть допустимая возможность (-able), которая как раз таки и обозначает, что объект ВПОЛНЕ МОЖЕТ БЫТЬ (-able) соотносится как-то с формой этими тремя смыслами.
Третий смысл легко понимается как некий флаг:
obj: ishapeable, icolorable
При этом, если у интерфейсов нет ни одного метода (а логически так может быть), то интерфейсы тут говорят следующее: у объекта МОЖЕТ БЫТЬ (допустима возможность иметь, без реализации) форма и цвет, но какие они — не существенно…
А потому, логически, интерфейс — это «самая» не явная абстракция, или как говорят «абстрактная абстракция».
И т.д.
пс: про каждый ваш абзац можно сильно долго писать как оно на самом деле, но извините, лень…
Во-первых, формализации как таковой — интерфейсы никак не касаются вообще. Формализация — это вообще другая «опера».
Мне кажется, нужно определить, что значит формализация.
Если принимать, что формализация — это возможность эту абстракцию потрогать\посмотреть, то я думаю, что автор имеет в виду, что интерфейс (я имею в виду не графический, а интерфейс как контракт), можно посмотреть и увидеть описание, что именно он делает.
Во-вторых, вы пишете «остаётся только «что оно делает», но это не так. Потому что в более широком логическом смысле интерфейс может быть и не реализован, и тут вы верно пишете «без «как оно делает»
Как мне кажется, в данном случае это вообще не важно, реализован интерфейс или нет, если вы рассматриваете его отдельно, независимо от реализации. Вы можете увидеть, что он делает.
Проблема любой онтологии состоит в том, что она пытается описывать понятия, используя понятия. В общем случае, одного порядка (если мы будем повышать уровень абстрактности, то в какой-то момент достигнем момента, когда онтологическая модель описывается в терминах онтологической модели).
При этом несовместимость базовых онтологических представлений (т.е. базовой иерархии понятий) чревата полным взаимным непониманием, а семантические различия в определении понятий (синонимы, или «каждый понимает по-своему») чревата конфликтами, причём очень трудными — ведь мы не можем объяснить другому человеку что мы имеем в виду не используя понятия нашей онтологической модели, и если у нас уже есть семантический конфликт, то он только усугубится.
TL;DR; В таких случаях я считаю самым полезным пытаться придумать свой (общий с этим человеком) набор понятий, который будет новым и для него, и для меня. В целом это трудно, и даже осложнит общение с другими, но это единственный метод реально разрулить онтологические хэш-коллизии.
При этом несовместимость базовых онтологических представлений (т.е. базовой иерархии понятий) чревата полным взаимным непониманием, а семантические различия в определении понятий (синонимы, или «каждый понимает по-своему») чревата конфликтами, причём очень трудными — ведь мы не можем объяснить другому человеку что мы имеем в виду не используя понятия нашей онтологической модели, и если у нас уже есть семантический конфликт, то он только усугубится.
TL;DR; В таких случаях я считаю самым полезным пытаться придумать свой (общий с этим человеком) набор понятий, который будет новым и для него, и для меня. В целом это трудно, и даже осложнит общение с другими, но это единственный метод реально разрулить онтологические хэш-коллизии.
А потом приходит абстракция абстракций… и начинается апокалипсис абсолютный перфекционизм.
текут
Программные интерфейсы — это, пожалуй, самая явная формализованная абстракция.Разрешите не согласиться. Классическая абстракция в программировании — это типы данных начиная с классического Паскаля (и раньше), потом добавились ОО классы.
В итоге у двух разных людей может быть очень разное восприятие одних и тех же сущностей реального мира.Два грамотных программиста одинаково воспринимают тип Real, тип Integer и array [0..2] of integer.
Вопрос: GUI — это программный интерфейс? Взять, нпр., объект «форма» (в смысле «окно»).
у объекта МОЖЕТ БЫТЬ (допустима возможность иметь, без реализации) форма и цвет, но какие они — не существенно…Если не существенно, то форма формы и цвет реализуются средой по умолчанию. Но кому и когда не существенно? Кодеру, который пишет обработчики событий для этой формы, м.б. не важно красная форма или зеленая, но до тех пор пока не возникнет, нпр., задача: при неправильном клике пользователя форма должна краснеть, а при правильном зеленеть. Но, да, оттенки цвета кодера при этом волновать не будут. А вот дизайнер скажет: что зеленый слишком кислотный, а красный слишком блеклый.
Т.о., учитывая приведенные примеры, смысл секции «Итого» не понял.
Посмотрите курс про теорию познания, несмотря на то, что там больше с точки зрения социологии и о программировании ни слова. postnauka.ru/courses/51323
Из определения можно сделать вывод, что абстракцией может быть только осмысленное.
«вся эта туфта» это термин или осмысленная абстракция?
Обобщение не всегда осмысленно. Это просто обобщение.
Sign up to leave a comment.
Кратко об абстракциях