Design Patterns (GoF)
Padroes de projeto mais cobrados em entrevistas .NET — Strategy, Observer, Factory, Decorator e Repository
Os Design Patterns do Gang of Four (GoF) sao solucoes reutilizaveis para problemas recorrentes em design orientado a objetos. Em entrevistas .NET, os mais cobrados sao Strategy, Observer, Factory Method, Decorator e Repository. Conhecer onde o proprio framework usa esses padroes e um diferencial.
Categorias de Design Patterns
Os 23 padroes GoF sao divididos em tres categorias. Em entrevistas .NET, os mais relevantes estao destacados abaixo.
| Categoria | Objetivo | Padroes mais cobrados | Uso no .NET |
|---|---|---|---|
| Creational | Controlar como objetos sao criados | Factory Method, Abstract Factory, Singleton, Builder | IServiceCollection, HttpClientFactory |
| Structural | Compor objetos em estruturas maiores | Decorator, Adapter, Facade, Proxy | Middleware pipeline, Stream wrappers |
| Behavioral | Definir como objetos interagem | Strategy, Observer, Chain of Responsibility, Template Method | DI + interfaces, event, middleware chain |
Padroes no ecossistema .NET
| Pattern | Onde aparece no .NET | Exemplo concreto |
|---|---|---|
| Strategy | Dependency Injection | ILogger, IAuthorizationHandler |
| Observer | Events, Rx, IObservable | event EventHandler, IObservable<T> |
| Factory Method | IHttpClientFactory | CreateClient("name") |
| Abstract Factory | IServiceScopeFactory | CreateScope() |
| Decorator | Middleware, Stream | BufferedStream(new FileStream(...)) |
| Chain of Resp. | Middleware pipeline | app.UseAuthentication().UseAuthorization() |
| Repository | Data access layer | DbContext como Unit of Work |
| Builder | Host/App configuration | WebApplication.CreateBuilder() |
| Singleton | DI container | services.AddSingleton<T>() |
| Template Method | Base classes | ControllerBase, BackgroundService |
Qual a diferenca entre um Design Pattern e um princípio SOLID?
Principios SOLID sao diretrizes gerais de design (ex: Dependency Inversion). Design Patterns sao solucoes concretas e nomeadas para problemas especificos (ex: Strategy implementa o principio Open/Closed). Patterns aplicam principios — nao sao a mesma coisa.
Quando NAO usar um Design Pattern?
Quando a complexidade adicionada nao se justifica. Um pattern existe para resolver um problema recorrente. Se o problema e simples ou nao vai mudar, aplicar um pattern e over-engineering. Siga YAGNI (You Aren't Gonna Need It).