Переваги та недоліки структурування всього коду за допомогою класів та компіляції до класів (наприклад, Java)

Редагувати: моя мова дозволяє багаторазово успадкувати, на відміну від Java.

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

Спочатку я вирішив базувати її на Java.

Це означало, що весь код буде записаний у формі класів, і що код збирається у класи, які завантажуються VM.

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

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

Тепер мені залишається цікаво: які переваги та недоліки мають класи як одиниці компіляції?

Крім того, будь-який загальний коментар до моєї конструкції був би вдячний. Інформаційне повідомлення про мою мову можна знайти тут: http://www.yannbane.com/2012/12/kava.html .

— jcora
джерело

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

— Роберт Харві

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

@delnan: Насправді ви все ще можете використовувати композицію для нарощування функціональності.

— Роберт Харві

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

@delnan: Що не так у використанні успадкування для підтипу та поліморфізму? Ось що для наслідування ...

— Мейсон Уілер

Відповіді:

які переваги мати класи як одиниці компіляції?

Це може зменшити складність мови. Немає потреби в різних конструкціях, все трактується однаково. У деяких проектах (хоча це не є вашим), ви не маєте статики та проблем із дизайном, з якими вони стикаються (питання порядку ініціалізації, обмеження одночасності, незручність із класами generics / type). Це також дозволяє отримати деякі переваги концепції модуля, наприклад, окремі екземпляри модулів для пісочниці або паралелізації; і типізація модулів, де залежності залежать від певного інтерфейсу, і весь модуль, який варто реалізувати, може бути ініційований і скинутий.

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

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

— Теластин
джерело

Я планую лише мати один єдиний клас вищого рівня Object. Я усвідомлюю, що мені, мабуть, потрібна якась особлива поведінка для цього, але поки це окремий випадок, я з цим все в порядку. Я не вірю, хоча у мене будуть проблеми із залежністю. Існує набір класів, які завантажуються під час запуску VM, деякі з них реалізовані на власному рівні (клас системи), але всі вони успадковують від Object. Після того, як все буде завантажено, KVM завантажує клас, який йому було доручено завантажувати, і відпрацьовує залежності. Однак мене цікавить, які проблеми представляє статика?

— jcora

@yannbane - Я не маю на увазі object, я маю на увазі класи, які поводяться як модулі, а не внутрішні класи, які не обов'язково є загальнодоступними поза їх компіляційним блоком. "Випрацює залежності" перетворюється на гігантське гніздо шершнів у деталях, якщо ви хочете будь-якої поведінки стилю DLL; ymmv. Щодо статики .

— Теластин

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

— jcora

@yannbane - Ні, не дуже. Модулі - це модулі, тому що вони миттєві. Інакше у вас просто є простори імен у стилі C ++. Після обмеження класів верхнього рівня на простори імен стилю C ++ вони вже не є класами.

— Теластин

Гм, я все ще в порядку і насправді не бачу проблеми зі створенням модулів з класами. І так, модулі виконують роль просторів імен, особливо модулів Python.

— jcora

Замість того, щоб відповісти на це питання, я піду на один рівень вгору і запропоную вивчити MIT OpenCourseWare , зокрема 6.035 (Комп'ютерна інженерія мови). Це пояснить всю проблематику, щоб ви не спокусилися ставити подібні запитання ще раз.

Інженерія комп'ютерної мови

Єдина необхідна умова - Java.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-035-computer-language-engineering-spring-2010/lecture-notes/

Опис Курсу

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

— гнат
джерело