Чи використовуються події лише для програмування GUI?

Чи використовуються події лише для програмування GUI?

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

Ні. Вони дуже зручні для впровадження спостерігачів та переконання, що класи закриті для модифікації.

Скажімо, у нас є метод, який реєструє нових користувачів.

public void Register(user) {
    db.Save(user);
}

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

public void Register(user) {
    db.Save(user);
    emailClient.Send(new RegistrationEmail(user));
}

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

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

public void Register(user) {
    db.Save(user);

    RaiseUserRegisteredEvent(user);
}

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

Ні.

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

Тригери - це код, який виконується, коли трапляється певна подія (INSERT, DELETE тощо). Мені це здається подією.

Це визначення події у Вікіпедії:

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

Не всі події створюються користувачем. Деякі з них генеруються таймером, як кронтаб, бази даних INSERT, як я згадував раніше.

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

Програмування на основі подій фактично також використовується для високоефективних програмувань сервера.

При типовому навантаженні сервера значна частина часу на обробку результату фактично відбувається з вводу / виводу. Наприклад, витяг даних з (7200 RPM) жорсткого диска може зайняти до 8,3 мс. Для сучасного процесора ГГц це може дорівнювати ~ 1 млн тактових циклів. Якби процесор чекав даних кожен раз (нічого не роблячи), ми втратили б багато циклів годин.

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

Крім того, кожен потік повинен використовувати певний об'єм пам'яті для зберігання свого стану.

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

Найкращим прикладом такого сервера є Node.js , для якого було показано, що він може обробляти 1 мільйон одночасних з'єднань зі скромним обладнанням, тоді як сервер Java / Tomcat би боровся на кілька тисяч.

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

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

Тепер це низький і абстрактний погляд, а ще складніше, щоб добре досягти масштабу. Однак є безліч фреймворків вищого рівня, які займаються цим рівномірно на платформі: мені приходять в голову Twisted for Python, Boost.Asio для C ++ або libevent для C.

Вбудовані системи майже завжди притаманні подій, навіть якщо вони не запрограмовані явно як такі.

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

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

Однією з найпоширеніших і популярних рамок вбудованих систем, керованих подіями, є Quantum Platform (QP) (QP також працює під Linux, Windows та будь-якою unix-подібною ОС.) Державні машини є природним пристосуванням для програмування, керованого подіями, оскільки програма не є "послідовною" у типовому сенсі, скоріше, це набір "зворотних зворотів", які викликаються залежно від стану системи та поточної події.

Повідомлення подій Грегор Хопе.

Архітектури, керовані подією Грегор Хопе.

Архітектура SEDA , валлійська, куллер, пивовар.

як ти справляєшся у звичайному програмі бекенда, коли щось трапляється, роби щось інше?

Кінцева державна машина - це один загальний підхід

Given(State.A)
When(Event.B)
Then(State.C)
    .and(Consequences.D)

У вбудованих системах події відбуваються під час перерв. Існує багато джерел переривань, від таймерів до вводу-виводу.

Також у RTOS можуть бути події. Один приклад - очікування повідомлення з іншого завдання.

Для невбудованої системи, але те, що я робив у C #, була система SCADA. Було багато подій, пов’язаних із тим, що відбувалося на складі, коли завантаження було вивантажено частиною події, що генерується системою, а інша частина записувала новий стан у базу даних. У нас, звичайно, був якийсь клієнт GUI, але це було просто показати стан бази даних, що відображало стан складу. Таким чином, це було серверне програмне забезпечення на основі подій та потоків. Досить складно розвиватися.

https://en.wikipedia.org/wiki/SCADA