Що таке абстракція? [зачинено]

Чи існує загальноприйняте визначення поняття " абстракція програмування" , яке використовують програмісти? [Зауважте, програмування абстракції не слід плутати зі словниковими визначеннями для слова "абстракція".] Чи є однозначне чи навіть математичне визначення? Назвіть кілька чітких прикладів абстракцій?

Відповідь "Чи можете ви визначити, що абстрагування програмування більш-менш математично?" є "ні". Абстракція - це не математичне поняття. Було б як би попросити когось математично пояснити колір лимона.

Якщо ви хочете добре визначити: абстракція - це процес переходу від конкретної ідеї до більш загальної. Наприклад, погляньте на мишку. Це бездротовий зв’язок? Який у нього датчик? Скільки кнопок? Це ергономічно? Наскільки воно велике? Відповіді на всі ці запитання можуть точно описати вашу мишу, але незалежно від того, що відповіді, це все ж миша, оскільки це вказівний пристрій з кнопками. Це все, що потрібно, щоб бути мишкою. "Silver Logitech MX518" - конкретний предмет, а "миша" - це абстракція цього. Важливо подумати, що немає такого конкретного об’єкта, як «миша», це лише ідея. Миша на вашому столі завжди є щось більш конкретне - це '

Абстракція може бути шаруватою і настільки дрібнозернистою або крупнозернистою (як MX518 - миша, яка є вказівним об'єктом; це комп'ютерна периферія, яка є об'єктом, що живиться від електрики), може йти, наскільки хочеш , і практично в будь-якому напрямку, яке ви хочете (у миші є дріт, це означає, що я міг би класифікувати її як об'єкти з дротом. Він також плоский на дні, тому я міг би класифікувати його як вид об'єктів, які не будуть котитися, коли розміщені вертикально на похилій площині).

Об'єктно-орієнтоване програмування будується на концепції абстракцій та сімей або їх груп. Хороший OOP означає вибір хороших абстракцій на відповідному рівні деталізації, які мають сенс у галузі вашої програми та не «просочуються». Перший означає, що класифікація миші як об’єкта, який не буде котитися по похилій площині, не має сенсу для програми, яка описує комп'ютерне обладнання, але це може мати сенс для фізичного симулятора. Останнє означає, що вам слід намагатися уникати "боксу" в ієрархію, яка не має сенсу для якихось об'єктів. Наприклад, в моїй ієрархії вище ми впевнені, що всікомп'ютерна периферія живиться від електрики? А як же стилус? Якщо ми хочемо згрупувати стилус до категорії "периферійні", у нас виникне проблема, оскільки вона не використовує електрику, і ми визначили комп'ютерну периферію як об'єкти, які використовують електроенергію. Проблема кола-еліпса - найвідоміший приклад цієї головоломки.

Я категорично не згоден з більшістю відповідей.

Це моя відповідь:

Враховуючи два набори G і H, між ними можна визначити з'єднання Галуа (альфа, бета) , і один, можна сказати, конкретизувати інший; Зворотний зв'язок, і один - абстракція іншого. Функції - це функція конкретизації та абстракції.

Це випливає з теорії абстрактної інтерпретації комп'ютерних програм, яка, як правило, є статичним аналізом на сьогоднішній день.

Абстракція більше зосереджена на увазі Whatі менше How. Або ви можете сказати, знайте лише те, що вам потрібно, і просто довіряйте постачальнику всіх інших послуг. Він іноді навіть приховує особу постачальника послуг.

Наприклад, на цьому веб-сайті передбачена система запитання та відповіді на них. Практично всі тут знають, які процедури запитувань, відповідей, голосування та інших речей цього сайту. Але мало хто знає, які основні технології. Як, наприклад, чи розроблявся сайт за допомогою ASP.net mvc або Python, чи працює він на Windows або Linux-сервері тощо. Тому що це не наш бізнес. Отже, цей сайт зберігає шар абстрагування над його базовим механізмом для нас, що надають послугу.

Деякі інші приклади:

• Автомобіль приховує всі свої механізми, але надає спосіб водіння, заправки та обслуговування його власникові.

• Будь-який API приховує всі деталі його реалізації, надаючи послугу іншим програмістам.

• Клас в ООП приховує своїх приватних членів і здійснення громадських членів, які надають послугу для виклику публічних членів.

• Під час використання об’єкта типу a Interfaceабо abstract classin у Java або C ++ реальна реалізація прихована. І не тільки приховані, реалізація методів, оголошених у Interface, також може бути різною в різних реалізованих / успадкованих класах. Але коли ви отримуєте ту саму послугу, просто не турбуйтеся, що Howвона реалізована, а саме Who/ Whatнадає послугу.

• Приховування особи : для речення "Я знаю, що Сем може писати комп'ютерні програми". абстракція може бути - "Сем програміст. Програмісти вміють писати комп'ютерні програми." У другому твердженні людина не важлива. Але його вміння займатися програмуванням важливо.

Абстрагування програмування - це спрощена модель проблеми.

Наприклад, TCP / IP-з'єднання - це абстракція над надсиланням даних. Ви просто включаєте ip-адресу та номер порту та надсилаєте їх до API. Ви не переймаєтесь усіма деталями проводів, сигналів, форматів повідомлень та відмов.

Абстракція - це лише версія програмування теореми.

У вас формальна система, ви пропонуєте думати про цю систему. Ви робите доказ цього, і якщо це виходить, то у вас є теорема. Знаючи, що ваша теорема дотримується, ви можете використовувати її для подальших доказів щодо системи. Примітиви, що надаються системою (наприклад, якщо типи операторів та значення int), зазвичай розглядаються як аксіоми, хоча це не зовсім вірно, оскільки все, що не є інструкціями щодо процесора, написаними в машинному коді, є своєрідною абстракцією.

У функціональному програмуванні ідея програми як математичного висловлювання є дуже сильною, і часто система типу (у сильній, статично типізованій мові, як Haskell, F #, або OCAML) може використовуватися для перевірки теоретичності через докази.

Наприклад: скажімо, що ми маємо перевірку додавання та рівності як примітивні операції, а цілі чи булеві значення - як примітивні типи даних. Це наші аксіоми. Отже, ми можемо сказати, що 1 + 3 == 2 + 2це теорема, а потім скористайтеся правилами додавання і цілих чисел та рівності, щоб побачити, чи справжнє це твердження.

Давайте припустимо, що ми хочемо множення, і наші примітиви (заради стислості) включають циклічну конструкцію та засоби для призначення символічних посилань. Ми могли б це зробити

ref x (*) y := loop y times {x +}) 0

Я буду робити вигляд, що я це довів, демонструючи, що множення має місце. Тепер я можу використовувати множення, щоб робити більше речей із моєю системою (мова програмування).

Я також можу перевірити систему типів. (*) має тип int -> int -> int. Це займає 2 ints та виводить int. Додавання має тип int -> int -> int, тому 0 + (rest) утримується до тих пір, поки (rest) призводить до int. Мій цикл може робити всілякі речі, але я кажу, що він виводить ланцюжок викривлених функцій таким чином, що (x + (x + (x ... + 0))) є результатом. Форма ланцюга додавання є просто (int -> (int -> (int ... -> int))), тому я знаю, що моїм кінцевим результатом буде int. Таким чином, моя система типу підтвердила результати мого іншого підтвердження!

Поглиблюйте цю ідею протягом багатьох років, багато програмістів і багато рядків коду, і у вас є сучасні мови програмування: сердечний набір примітивів і величезна бібліотека «перевірених» абстракцій коду.

Чи була б відповідь Вікіпедії досить хорошою? http://en.wikipedia.org/wiki/Abstraction_%28programming%29

В інформатиці механізм і практика абстрагування зменшують і виділяють деталі, щоб можна було зосередитись на кількох поняттях одночасно.

Ну, математично, "ціле число" - це абстракція. І коли ви робите офіційні докази на зразок того, що x + y = y + x для всіх цілих чисел, ви працюєте з абстракцією "ціле число", а не з конкретними числами, такими як 3 або 4. Те саме відбувається при розробці програмного забезпечення машина на рівні вище регістрів та місць пам'яті. Можна думати більш потужні думки на більш абстрактному рівні, в більшості випадків.

Тут ви отримуєте хороші відповіді. Я б лише застеріг - люди думають, що абстракція - це якось дивовижна річ, яку потрібно поставити на п’єдестал, і якої ви не можете отримати достатньо. Це не так. Це просто здоровий глузд. Це просто визнання подібності між речами, тому ви можете застосувати рішення проблеми до цілого ряду проблем.

Дозвольте мені заглянути ...

У моєму списку роздратовань є те, коли люди говорять про "шари абстракції" так, ніби це добре. Вони роблять «обгортки» навколо занять або розпорядок, які їм не подобаються, і називають їх «більш абстрактними», ніби це зробить їх кращими. Пам’ятаєте байку «Принцеса і горох»? Принцеса була настільки делікатна, що якби під матрацом був горох, вона не змогла б спати, а додавання більше шарів матраців не допоможе. Ідея, що додавання більше шарів "абстракції" допоможе, просто така - зазвичай це не так. Це просто означає, що будь-які зміни в базовій сутності повинні бути переплетені через кілька шарів коду.

Думаю, вам може бути корисною повідомлення в моєму блозі про непрохідні абстракції. Ось відповідна інформація:

Абстракція - це механізм, який допомагає взяти те, що є спільним серед набору пов'язаних фрагментів програми, усунути їх відмінності та дати можливість програмістам безпосередньо працювати з конструкцією, що представляє цю абстрактну концепцію. Ця нова конструкція (практично) завжди має параметризацію : засіб налаштувати використання конструкції відповідно до ваших конкретних потреб.

Наприклад, Listклас може абстрагувати деталі реалізації пов'язаного списку-- де замість думати з точки зору маніпулювання nextта previousпокажчиків, ви можете думати про рівень додавання або видалення значень до послідовності. Абстракція є важливим інструментом для створення корисних, багатих, а часом і складних рис із значно меншого набору більш примітивних понять.

Абстракція пов'язана з інкапсуляцією та модульністю, і ці поняття часто неправильно трактуються.

У Listприкладі інкапсуляція може бути використана для приховування деталей реалізації пов'язаного списку; наприклад, на об'єктно-орієнтованій мові, ви можете зробити приватні nextта previousпокажчики приватними, коли доступ до цих полів дозволений лише реалізації списку

Інкапсуляція недостатня для абстрагування, оскільки це не обов'язково означає, що ви маєте нову чи іншу концепцію конструкцій. Якщо б усі Listкласи дали вам методи аксесуарів стилю ' getNext' / ' setNext', він би інкапсулював вас від деталей реалізації (наприклад, ви назвали поле ' prev' чи ' previous'? Що було його статичним типом?), Але це мала б дуже низький ступінь абстракції.

Модульність стосується приховування інформації : стабільні властивості задаються в інтерфейсі, а модуль реалізує цей інтерфейс, зберігаючи всі деталі реалізації в модулі. Модульність допомагає програмістам справлятися зі змінами, оскільки інші модулі залежать лише від стабільного інтерфейсу.

Приховування інформації сприяє інкапсуляції (щоб ваш код не залежав від нестабільних деталей реалізації), але інкапсуляція не потрібна для модульності. Наприклад, ви можете реалізувати Listструктуру в C, виставляючи « next» і « prevпокажчики» в світі, але і забезпечують інтерфейс, який містить initList(), addToList()іremoveFromList()функції. За умови дотримання правил інтерфейсу ви можете гарантувати, що певні властивості завжди будуть зберігатись, наприклад, забезпечення того, що структура даних завжди буде у дійсному стані. [Класичний документ про модульність Парнаса, наприклад, був написаний із прикладом у зборі. Інтерфейс - це контракт і форма спілкування про дизайн, його не обов'язково перевіряти механічно, хоча саме на це ми покладаємось сьогодні.]

Хоча такі терміни, як абстрактні, модульні та інкапсульовані використовуються як позитивні описи дизайну, важливо усвідомити, що наявність будь-якої з цих якостей не дає автоматичного дизайну:

• Якщо алгоритм n ^ 3 "добре інкапсульований", він все одно буде працювати гірше, ніж вдосконалений алгоритм n log n.

• Якщо інтерфейс бере певну операційну систему, жодна з переваг модульної конструкції не буде реалізована, коли, скажімо, відеоігру потрібно перенести з Windows на iPad.

• Якщо створена абстракція виявить занадто багато несуттєвих деталей, вона не зможе створити нову конструкцію з власними операціями: це буде просто інша назва для тієї ж речі.

Гаразд, я думаю, я зрозумів, що ви запитуєте: "Що таке математичне суворе визначення" Абстракція "."

Якщо це так, я думаю, що вам не пощастило - "абстракція" - це програмний термін архітектури / дизайнерського терміна, і він не має математичного підґрунтя, наскільки я знаю (можливо, хтось, хто краще розбирається в теоретичному КС, виправить мене тут) будь-яке більше, ніж "з'єднання" або "приховування інформації" мають математичні визначення.

Абстракція - це коли ви ігноруєте реквізити, визнані неактуальними на користь тих, які вважаються релевантними.

Абстракція включає інкапсуляцію, приховування інформації та узагальнення. Він не охоплює аналогій, метафор чи евристики.

Будь-який математичний формалізм для поняття абстракції сам по собі був би абстракцією, оскільки це обов'язково вимагало, щоб основна річ була абстрагована у набір математичних властивостей! Поняття теорії категорій морфізму , мабуть, найближче до того, що ви шукаєте.

Абстракція - це не те, що ти декларуєш, це те, що ти робиш .

Як спосіб пояснити це іншій людині, я б пішов навпаки, від результатів назад:

Абстрагування в комп'ютерному програмуванні - це узагальнення чогось до того, що більш ніж одна аналогічна річ може взагалі трактуватися як однакова і оброблятися однаковою.

Якщо ви хочете розширити це, ви можете додати:

Іноді це робиться для досягнення поліморфної поведінки (інтерфейси та успадкування), щоб скоротити повторюваний код на передній панелі, в інших випадках це робиться для того, щоб внутрішні опрацювання чогось можна було замінити на майбутнє подібним рішенням, не змінюючи код з іншого боку абстрагованого контейнера або обгортки, сподіваємось скоротити переробку в майбутньому.

Крім того, я думаю, ви повинні почати з прикладів ...

Ви можете перевірити деякі показники Боба Мартіна

http://en.wikipedia.org/wiki/Software_package_metrics

Однак, я не думаю, що його "абстрактність" така ж, як і ваша. Його скоріше є мірою "недостатньої реалізації на класі", тобто використання інтерфейсів / абстрактних класів. Нестабільність та відстань від головної послідовності, ймовірно, грають більше на те, що ви шукаєте.

Merriam-webster визначає абстрактне як прикметникову істоту: відмежоване від будь-якого конкретного екземпляра.

Абстракція - це модель якоїсь системи. Вони часто перелічують групу припущень, які повинні бути виконані, щоб реальна система змогла змоделювати абстракцію, і вони часто використовуються, щоб ми могли концептуалізувати все більш складні системи. Перехід від реальної системи до абстракції не має жодного формального математичного методу для цього. Це залежить від судження того, хто визначає абстракцію, і яка мета абстракції.

Однак часто абстракції визначаються з точки зору математичних конструкцій. Мабуть, тому, що їх так часто використовують у науці та техніці.

Прикладом є механіка Ньютона. Він передбачає, що все нескінченно мало, і вся енергія зберігається. Взаємодії між об'єктами чітко визначені математичними формулами. Зараз, як ми знаємо, Всесвіт не так працює, і в багатьох ситуаціях абстракція просочується. Але у багатьох ситуаціях це працює дуже добре.

Інша абстрактна модель - це типові елементи лінійної ланцюга, резистори, конденсатори та індуктори. Знову ж взаємодії чітко визначені математичними формулами. Для ланцюгів низької частоти або простих драйверів реле та інших речей аналіз RLC працює добре і дає дуже хороші результати. Але в інших ситуаціях, як, наприклад, у мікрохвильових радіосхемах, елементи занадто великі, взаємодія - тонкіші, а прості абстракції RLC не витримують. Що робити в цей момент, залежить від судження інженера. Деякі інженери створили ще одну абстракцію поверх інших, деякі замінюють ідеальні підсилювачі новими математичними формулами щодо їх роботи, інші замінюють ідеальні підсилювачі на імітовані реальні підсилювачі, які в свою чергу моделюються складною мережею менших розмірів ідеальні елементи.

Як говорили інші, це спрощена модель. Це інструмент, який використовується для кращого розуміння складних систем.

Абстракція являє собою щось (наприклад, концепцію, структуру даних, функцію) з точки зору чогось іншого. Наприклад, ми використовуємо слова для спілкування. Слово - це абстрактне ціле, яке може бути представлене у звукових формах (мовлення) або у вигляді графічних символів (написання). Ключова ідея абстракції полягає в тому, що сутність, про яку йдеться, відрізняється від основного представлення, подібно до того, як слово - це не звуки, які використовуються для його вимови, або літери, які використовуються для його написання.

Таким чином, принаймні теоретично, базове представлення абстракції може бути замінено іншим поданням. На практиці, однак, абстракція рідко цілком відрізняється від основної репрезентації, а іноді представлення " протікає " наскрізь. Наприклад, мова має емоційні підтексти, які дуже важко передати письмово. Через це аудіозапис і стенограма одних і тих же слів можуть мати дуже різний вплив на аудиторію. Іншими словами, абстракція слів часто протікає.

Абстракції зазвичай бувають шарами. Слова - це абстракції, які можуть бути представлені буквами, які, в свою чергу, є абстракціями звуків, які, в свою чергу, абстрагують малюнок руху частинок повітря, що створюються голосовими акордами і виявляються вушними барабанами. .

У інформатиці біти, як правило, є найнижчим рівнем представлення. Наступний рівень абстракції - байти, місця розташування пам'яті, інструкції по збірці та регістри процесора. Тоді у нас є примітивні типи даних та інструкції мови вищого рівня, які реалізуються з точки зору байтів, місць розташування пам’яті та інструкцій зі складання. Потім функції та класи (припускаючи мову ОО), які реалізуються з точки зору примітивних типів даних та вбудовані в мовні інструкції. Потім реалізуються більш складні функції та класи з точки зору більш простих. Деякі з цих функцій та класів реалізують структури даних, такі як списки, стеки, черги тощо. Ті, в свою чергу, використовуються для представлення більш конкретних об'єктів, таких як черга процесів, або список працівників, або хеш-таблиця назв книг .

Один із способів я намагаюся описати це людям, можливо, це не найкращий спосіб

Розглянемо програму, яка додає 2 + 2 та виводить 4

Розглянемо програму, яка додає два числа, введені користувачем, x + y = z

Що корисніше та загальне?

Я б заперечував, що абстракція - це те, що приховує зайві деталі. Однією з найбільш основних одиниць абстрагування є процедура. Наприклад, я не хочу турбуватися про те, як я зберігаю дані в базі даних, коли я читаю ці дані з файлу. Таким чином, я створюю функцію збереження_da_database.

Абстракції також можуть бути об'єднані разом для формування більших абстракцій. Наприклад, функції можуть бути об'єднані в клас, класи можуть бути об'єднані для формування програми, програми можуть бути об'єднані для формування розподіленої системи тощо.

Я завжди думаю абстракцію в програмуванні як приховування деталей і надання спрощеного інтерфейсу. Це головна причина, що програмісти можуть розбити монументальні завдання на керовані частини. За допомогою абстракції ви можете створити рішення частини проблеми, включаючи всі дрібні деталі, а потім надати простий інтерфейс для використання рішення. Тоді ви можете фактично «забути» про деталі. Це важливо, тому що немає жодної можливості одразу зберегти всі деталі надскладної системи у своїй свідомості. Це не означає, що деталі під абстракцією ніколи не потребуватимуть перегляду, але наразі слід пам'ятати лише інтерфейс.

У програмуванні цей спрощений інтерфейс може бути будь-яким: від змінної (вилучає групу бітів і забезпечує простіший математичний інтерфейс) до функції (абстрагує будь-яку кількість обробки в одному дзвінку на рядок) до класу і за його межами.

Зрештою, головна робота програмістів - це, як правило, абстрагуватися від усіх обчислювальних деталей і надати простий інтерфейс, наприклад, графічний інтерфейс, який може використовувати той, хто не знає нічого про те, як працюють комп'ютери.

Деякі з переваг абстракції:

• Дозволяє розбити велику проблему на керовані частини. Додаючи записи людини в базу даних, вам не хочеться возитися з вставкою та врівноваженням дерев індексів у базі даних. Ця робота, можливо, була зроблена в якийсь момент, але зараз її відібрали, і вам більше не доведеться про це турбуватися.

• Дозволяє багатьом людям добре працювати разом над проектом. Мені не хочеться знати всі внески коду мого колеги. Мені просто хочеться знати, як його використовувати, що він робить, і як це вмістити разом із моєю роботою (інтерфейсом).

• Дозволяє людям, які не мають необхідних знань, виконувати складне завдання. Моя мама може оновити свій facebook, і люди, яких вона знає по всій країні, можуть бачити це. Без абстрагування шалено складної системи до простого веб-інтерфейсу, немає ніякого способу, як вона змогла б почати робити щось подібне (і я б це не робив).

Однак абстракція може мати зворотний ефект, що робить речі менш керованими, якщо їх надто використовувати. Розбиваючи проблему на занадто багато дрібних шматочків, кількість інтерфейсів, про які потрібно пам'ятати, збільшується, і зрозуміти, що насправді відбувається, стає важче. Як і більшість речей, потрібно знайти баланс.

Додатковий рівень непрямості.

Вам не хочеться байдуже, чи використовується об’єкт a Catчи a Dog, тому ви перейдете через віртуальну таблицю функцій, щоб знайти потрібну makeNoise()функцію.

Я впевнений, що це може бути застосоване і до "нижчих" і "вищих" рівнів - подумайте про компілятор, який шукає правильну інструкцію для використання для даного процесора, або Monadабстрагування Haskell над обчислювальними ефектами, викликаючи все returnі >>=.

Це те, що я насправді хотів вести блог довший час, але так і не дійшов до цього. На щастя, я зомбі-реп і є навіть щедрість. Мій пост вийшов досить тривалим , але ось суть:

Абстракція в програмуванні - це розуміння сутності об'єкта в заданому контексті.

[...]

Абстрагування помиляється не лише з узагальненням, але й з інкапсуляцією, але це дві ортогональні частини інформації, що приховуються: Сервісний модуль вирішує, що він бажає показати, а клієнтський модуль вирішує, що він бажає бачити. Інкапсуляція - це перша частина, а абстракція - друга. Тільки обидва разом складають повну інформацію.

Сподіваюся, що це допомагає.

Тут нематематична відповідь:

Відмовляючись від програмування, робимо вигляд, що ти зараз не дбаєш про деталі, тоді як насправді ти робиш їх і ти повинен постійно їх дбати. Це в основному прикидається.

Для мене абстракція - це те, чого не існує "буквально", це щось на зразок ідеї. Якщо ви виражаєте це математично, це вже не абстрактно, тому що математика - це мова, яка виражає те, що відбувається у вашому мозку, і це може зрозуміти чужий мозок, тому ви не можете структурувати свої ідеї, тому що якщо ви це зробите, це не ідея більше: вам потрібно було б зрозуміти, як працює мозок, щоб висловити модель ідеї.

Абстракція - це те, що дозволяє інтерпретувати реальність у те, що може бути незалежним від неї. Можна абстрагувати пляж і мрію, але пляж існує, але сон не працює. Але ви могли сказати, що існують, але це неправда.

Найважче в абстракції - це знайти спосіб висловити це, щоб інші люди могли його зрозуміти, щоб це перетворилося на реальність. Це найскладніша робота, і її справді неможливо виконати поодинці: ви повинні придумати відносну модель, яка працює на ваші ідеї і яку може зрозуміти хтось інший.

Для мене абстракція в комп'ютерній мові повинна називатися "математичною" моделлю, мова йде про повторне використання ідей, які можна передавати, і це величезне обмеження порівняно з тим, що можна досягти абстрактно.

Простіше кажучи, атоми стоять поруч, але їм все одно. Великий набір молекул, організованих у людини, може зрозуміти, що він поруч з кимось, але він не може зрозуміти, як це, як атоми позиціонували себе в якійсь схемі.

Один об’єкт, яким керується концепція, взагалі, не може «зрозуміти» себе. Ось чому ми намагаємось вірити в Бога і чому нам важко зрозуміти наш мозок.

Чи можу я отримати свою медаль зараз?

Цікаве запитання. Я не знаю жодного визначення абстракції, яке вважається авторитетним, коли мова йде про програмування. Хоча інші люди надали посилання на деякі визначення з різних галузей теорії CS чи математики; Мені подобається думати про це подібним чином до "супервенції", див. Http://en.wikipedia.org/wiki/Supervenience

Коли ми говоримо про абстракцію в програмуванні, ми по суті порівнюємо два описи системи. Ваш код - це опис програми. Абстракція вашого коду також буде описом цієї програми, але на "вищому" рівні. Звичайно, ви можете мати ще більш високий рівень абстрагування своєї оригінальної абстракції (наприклад, опис програми в архітектурі системи високого рівня порівняно з описом програми в детальному проекті).

Тепер те, що робить один опис "вищого рівня", ніж інший. Ключ - "багаторазова реалізація" - ваша абстракція програми може бути реалізована багатьма мовами багатьма мовами. Тепер ви можете сказати, що можна було б виготовити кілька проектів для однієї програми - двоє людей могли виготовити два різних дизайни високого рівня, які точно описують програму. Еквівалентність реалізацій робить різницю.

Порівнюючи програми чи проекти, ви повинні робити це таким чином, що дозволяє ідентифікувати ключові властивості опису на цьому рівні. Ви можете потрапити на складні способи сказати, що дизайн еквівалентний іншому, але найпростіший спосіб подумати про це - чи може одна двійкова програма задовольнити обмеження обох описів?

Отже, що робить один рівень опису вищим, ніж інший? Скажімо, у нас є один рівень опису A (наприклад, проектні документи) та інший рівень опису B (наприклад, вихідний код). А є вищим рівнем, ніж В, оскільки якщо A1 і A2 - два нееквівалентні описи на рівні A, то реалізація цих описів, B1 і B2 також повинна бути нееквівалентною на рівні B. Однак, зворотній зв'язок не обов'язково відповідає дійсності .

Отже, якщо я не можу створити єдину бінарну програму, яка задовольняє два чіткі документи проектування (тобто обмеження цих конструкцій будуть суперечити один одному), то вихідний код, який реалізує ці проекти, повинен бути іншим. Але з іншого боку, якщо я візьму два набори вихідного коду, які неможливо було б скомпілювати в одну і ту ж двійкову програму, все одно може бути так, що двійкові файли, отримані в результаті компіляції цих двох наборів вихідного коду, задовольняють однаковій конструкції документ. Таким чином, проектний документ є "абстракцією" вихідного коду.

Програмування абстракцій - це абстракції, зроблені кимось на програмному елементі. Скажімо, ви знаєте, як створити меню з його пунктів і речей. Потім хтось побачив цей фрагмент коду і подумав, що, що може бути корисним в інших видах, схожих на гіреахію, і визначила Шаблон дизайну компонентів - це абстрагування першого фрагмента коду.

Об'єктно-орієнтовані шаблони дизайну є досить хорошим прикладом того, що таке абстракція, і я не маю на увазі реальну реалізацію, але спосіб, яким ми повинні підійти до рішення.

Отже, підводячи підсумок, абстрагування програмування - це підхід, який дозволяє нам зрозуміти проблему, це засіб отримати щось, але це не реально