Це моя перша стаття на Medium та перша в 2025 році. Я вирішив показати, як побудувати масштабовану систему за допомогою TypeScript.
Для цього я вибрав змоделювати роботу банкомату. Основною метою цієї публікації є демонстрація деяких хороших практик розробки, а також способів їх використання для моделювання реальної системи.
У цій публікації ми розглянемо використання кількох шаблонів проектування (design patterns) та приклади їх використання. Ми також змоделюємо нашу систему за допомогою UML перед тим, як перейти до кодування.
Сподіваюся, що ви отримаете таку ж насолоду від читання моєї симуляції, яку я отримав, її пишучи.
Що таке банкомат (GAB)?
Банкомат (GAB) — це машина, яка дозволяє здійснювати низку операцій за допомогою магнітної картки, що дає користувачеві доступ до певних привілеїв. Операції обмежені необхідністю проходження перевірок під час роботи з карткою.
Що потрібно знати для реалізації системи
Реалізація цієї системи проходить через кілька етапів:
- Управління сутностями, що можуть виконувати операції
- Управління перевірками операцій
- Налаштування банківської картки
- Налаштування синглетону бази даних
- Управління історією транзакцій
- Управління кінцевими точками для виконання операцій
Управління сутностями, що можуть виконувати операції
Основні операції, які делегуються банкоматом картці, а потім картка — рахунку, це:
- Перевірка балансу
- Отримання історії операцій
- Операції поповнення
- Операції зняття коштів
Банкомат, банківська картка та банківський рахунок мають спільні операції:
- Отримання перевірок
- Фільтрація перевірок залежно від операції
- Перевірка операцій
- Перевірка балансу
- Операції поповнення/зняття
- Отримання історії операцій
Операція, яка може бути виконана лише на картці та банкоматі:
- Вхід до банківського рахунку
Операція, яку може виконати лише банкомат:
- Вихід з банківського рахунку
Шаблонний шаблон (Template Pattern)
Ми створимо клас performOperation, який представляє базовий шаблон для різних сутностей нашої системи, що можуть виконувати операції. Цей клас реалізує 5 контрактів інтерфейсів, а також визначає, як кожна з сутностей — картка, банкомат, рахунок — повинна реалізувати filterOperation та CheckOperations.
Для методів, визначених в різних контрактах інтерфейсів, цей клас змушує своїх підкласів використовувати та реалізовувати їх самостійно.
Шаблон проксі (Proxy Pattern)
Для реалізації 4 основних методів, визначених у PerformOperation, банкомат використовує картку як проксі, а картка, у свою чергу, використовує рахунок як проксі. Точно так же для входу, банкомат і картка реалізують контракт loginInterface. Потім банкомат використовує картку для перевірки входу.
Управління перевірками операцій
Під час виконання операції з карткою система повинна перевірити умови для цієї операції, які були попередньо визначені банком.
Ми повинні визначити сімейство алгоритмів перевірки залежно від операції.
Для нашого прикладу ми визначимо дуже прості перевірки, а саме:
- Максимальна сума зняття для картки
- Перевірка на позитивну суму для депозитів/зняттів
Додаткові перевірки можуть бути додані за потреби, якщо ми хочемо мати набагато складнішу та повну систему.
Шаблонний шаблон (Template Pattern)
Клас BaseValidation представляє базовий шаблон для всіх перевірок. Таким чином, він вимагає від усіх своїх дочірніх класів реалізувати свою власну версію validate.
Налаштування банківської картки
Точно так само, як і в попередньому випадку, ми можемо мати різні типи карток, і для кожного типу буде специфічне подання.
Ми будемо варіювати поведінку карток за двома критеріями:
- Тип картки
- Пакет
Різні категорії типів карток, які ми будемо мати, є наступними:
- Картка заощаджень
- Поточна картка
Якщо ми вважаємо, що операції зняття коштів з картки заощаджень або поточної картки не можуть виконуватись за допомогою однієї картки. Цей тип картки є лише прикладом, у реальному житті це має інше значення. Для поточної картки ми розділимо її на три підкласи, кожен з яких представляє користувацький пакет з набором перевірок.
Ці підкласи такі:
- Картка Start
- Картка Liberty
- Картка Elite
Шаблонний шаблон (Template Pattern)
Використання цього шаблону дозволяє нам налаштувати getValidations та різні перевірки, до яких підлягає кожен тип картки.
Налаштування синглетону бази даних
Оскільки ця стаття зосереджена на використанні шаблонів проектування, ми не будемо використовувати базу даних. Замість цього ми використаємо інстанцію синглетону, яка має в пам'яті всі дані, а саме:
- Банкомат
- Банківські картки
- Історії
- Транзакції
З метою уникнення циклічної залежності через використання деяких класів нам потрібна точка входу, яка створюватиме наші класи. Завжди враховуючи це, деякі класи повинні отримувати інстанцію налаштувань під час виконання. Ми будемо використовувати спеціальний клас для створення класів.
Шаблон фабрики (Factory pattern)
Оскільки ми хочемо мати єдину точку входу для створення карток і банкнот, ми вибрали цей метод. Саме ця інстанція буде використовуватись системою для налаштування.
Шаблон фасаду (Facade pattern)
Ми хочемо приховати певну складність від клієнта при налаштуванні всієї нашої системи. Пройшовши через метод initialize нашого класу SystemInitializer, ми можемо ініціалізувати систему.
Шаблон синглетону (Singleton Pattern)
Ми обрали шаблон синглетону, щоб мати одну інстанцію конфігурації в системі. Цей клас Config представляє базу даних системи.
Управління історією транзакцій
Щодо створення журналів, лише банкомат і рахунок мають право взаємодіяти з нашою інстанцією конфігурації.
Використовуючи зв'язок з конфігураціями, які ми визначили раніше.
- Банкомат буде відповідати за логування входу
- Рахунок буде відповідати за логування операцій.
Щоб отримати історії, залежно від сутності, яка запускає запит, ми звертатимемося до нашої конфігурації, яка містить усі дані, що зберігаються в пам'яті.
Шаблон проксі (Proxy Pattern)
Як ми робили в першій діаграмі, що стосувалась шаблону проксі, це майже та сама механіка, яка тут представлена, але тепер використовується безпосередньо HistoriqueInterface.
Також банкомат і рахунок використовують функціональність TransactionLogger під час операцій для керування історією.
Управління кінцевими точками запитів для виконання операцій
Хоча мета нашої системи полягає в тому, щоб виконувати операції з банкомату, ми повинні мати можливість запускати ті ж операції через картку або рахунок, окрім банкомату.
Тому ми визначимо сімейство команд, кожна з яких буде пов'язана з операцією, яку ми хочемо виконати. Таким чином, з нашої точки входу і в залежності від операції, яку потрібно виконати, ми зможемо викликати відповідну команду.
Оскільки різні сутності реалізують інтерфейси, пов'язані з тими операціями, які вони можуть запускати.
Шаблонний шаблон (Template pattern)
Ще раз ми використовуємо шаблонний шаблон через RequestHandler для створення сімейства обробників запитів для нашої системи. Кожен обробник повинен відповідати належним чином на запит.
Стратегія шаблону (Strategy pattern)
Подання інших дочірніх класів RequestHandler є подібним до цього прикладу, як показано на зображенні. Ця структура дозволяє класу RequestHandler адаптуватися до ситуації, орієнтуючись на агрегаційний клас, з яким він пов'язаний.
Якщо ми вирішимо трохи змінити код точки входу, можна буде запустити операції з наших різних сутностей. Ми цього не робили, а просто підготували нашу систему до прийому запитів з різних джерел.
Після того, як ми детально розглянули різні етапи для налаштування нашої системи, ми підходимо до висновку. Ми побачили шість шаблонів і кілька випадків використання з UML-поданнями мого коду.
Нижче ви знайдете посилання на реалізацію симуляції, яку ми виконали разом. Однак це лише симуляція, тому вона не обов'язково відображає реальність.
[
GitHub — GreyCoderK/tsgabsystem_example
Приклад системи банкомату, написаної за допомогою TypeScript.
github.com
](https://github.com/GreyCoderK/tsgabsystemexample?source=postpage-----14247560ee73--------------------------------)
Перекладено з: Système de guichet automatique de banque