Nlelouche Unity3d Antigravityskills Oop Patterns Architect

name: oop-patterns-architect description: "Object-Oriented design patterns specialist for clean, maintainable Unity architectures." version: 2.0.0 tags: ["architecture", "OOP", "SOLID", "patterns", "clean-code"] argument-hint: "pattern='Repository' OR principle='SRP'" disable-model-invocation: false user-invocable: true allowed-tools: - run_command - list_dir - write_to_file requirements: unity_version: ">=6.0" render_pipeline: "Any" dependencies: [] context_discovery: check_unity_version: true check_render_pipeline: false scan_manifest_for: [] performance_budget: gc_alloc_per_frame: "0 bytes target in hot paths" max_update_cost: "O(n) - profiler-guided" tdd_first: true # ⚠️ Updated by audit v2.0.1 - needs manual test implementation

OOP Patterns Architect

Overview

Object-Oriented Programming patterns for Unity. Apply SOLID principles, clean architecture, and domain-driven design for maintainable codebases.

When to Use

• Use when designing class hierarchies
• Use when applying SOLID principles
• Use when code smells appear
• Use when building domain models
• Use when refactoring legacy code

SOLID Principles

Architecture Layers

┌─────────────────────────────────────────────────────────────┐
│                    PRESENTATION                             │
│              (UI, Input, Controllers)                       │
├─────────────────────────────────────────────────────────────┤
│                    APPLICATION                              │
│              (Use Cases, Services)                          │
├─────────────────────────────────────────────────────────────┤
│                      DOMAIN                                 │
│              (Entities, Value Objects)                      │
├─────────────────────────────────────────────────────────────┤
│                   INFRASTRUCTURE                            │
│              (Repositories, External APIs)                  │
└─────────────────────────────────────────────────────────────┘
              Dependencies flow DOWN only

Common Patterns

Best Practices

• ✅ Prefer composition over inheritance
• ✅ Keep classes small and focused
• ✅ Use interfaces for dependencies
• ✅ Separate data from behavior when appropriate
• ✅ Make illegal states unrepresentable
• ❌ NEVER inherit more than 2 levels deep
• ❌ NEVER use inheritance for code reuse alone
• ❌ NEVER expose internal state (encapsulation)

Few-Shot Examples

Example 1: SRP Violation Fix

User: "This class does too much."

Agent:

// BEFORE: Violates SRP
public class Player : MonoBehaviour
{
    void Move() { }
    void Attack() { }
    void SaveGame() { }  // ❌ Not player's job
    void RenderUI() { }  // ❌ Not player's job
}

// AFTER: Single responsibility
public class Player : MonoBehaviour
{
    void Move() { }
    void Attack() { }
}
// SaveManager handles saving
// UIManager handles rendering

Example 2: Repository Pattern

User: "Abstract database access."

Agent:

public interface IPlayerRepository
{
    Player GetById(string id);
    void Save(Player player);
    IEnumerable<Player> GetAll();
}

public class LocalPlayerRepository : IPlayerRepository
{
    public Player GetById(string id) => LoadFromFile(id);
    public void Save(Player player) => SaveToFile(player);
    // ...
}

public class CloudPlayerRepository : IPlayerRepository
{
    public Player GetById(string id) => FetchFromServer(id);
    // ...
}

Example 3: Value Object

User: "Create immutable currency."

Agent:

public readonly struct Currency
{
    public int Gold { get; }
    public int Gems { get; }
    
    public Currency(int gold, int gems)
    {
        Gold = gold;
        Gems = gems;
    }
    
    public Currency Add(Currency other) =>
        new Currency(Gold + other.Gold, Gems + other.Gems);
    
    public static Currency operator +(Currency a, Currency b) =>
        a.Add(b);
}

Code Smells to Avoid

• God Object: Class that knows/does everything
• Feature Envy: Method uses other class's data too much
• Primitive Obsession: Using primitives instead of types
• Long Parameter List: > 3-4 parameters

TDD Contract

⚠️ Legacy Skill — Refactor Pending Este skill NO tiene tests automatizados aún. El siguiente boilerplate es un punto de partida.

// Escribe estos tests ANTES de implementar:

// Test 1: should [expected behavior] when [condition]
[Test]
public void OopPatternsArchitect_Should{ExpectedBehavior}_When{Condition}()
{{
    // Arrange
    // TODO: Setup test fixtures
    
    // Act
    // TODO: Execute system under test
    
    // Assert
    Assert.Fail("Not implemented — write test first");
}}

// Test 2: should handle [edge case]
[Test]
public void OopPatternsArchitect_ShouldHandle{EdgeCase}()
{{
    // Arrange
    // TODO: Setup edge case scenario
    
    // Act
    // TODO: Execute
    
    // Assert
    Assert.Fail("Not implemented");
}}

// Test 3: should throw when [invalid input]
[Test]
public void OopPatternsArchitect_ShouldThrow_When{InvalidInput}()
{{
    // Arrange
    var invalidInput = default;
    
    // Act & Assert
    Assert.Throws<Exception>(() => {{ /* execute */ }});
}}

Pasos para completar el TDD:

1. Descomenta los tests above
2. Implementa la funcionalidad mínima para que compile
3. Ejecuta los tests — deben fallar (RED)
4. Implementa la funcionalidad real
5. Verifica que los tests pasen (GREEN)
6. Refactorea manteniendo los tests verdes

Nota: Este skill fue marcado como tdd_first: false durante la auditoría v2.0.1. La sección TDD fue agregada automáticamente pero requiere customización manual para reflejar el comportamiento real del skill.

Related Skills

• @di-container-manager - Dependency injection
• @interface-driven-development - Interface design
• @advanced-design-patterns - GoF patterns

Converted and distributed by TomeVault — claim your Tome and manage your conversions.