Спробуємо розібратися чому Java вибирається в сучасних проектах в якості основного мови програмування.
Сі-подібний синтаксис *
У той час, коли створювався мову Java, найпопулярнішою мовою програмування був C ++. Для того, щоб «переманити» програмістів на новий Java було прийнято рішення зробити його максимально схожим на С ++, взявши по можливості краще від нього.
Java і С ++ не єдині, хто володіє подібним синтаксисом. Прабатьком C ++ була мова C (Сі), тому всі мови використовують подібний синтаксис називаються сі-подібними, і їх існує велика кількість (Wikipedia: C-family).
Таким чином якщо ви вже знайомі хоча б з одним з цих мов, то велика кількість точок, фігурних і круглих дужок в Java здадуться вам чимось давно знайомим і звичним. З іншого боку вивчивши синтаксис Java вам буде набагато простіше осягнути і інші мови цього сімейства.
* Синтаксис - це набір правил, яким повинен відповідати текст програми. По-простому: то, як виглядає програма. Складніше - на вікі.
Мова загального призначення
За своїм призначенням мови програмування бувають:
- спеціальні (які вирішують завдання в певній галузі. Наприклад в математиці Fortran, в базах даних SQL);
- загального призначення (вирішальні широкий спектр завдань в будь-яких галузях. Наприклад С ++, Java, C #).
Java відноситься до другого типу, це мова загального призначення, на якому можна написати практично будь-яку програму. На сьогоднішній день на Java створюються програми будь-якого рівня складності: від програмування побутової техніки та мобільних пристроїв (Java ME), до складних високо навантажених сервісів (Java EE).
- універсальний, вирішує будь-які завдання
- в окремих галузях поступається (по швидкості роботи і зручності використання) спеціалізованим мов
Об'єктно-орієнтована
Всі комп'ютерні програми намагаються описати процеси нашого світу в командах процесора. Оскільки комп'ютер нічого не знає про об'єкти нашого світу, програмісту завжди доводилося «переводити» все на мову цифр і інструкцій. Так було до 70-х років, поки не з'явилася об'єктно орієнтована парадигма програмування. З її допомогою стало можливим програмування на рівні об'єктів з нашого світу, а не на рівні цифр зі світу комп'ютерного.
Наприклад, ось так виглядає опис двох столів в не-об'єктних вигляді:
- довжина першого столу: 1200мм
- ширина першого столу: 500мм
- висота першого столу: 1000 мм
- довжина другого столу: 1300мм
- ширина другого столу: 600мм
- висота другого столу: 1100мм
Між параметрами немає ніякого зв'язку, крім їх назв. Можна легко припуститися помилки, в спробі порахувати площу столу: помножити довжину ПЕРШОГО столу на ширину ДРУГОГО.
Приклад об'єктно-орієнтованого опису:
В даному випадку, ми вже оперуємо НЕ розрізненими параметрами, а цілими об'єктами: Перший стіл і Другий стіл.
Програми написані на об'єктно орієнтованих мовах виконувалися повільніше і це було основною причиною того, чому ця парадигма стала популярною лише в 90-х, коли «залізо» стало до цього готове.
Java, як майже всі сучасні мови, це об'єктно-орієнтована мова, на якому досить просто моделювати процеси реального світу, і користуватися всіма перевагами об'єктно орієнтованого підходу.
- ООП використовується в багатьох інших мовах програмування
- широко використовує абстракції
- легко моделювати об'єкти реального світу
- вимагає додаткового вивчення і розвитку абстрактного мислення
функціональний
Коли необхідно зменшити час виконання програми є два очевидні шляхи:
- Оптимізувати програму;
- Збільшити частоту процесора.
З оптимізацією маємо такі проблеми:
- оптимізувати доводиться ВСЕ програми;
- існує логічний ліміт, далі якого оптимізувати неможливо.
Прискорення процесора вирішує ці проблеми, і прискорює виконання відразу всіх програм.
Завдяки закону Мура світ розвивався другим шляхом - прискорював процесори. Закон свідчив, що кожні два роки частота процесорів зобов'язана подвоюватися. Але одного разу закон Мура перестав працювати і частота перестала рости. І ми перестали отримувати необхідну нам прискорення програм. У всьому відразу звинуватили Мура, сказали що він все не так зрозумів, і в закон внесли поправку: чи не частота подвоюється, а кількість транзисторів!
Таким чином останні роки частота процесорів не росте, а росте кількість транзисторів. Транзистори витрачаються на додаткові ядра процесорів. Але якщо подивитися на вище згадані два способи прискорення програм - там немає пункту про додавання ядер. Щоб програму можна було прискорити за допомогою додаткових ядер - вона повинна бути здатна виконуватися незалежними частинами.
Але зробити це не так-то просто: все шматки програм залежать один від одного, залежать від загальних даних (особливо якщо мова йде про об'єктно-орієнтованому програмуванні).
І тут на допомогу приходить функціональне програмування, яке зводить до мінімуму (а в ідеалі повністю виключає) використання загальних даних, що дозволяє легко і просто виконувати програму на різних ядрах.
Об'єктно-орієнтованої парадигми знадобилося 20 років, щоб пройти шлях від теорії до масового використання. Знаючи як стрімко зараз змінюється наш світ, можна подумати що це виключення з правил, і ми приймаємо все нове набагато швидше і охочіше.
Однак функціональній парадигмі програмування треба було набагато більше часу ніж об'єктно-орієнтованої. Вперше ця парадигма була представлена в 30-і роки, проте в широкі маси функціональне програмування починає входити тільки в наші дні.
Існують повністю функціональні мови (Haskel, Erlang) і гібридні - поєднують в собі об'єктно-орієнтована і функціональний підходи (Scala, C ++).
Починаючи з 8 версії Java набуває механізми функціонального програмування (такі як посилання на функції і лямбда-вирази), що дозволяє легко створювати програми, які можуть виконуватися на декількох ядрах одночасно.
- доступні нові прийоми програмування
- легко створюються програми, здатні використовувати одночасно кілька ядер процесора
- вимагає додаткового вивчення і розвитку функціонального (математичного) мислення
Типізація: сувора, статична, явна
сувора типізація
Судячи з назви, якщо типізація сувора - то існують якісь правила, порушувати які не можна.
Приклад (необхідно розуміти що рядки і числа - це різні типи даних):
Додавання двох чисел і двох рядків, не залежно від моделі типізації, всюди відбувається однаково:
Різниця буде коли ми (можливо помилково) спробуємо скласти число і рядок:
5 + «5» =. (10 або «55»)
Строго типізований мову скаже що тут зачаїлася помилка і змусить нас явно привести все до якогось одного типу.
Чи не строго типізований почне хитрувати: він удасться до додаткового набору правил на випадок невідповідності типів. Залежно від цих правил буде обраний один з варіантів:
- Рядок «5» стане числом і результат буде 10 (додавання чисел)
- Число «5» стане рядком і результат буде «55» (конкатенація рядків)
Виходить, що прі не суворої типізації, помилково ми можемо спробувати виконати операцію над несумісними типами даних і в залежності від «додаткових правил» отримати різний результат: 10 або «55».
В Java використовується строгий варіант, який вважає за краще повідомити про помилку і змусити програміста явно привести до якогось типу, тим самим уникнути набору «додаткових правил». на випадок коли типи не збігаються.
- немає додаткових правил автоматичного перетворення типів: їх не потрібно знати і немає помилок неправильного перетворення
- швидко приходить розуміння типізації
- всі необхідні перетворення доводиться виконувати явно
статична типізація
Оскільки типи всіх змінних в Java визначаються статично на етапі компіляції, то є можливість перевірити чи правильно ці типи використані. Наприклад, якщо ми намагаємося відправити автомобіль до ветеринара - Java нам скаже, що ветеринар не приймає об'єкти такого типу. Отже про помилку ми дізнаємося як тільки спробуємо скомпілювати код, а не коли запустимо додаток на сервері.
Таким чином Java уникає цілий клас помилок (помилок несумісності типів), тому що вони все виявляються під час компіляції завдяки статичної типізації.
Природно, що в наші дні ніхто не пише код в блокноті, і не компілює з командного рядка - все це вміють робити сучасні інструменти розробки IDE (IDEA, Eclipse, NetBeans). І все зазначені IDE активно користуються тим, що типізація статична, і перевіряють помилки ще до того, як ми спробуємо код скомпілювати.
Ще одним плюсом статичної типізації є те, що IDE здатна підказувати які методи і властивості є у об'єкта. Це дуже сильно спрощує і розробку, і навчання.
- про помилки несумісних типів ми дізнаємося під час компіляції (з використанням IDE під час написання коду), а не під час виконання програми
- знаючи тип даних IDE може підказувати які операції з ним можна виконати (дуже корисно, особливо на початкових етапах знайомства з мовою)
- необхідність визначати типи самостійно
явна типізація
Для того, щоб оголосити змінну в Java необхідно явно вказати її тип. Наприклад, змінна i целочисленного типу оголошується так:
При цьому насправді Java вміє вивести тип змінної i і без нашого int. Досить було б написати:
- необхідність вказувати типи явно (мікро-проблема)
Крос-платформний
Для того, щоб написане вами додаток могло запускатися на різних платформах (Linux, Windows, Android), воно повинно бути перетворено (скомпілювати) сумісні з цією платформою в процесорні інструкції.
Java декларує, що для її програм цього не потрібно. За рахунок чого це досягається?
Код, написаний на Java, компілюється не в інструкції процесора (як у більшості компільованих мов), а в спеціальний байт-код. Цей байт-код запускається на Java-машині - спеціальною програмою, яка вміє перетворити байт-код в процесорні інструкції.
Таким чином від платформи залежить не код, а Java-машина. Встановивши відповідну Java-машину на кожну платформу наш код однаково працюватиме на кожній з них.
- програми можуть працювати на різних системах
- страждає продуктивність (незначно)
Складальник сміття
Пам'ять. Вона не гумова. У процесі роботи програми створюються об'єкти, захаращуючи пам'ять. На плечі програміста лягає тягар стежити за цими об'єктами, і коли вони стають не потрібні - видаляти їх. Завдання не з простих. Якщо щось пішло не так - утворюється витік пам'яті, і додаток неминуче (це питання часу) зупиниться з помилкою про вичерпання всієї доступної пам'яті.
Попутно складальник вирішує ще одну проблему - фрагментацію пам'яті. Якщо в двох словах суть проблеми в наступному: є шматок пам'яті на 10 осередків, 5 з них зайняті, і 5 вільні. Ви хочете записати цілий об'єкт на 5 осередків в пам'ять - але не можете зробити цього. Оскільки вільні комірки розташовані не підряд, а три спочатку, і дві в кінці.
- не потрібно стежити за об'єктами, і приймати рішення про очищення пам'яті
- немає проблеми фрагментації пам'яті