KE
  • dotNet Web 3.0
  • Engineering Management
    • Process Planning (SDLC)
      • Software development process
      • Basics of SDLC models
      • Scrum
      • Kanban
      • Scrum vs Kanban: applicability
      • Scrumban
    • Estimation
      • Scope Concept
      • Estimates, Targets, and Commitments
      • Overestimate vs Underestimate
      • Decomposition and Recomposition
      • Analogy-based estimations
      • Estimating in Agile
  • Requirements
    • Software Requirements Engineering
      • Requirement definition
      • Levels of Requirements
      • Most common requirements risks
      • Characteristics of Excellent Requirements
      • Benefits from a High-Quality Requirements Process
      • Root Causes of Project Success and Failure
  • Design
    • OOD
      • Abstraction
      • Encapsulation
      • Inheritance vs Aggregation
      • Modularity
      • Polymorphism
      • Abstraction Qualities (cohesion, coupling, etc)
      • Types vs. Classes
      • Separation of concerns principle
      • SOLID
      • Design Patterns
        • Structural patterns
        • Creational patterns
        • Behavioral patterns
      • Most often used design patterns
      • Software Architecture Patterns (structure, pros & cons)
      • Inversion of Control Containers and the Dependency Injection pattern
      • Domain-Driven Design patterns
      • Anti-patterns
    • DB Design
      • Relational Terminology: Entities
      • Relational terminology: Attributes
      • Relational terminology: Records (Tuples)
      • Relationships (One-to-One, One-to-Many)
      • Understanding ER notation
      • Understanding normalization concept
      • Data Integrity
    • Modeling
      • UML: Basic Diagram Types
      • UML: Use Case Diagram (Essentials)
      • UML: Class Diagram (Essentials)
      • Entity Relationship Diagrams
      • Data Flow Diagrams
    • Security
      • Information security concepts
      • Access Control Lists (ACLs)
      • Access Control Models
      • .NET Cryptography Model
      • ASP.NET Identity
      • OWASP Top 10
      • Cross-Site Request Forgery (XSRF)
      • Protecting against cross-site scripting attacks (XSS)
      • Protecting against buffer overrun attacks
      • Protecting against SQL-injection attacks
      • CSRF/XSRF protection
    • Algorithms
      • Algorithms complexity (understanding, big O notation, complexity of common algorithms)
      • Array sorting methods (bubble sort, quick sort, merge sort)
      • Tree structure (construction, traversal)
      • Binary search algorithm
      • Hash table (creating, collisions)
      • Stack, queue, linked list (construction, understanding, usage)
  • Construction Core
    • Programming language
      • Declare namespaces, classes, interfaces, static and instance class members
      • Types casting
      • Value and reference types. Class vs Struct usage.
      • Properties and automatic properties
      • Structured Exception Handling, Exception filters
      • Collections and Generics
      • Dictionaries. Comparison of Dictionaries
      • Building enumerable types
      • Building cloneable objects
      • Building comparable types
      • Nullable types
      • Delegates, events and lambdas
      • Indexers and operator overloading
      • Anonymous types
      • Extension methods. Practices.
      • Custom Type Conversions (implicit/explicit keywords)
      • Strings and StringBuilder. String concatenation practices. String Interpolation
      • Serialization
      • System.IO namespace
      • LINQ to Objects
      • General Coding conventions for C#
      • Static Using Statement
      • Type Reflection
      • Custom attributes
      • Dispose and Finalizable patterns
      • Garbage collection
      • .Net Diagnostics
      • Implementing logging
      • Exception handling guidelines
      • Regular Expressions
      • Span<T> struct
      • C# - What's new?
      • .NET Standard overview
    • Concurrency
      • Understand differences between Concurrency vs Multi-threading vs Asynchronous
      • Concurrency: An Overview
      • Async basics
      • Task Parallelism
      • Basic Synchronization in C#
      • Deadlock problem
      • QueueBackgroundWorkItem or IHostedService for .NET Core
      • How to run Background Tasks in ASP.NET
    • Refactoring
      • Refactoring Concept (what/when/why)
      • Smells Catalog and possible re-factorings
      • Moving Features Between Objects (basic)
      • Organizing Data (basic)
      • Composing Methods (basic)
      • Simplifying Conditional Expressions (basic)
      • Making Method Calls Simpler
      • Dealing with Generalization
    • Product deploying, software installation
      • Create, configure, and publish a web package (.NET Web Profile)
      • Publishing Web Services
      • Manage packages by using NuGet, NPM and Bower
    • Networking
      • Understanding networks: layers and protocols
      • Basic understanding of TCP/IP model and protocols
      • Defining internet, intranet and VPN
      • Basics of Firewalls and DMZ
      • Application layer protocols basics (HTTP, FTP, Telnet)
      • Understanding HTTP and WWW
      • Basic troubleshooting tools (ICMP, ping, traceroute)
      • Client/Server model
      • Sockets, IP and port addressing
      • Using proxy server
      • File transfer services: FTP, TFTP
      • Name resolution services: DNS, whois
      • Remote access services: Telnet, SSH, rdesktop, VNC
      • The basic difference between HTTP and HTTPS protocols
  • Construction Web
    • Web server applications
      • ASP.NET Core
        • Application startup
        • Middleware
        • Working with Static Files
        • Routing
        • Error Handling
        • Globalization and localization
        • Configuration
        • Logging
        • File Providers
        • Dependency Injection
        • Working with Multiple Environments
        • Hosting
        • Managing Application State
        • Request Features
      • ASP.NET Core MVC
        • MVC basics (Model, View, Controller, DI)
        • Model binding and validation
        • View (Razor compilation, Layout, Tag Helpers, Partial Views, DI, View components)
        • Controllers (Route to actions, File uploads)
      • Security and Identity (concepts understanding)
        • Authentication
        • Using identity
        • Authorization with roles
      • Bundle and Minify assets
      • Develop ASP.NET Core MVC apps
      • Advanced topics for ASP.NET Core MVC
        • Application model
        • Filters
        • Areas
        • Application Parts
        • Custom Model Building
        • IActionConstraint
      • Host and deploy ASP.NET Core
      • Migrate from ASP.NET to ASP.NET Core
      • Troubleshoot ASP.NET Core projects
      • Open Web Interface for .NET (OWIN)
      • Web server implementations in ASP.NET Core
    • Web Services
      • REST
      • ASP.NET Web API
        • Routing
        • Configuration
        • Basic error handling
      • Web API-based services
      • Web API Security
      • Token based security
      • SingalR
      • Serialization Frameworks
      • Implement caching
      • gRPC on ASP.NET Core
      • API versioning
      • API documentation
    • Microservices and Cloud
      • Microservices architecture
      • Dockerize a .NET Core application
      • Development workflow for Docker apps
    • JavaScript, HTML, CSS
      • JavaScript: Variables
      • JavaScript: Data types and types conversion
      • JavaScript: Operators
      • JavaScript: Control and Loop constructions
      • JavaScript: Functions, Execution Context and Variables scopes
      • JavaScript: Arrays
      • JavaScript: JS in WebBrowser and basic DOM manipulations
      • HTML: Basic elements
      • CSS: Simple Style rules
      • CSS: selectors
      • Box model
      • HTML: Standards and Browser compatibility
      • HTML: Page Layouts with divs
      • HTML: Frames
      • CSS: Elements positioning and layering
      • CSS: Tables properties
      • CSS: Flexbox
      • Different storage
      • JavaScript: Event Understanding (propagation, capturing, attach/detach)
      • JavaScript: Closure
      • AJAX/JSON
      • Ecma script 6: OOP
      • Promise
      • Strict mode of javascript
    • JavaScript Frameworks
      • Selecting elements
      • Operating on collection
      • Manipulating with elements, working with properties, attributes and data
      • Events
      • animation and effects
      • utilities and Ajax
      • SPA (SINGLE PAGE APPLICATIONS)
      • EcmaScript 6
      • UI frameworks basics:
      • NPM basics:
      • React basics
  • Construction DB
    • SQL
      • Tables, relationships, keys, constraints understanding
      • DDL, DML, DCL understanding
      • SQL data types
      • SQL operators, functions
      • Data manipulation (insert, update, delete)
      • Retrieving data (simple select statement)
      • Joins understanding
      • Creating, modifying, removing database objects
      • Aggregations (ORDER BY, GROUP BY, HAVING, SUM, COUNT, AVG, etc)
      • Combining the results of multiple queries (UNION, EXCEPT, INTERSECT, MINUS, subqueries)
      • Sessions, transactions, locks
      • Isolation levels understanding
      • Implementing stored procedures, user-defined functions, triggers
      • Cursors
    • Data Access Layer
      • Manage connection strings and objects
      • Working with data providers
      • Connect to a data source by using a generic data access interface
      • Handle and diagnose database connection exceptions
      • Manage exceptions when selecting, modifying data
      • Build command objects and query data from data sources
      • Retrieve data source by using the DataReader
      • Manage data by using the DataAdapter and TableAdapter
      • Updating data
      • Entity Framework
        • Query data sources by using EF
        • Code First to existing DB
        • Entity Data Modeling Fundamentals
        • Querying Data
        • Data modification
  • Verification
    • Code Quality
      • MSDN: Guidelines for Names
      • SDO Best Practices Catalog - Coding Standards
      • SDO Best Practices Catalog - Code Review Process
      • SDO Best Practices Catalog - Automatic Code Inspection
      • Automated coding standards enforcement (StyleCop, Resharper)
      • Code Reviews and Toolset
      • Use Work Items (TODO, BUG etc.)
      • Preemptive Error Detection
      • Desirable characteristics of a design (minimal complexity, ease of maintenance, minimal connectednes
      • Creating high quality classes
      • Creating high quality methods
      • Guidelines for initializing variables
      • Exceptions and error handling techniques
      • Best practices of working with data types
      • Code commenting practices
    • Automated Testing (principles, patterns, and practices)
      • Software testing basic concepts
      • Software testing concept
      • Test Case
      • Test Suite
      • Test Plan
      • Testing Levels
      • Naming standards for unit tests
      • Types of test doubles (Stub, Mock, Spy, Fake, Dummy)
      • Basic coverage criteria
      • Testing concepts (Unit vs Functional vs Integration)
      • Goals of Unit Testing, What Makes a Test Valuable?
      • Styles of Unit Testing (Output / State / Collaboration)
      • Good unit test properties
      • F.I.R.S.T Principles of unit testing
      • Test Pyramid concept
      • Testing Pyramid, Agile Testing Pyramid, Diamond
      • Breaking the dependency, Interaction testing
      • Strategies for isolating the database in tests
      • Test smells and how to avoid
      • Test Organization patterns
      • Fixture setup patterns
      • Test double patterns
      • Feature-driven development (FDD)
      • Behavior-driven development (BDD)
      • Test-driven development (TDD)
      • Acceptance testing, Acceptance Test Driven Development (ATDD)
      • Continuous testing
    • Automated Testing (Frameworks, Tools, Libraries)
      • .NET unit test frameworks overview
      • .NET Mocking Frameworks, a comparison
      • xUnit
        • Primary test framework attributes
        • Asserts
        • Exception Handling in Unit Tests
        • Skipping Tests
        • Initialization and Cleanup (Assembly, Class, Test)
        • Data-driven Tests
      • NSubstitute
        • Mocking Method Calls (Using Mock Object, Return Values, Argument Matching)
        • Behavior Verification (Method Was/Not Called, a Specific Number of Times, Getter/Setter Was Called)
        • Throwing exceptions
        • Raising Events from Mock Objects
        • Returning Different Results for Sequential Calls
      • AutoFixture
      • EF Core InMemory test
      • Integration tests in ASP.NET Core
      • Isolating database data in integration tests
      • Test ASP.NET Core MVC apps
  • Configuration Management
    • Product builds and Continuous Integration
      • Automated build concept
      • Dotnet cli
      • CI/CD Basic concepts
    • Managing Versions
      • Fundamental concepts: revisions, working copy, repository, branch, baseline, trunk
      • Versioning Models
      • Distributed Version Control basics
      • Distributed systems advantages and weak sides
      • VCS Management life-cycle on (one of) major tools (clone, commit, update, revert, merge, resolve, et
      • Branching/Merging strategies
      • Blaming (annotate)
      • Revision graph/log actions (Git)
      • Integrating with Issue Tracking Systems
      • Source control Best Practices
Powered by GitBook
On this page
  • Decorator (Wrapper)
  • Composite
  • Bridge (Handle/Body)
  • Proxy
  • Fasade
  • Adapter
  • Flyweight
  1. Design
  2. OOD
  3. Design Patterns

Structural patterns

PreviousDesign PatternsNextCreational patterns

Last updated 5 years ago

Decorator (Wrapper)

Allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class. It is a flexible alternative of subclasses creation practice for functionality extension. Object "doesn't" know that it was "decorated", so this pattern is perfect for expansion of software systems.

The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern.

When should be used:

  • objectives and behavior of objects should be added dynamically;

  • concrete implementation should be separated from duties and behaviors;

  • objects' extension for the creation of subclasses is impractical or impossible;

  • specific functions should not be on the upper levels of the object hierarchy;

  • some functionality isn't applicable for all objects and can't be removed if necessary;

  • a large number of small objects that have similar implementations aren't permissible.

Component – a class that defines an interface for objects that can be dynamically assigned additional duties, as well as for future decorators;

ConcreteComponent – defines an object to which new states and behavior are added;

Decorator – contains a reference to the component object and inherits its interface implementation by default.

ConcreteDecorator (ConcreteDecoratorA, ConcreteDecoratorB) – concrete decorators.

Composite

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

When should be used:

  • у наявності є оригінальна структура, що складається з об’єктів та композицій об’єктів;

  • необхідно забезпечити ігнорування клієнтом істотних відмінностей між окремим об’єктом та складеним об’єктом;

  • необхідно реалізувати уніфіковану обробку всіх об’єктів.

Але також можна розглядати і такі варіанти:

  • шаблон «Декоратор», який містить операції типу Додати (Add), Видалити (Remove) та Знайти (Find)

  • шаблон «Пристосуванець» для розділення компонентів за умови, що характеристика «місцезнаходження» може бути проігнорована і всі операції будуть починатися з кореневої вершини композиції об’єктів

  • шаблон «Відвідувач» для локалізації операцій, які на даний момент розподілені між класами Composite та Component

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

Leaf – компонент без реалізації контейнерних функцій. Визначає листові вершини та не має нащадків. Визначає поведінку примітивних об’єктів у композиції; входить до складу контейнерів;

Composite – складений об’єкт. Визначає поведінку контейнерних об’єктів, у яких є нащадки. Зберігає ієрархію компонентів-нащадків; реалізує операцій, які відносяться до інтерфейсу управління нащадками.

Bridge (Handle/Body)

Дозволяє розділяти абстракцію і реалізацію таким чином, щоб вони могли змінюватися незалежно. Шаблон bridge використовує інкапсуляцію, агрегування та успадкування для того, щоб розділити відповідальність між класами.

When should be used:

  • потрібно уникнути постійної прив'язки абстракції до реалізації / абстракція та реалізація не повинні бути зв’язаними під час компіляції;

  • конкретну реалізацію необхідно вибирати під час виконання програми;

  • абстракція та реалізація повинні бути незалежно розширюваними новими підкласами. У такому випадку «Міст» дозволяє комбінувати різні абстракції та реалізації та змінювати їх незалежно;

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

  • деталі реалізації повинні бути прихованими від клієнта;

  • кількість класів швидко зростає, що є ознакою того, що ієрархію потрібно розділити на 2 частини.

Abstraction визначає інтерфейс абстракції і агрегує (зберігає посилання) на об'єкт типу Implementor;

Refined Abstraction (опціонально) - це більш специфічний підклас основної абстракції, який розширює інтерфейс, визначений нею;

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

ConcreteImplementor - один з конкретних (платформо-залежних) виконавців.

Proxy

забезпечує створення заступника об’єкта для контролю доступу до останнього через перехоплення всіх викликів.

Надає об’єкт-заступник (surrogate) або об’єкт-замінник (placeholder).

Обгортаючи доступ до реального компонента, «Заступник»зменшує складність роботи з ним.

When should be used:

  • створення об’єкту є “дорогою” операцією – можна створювати об’єкт тільки при першому зверненні до нього;

  • потрібно контролювати доступ до об’єкту: для різних об’єктів можна встановлювати різні рівні доступу;

  • потрібно організувати віддалений функціонал – заступник надає локального представника замість цільового об’єкта, що знаходиться в іншому адресному просторі;

  • потрібно виконувати додаткові дії при доступі до об'єкта – «розумне посилання».

Види шаблону:

  • віртуальний заступник: управляє створенням одного об’єкта через інший тоді, коли цей об’єкт реально потрібний (доцільно у випадках, якщо процес створення досить повільний або може бути визнаним непотрібним). Має назву ще lazy loading, on-demand loading, just-in-time loading. Може кешувати частину інформації про реальний Суб’єкт, щоб відкласти його створення;

  • заступник для аутентифікації (заступник-захисник): перевіряє правильність умов доступу до об’єкту;

  • віддалений заступник: забезпечує зв’язок з Суб’єктом, який знаходиться у іншому адресному просторі (домені застосунку, процесі чи комп’ютері); кодує/декодує повідомлення, які надсилаються мережею;

  • розумний заступник: додає щось до запиту перед його надсиланням до мережі або змінює запит;

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

Proxy :

  • зберігає посилання, яке дозволяє йому звертатися до реального суб'єкту, використовуючи інтерфейс класу Subject;

  • надає інтерфейс, ідентичний інтерфейсу Subject, тому заступник завжди може бути підставлений замість реального суб'єкта;

  • контролює доступ до реального суб'єкту і може відповідати за його створення і видалення;

  • виконує інші обов'язки, які залежать від виду заступника (remote proxies, virtual proxies, protection proxies etc.);

Subject – визначає спільний для RealSubject і Proxy інтерфейс, так що клас Proxy можна використовувати скрізь, де очікується RealSubject;

RealSubject – визначає реальний об'єкт, який подається за допомогою заступника.

Fasade

структурує об’єкти, надаючи до них всіх доступ через єдиний шлюз. Надає єдиний, уніфікований інтерфейс до всієї підсистеми замість набору окремих та багаточисельних інтерфейсів. Фактично, “Фасад” визначає інтерфейс більш високого рівня, який спрощує використання системи.

When should be used:

  • є необхідність у наданні простого інтерфейсу доступу до складної системи;

  • між клієнтами та класами реалізації абстракції існує багато залежностей і треба зменшити їхню кількість;

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

Facade – фасад:

  • проінформований про те, яким складовим системи потрібно переадресовувати запит;

  • делегує запити клієнтів відповідним об’єктам всередині підсистеми;

Класи підсистеми:

  • реалізують функціональність підсистеми;

  • виконують дії, які потребує «Фасад» і які, в свою чергу, «Фасад» отримав від одного з клієнтів;

  • нічого не “знають” про існування самого «Фасаду» (не зберігають посилань на нього);

  • реалізація компонентів підсистеми закрита та не видна зовнішнім компонентам.

Adapter

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

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

«Адаптер» – шаблон, що уніфікує класи та об’єкти.

When should be used:

  • існуючий клас підтримує необхідні дані і поведінку, але має інтерфейс, який не відповідає певним вимогам (наприклад, при використанні існуючої бібліотеки, до класів якої немає доступу);

  • необхідно створити повторно використовуваний клас, який повинен взаємодіяти із зазделегідь невідомими або непов’язаними з ним класами, які мають несумісні інтерфейси;

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

Target - цільовий інтерфейс. Визначає інтерфейс, який залежить від предметної області і яким користується Client;

Client - взаємодіє з об'єктами, що задовольняють інтерфейсу Target;

Adaptee - адаптований інтерфейс. Визначає існуючий інтерфейс класу (бібліотеки), який потребує адаптації;

Adapter - клас, що адаптує інтерфейс Adaptee до інтерфейсу Target.

Flyweight

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

When should be used:

  • у додатку використовується велика кількість подібних об'єктів, при цьому накладні витрати на їх зберігання є високими (може не вистачити пам’яті для їх одночасного розміщення в режимі runtime);

  • більшу частину станів об'єктів можна винести назовні (у зону відповідальності клієнтів, які створюють і використовують ці об'єкти);

  • багато нероздільних (unshared) об'єктів можна замінити невеликою кількістю поділюваних (shared) об'єктів, оскільки їх стан винесено назовні;

  • ідентичність кожного об’єкту не має значення.

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

ConcreteFlyweight реалізує інтерфейс Flyweight та додає при необхідності внутрішній стан. Об’єкт класу ConcreteFlyweight повинен бути розділюваним (shared). Будь-який збережуваний ним стан повинен бути внутрішнім, тобто таким, що не залежить від контексту;

UnsharedConcreteFlyweight – нерозділюваний (unshared) конкретний пристосуванець. Не всі підкласи Flyweight обов’язково повинні бути shared. Інтерфейс Flyweight допускає розділення, але не нав’язує його. Часто у об’єктів UnsharedConcreteFlyweight на деякому рівні структури пристосуванця є нащадки у вигляді об’єктів класу ConcreteFlyweight;

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

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