Абстракция чаще всего понимается в одном из двух смыслов:
Мысленное отвлечение, обособление от тех или иных сторон, свойств или связей предметов и явлений для выделения существенных их признаков.
Отвлечённое понятие, теоретическое обобщение.
В первом случае абстракция позволяет нам учитывать только необходимые нам свойства объекта реального мира. Например, мы говорим, что Земля имеет форм шара, и понимаем, что на самом деле это не так, но для нас в данном приближении детали не столь важны. Но при этом Земля остаётся Землёй, т.е. мы не заменяем один объект другим.
Разрабатывая информационную систему, мы тоже можем отказаться рассматривать некоторые специфические особенности объектов. И тогда мы получаем огромные плюсы:
Абстрагирование от несущественных в рамках текущей задачи особенностей объекта позволяет делать разрабатываемые нами системы управляемыми в отличие от реального мира, который по своей природе нами не управляем в принципе.
Снижаются затраты на проектирование и реализацию системы, написание документации, тестирование, обучение персонала и ввод в эксплуатацию.
Снижается стоимость владения: пользователи работают только с теми параметрами, которые им реально необходимы в работе. Отсутствуют затраты на ввод/чтение информации, которая не требуется для успешного решения задач, стоящих перед пользователем.
Снижаются требования к комплексу технических средств и увеличивается производительность: система хранит и обрабатывает значительно меньший по объёму массив информации.
Но есть и минус. Он заключается в известном законе: все абстракции дырявы. Т.е. в случае, если пользователю потребуется работать с параметрами, от которых наша система была абстрагирована, то он не сможет нашу систему использовать, т.е. она перестанет быть применимой к решению поставленных задач.
Когда мы говорим о втором понимании абстракции, мы имеем в виду совсем другую методику работы с информацией. Мы говорим, что есть несколько типов объектов, обладающих одинаковыми свойствами и/или выполняющими одинаковые функции, и на сновании этого мы можем выделить обобщающий тип объектов. Например, мы можем сказать, что Земля - это планета. Особенность заключается в том, что один объект заменяется другим объектом, поскольку планета - это не только Земля.
Программисты используют такой подход очень часто при работе с абстрактными и базовыми классами и интерфейсами в ООП. По своей природе, ООП - искусство абстрагирования. В итоге, мы имеем в позитиве следующие позиции:
Увеличивается гибкость, расширяемость и масштабируемость решений. Любая внешняя система может использовать наш API, если в её составе реализован клиентский модуль, поддерживающий принятые нами абстракции. Сторонний производитель может расширять функциональность нашей системы своими плагинами, если они будут реализованы в соответствии с принятыми правилами. Мы сами можем расширять функциональность системы, просто подключая новые модули без изменения старых.
Уменьшается риск внесения в старый действующий код ошибок при расширении функциональности системы. Сокращаются затраты на реализацию и тестирование.
Но мы должны чётко определить правила работы с нашими абстракциями. И опять же, в случае, если эти правила перестанут удовлетворять пользователя, наша система станет неприменимой для решения его задач.
Абстракция чаще всего понимается в одном из двух смыслов:
Мысленное отвлечение, обособление от тех или иных сторон, свойств или связей предметов и явлений для выделения существенных их признаков.
Отвлечённое понятие, теоретическое обобщение.
В первом случае абстракция позволяет нам учитывать только необходимые нам свойства объекта реального мира. Например, мы говорим, что Земля имеет форм шара, и понимаем, что на самом деле это не так, но для нас в данном приближении детали не столь важны. Но при этом Земля остаётся Землёй, т.е. мы не заменяем один объект другим.
Разрабатывая информационную систему, мы тоже можем отказаться рассматривать некоторые специфические особенности объектов. И тогда мы получаем огромные плюсы:
Абстрагирование от несущественных в рамках текущей задачи особенностей объекта позволяет делать разрабатываемые нами системы управляемыми в отличие от реального мира, который по своей природе нами не управляем в принципе.
Снижаются затраты на проектирование и реализацию системы, написание документации, тестирование, обучение персонала и ввод в эксплуатацию.
Снижается стоимость владения: пользователи работают только с теми параметрами, которые им реально необходимы в работе. Отсутствуют затраты на ввод/чтение информации, которая не требуется для успешного решения задач, стоящих перед пользователем.
Снижаются требования к комплексу технических средств и увеличивается производительность: система хранит и обрабатывает значительно меньший по объёму массив информации.
Но есть и минус. Он заключается в известном законе: все абстракции дырявы. Т.е. в случае, если пользователю потребуется работать с параметрами, от которых наша система была абстрагирована, то он не сможет нашу систему использовать, т.е. она перестанет быть применимой к решению поставленных задач.
Когда мы говорим о втором понимании абстракции, мы имеем в виду совсем другую методику работы с информацией. Мы говорим, что есть несколько типов объектов, обладающих одинаковыми свойствами и/или выполняющими одинаковые функции, и на сновании этого мы можем выделить обобщающий тип объектов. Например, мы можем сказать, что Земля - это планета. Особенность заключается в том, что один объект заменяется другим объектом, поскольку планета - это не только Земля.
Программисты используют такой подход очень часто при работе с абстрактными и базовыми классами и интерфейсами в ООП. По своей природе, ООП - искусство абстрагирования. В итоге, мы имеем в позитиве следующие позиции:
Увеличивается гибкость, расширяемость и масштабируемость решений. Любая внешняя система может использовать наш API, если в её составе реализован клиентский модуль, поддерживающий принятые нами абстракции. Сторонний производитель может расширять функциональность нашей системы своими плагинами, если они будут реализованы в соответствии с принятыми правилами. Мы сами можем расширять функциональность системы, просто подключая новые модули без изменения старых.
Уменьшается риск внесения в старый действующий код ошибок при расширении функциональности системы. Сокращаются затраты на реализацию и тестирование.
Но мы должны чётко определить правила работы с нашими абстракциями. И опять же, в случае, если эти правила перестанут удовлетворять пользователя, наша система станет неприменимой для решения его задач.