Add generic type parameter documentation to get_it

- Add explanation of generic type parameter to Accessing Services section
- Show how type inference works with inline code examples in Registering Concrete Classes vs Interfaces
- Add Switching Implementations subsection with conditional registration pattern
- Update testing.md with Pattern 2: Conditional Registration (Alternative)
- Rename Pattern 1 to "Scope-Based Testing"
- Add explanation about type-based shadowing in testing patterns

Author: escamoteur

docs/documentation/get_it/getting_started.md

@@ -90,6 +90,21 @@ get_it offers three main registration types:
 
 ---
 
+## Accessing Services
+
+The generic type parameter you provide when registering is that one that is used when you access an object after it is registered. **If you don't provide that, Dart will infer it from the implementation type:**
+
+Get your registered services using `getIt<Type>()`:
+
+
+<<< @/../code_samples/lib/get_it/accessing_services_example.dart#example
+
+::: tip Shorthand Syntax
+`getIt<Type>()` is shorthand for `getIt.get<Type>()`. Both work the same - use whichever you prefer!
+:::
+
+---
+
 ## Registering Concrete Classes vs Interfaces
 
 <strong>Most of the time, register your concrete classes directly:</strong>
@@ -114,18 +129,24 @@ This is simpler and makes IDE navigation to implementation easier.
   <li style="padding-left: 1.5em; text-indent: -1.5em;">❌️ Don't use "just because" - creates navigation friction in your IDE</li>
 </ul>
 
----
+```dart
+// Without type parameter - Dart infers StripePaymentProcessor
+getIt.registerSingleton(StripePaymentProcessor());
+getIt<PaymentProcessor>(); // ❌️ Error - not registered as PaymentProcessor
 
-## Accessing Services
+// With type parameter - explicitly register as PaymentProcessor
+getIt.registerSingleton<PaymentProcessor>(StripePaymentProcessor());
+getIt<PaymentProcessor>(); // ✅ Works - registered as PaymentProcessor
+```
 
-Get your registered services using `getIt<Type>()`:
+### Switching Implementations
 
+A common pattern is switching between real and mock implementations using conditional registration:
 
-<<< @/../code_samples/lib/get_it/code_sample_908a2d50.dart#example
 
-::: tip Shorthand Syntax
-`getIt<Type>()` is shorthand for `getIt.get<Type>()`. Both work the same - use whichever you prefer!
-:::
+<<< @/../code_samples/lib/get_it/conditional_registration_example.dart#example
+
+Because both implementations are registered as `<PaymentProcessor>`, the rest of your code remains unchanged - it always requests `getIt<PaymentProcessor>()` regardless of which implementation is registered.
 
 ---
 

docs/documentation/get_it/testing.md

@@ -23,14 +23,27 @@ Testing code that uses get_it requires different approaches depending on whether
 
 ## Unit Testing Patterns
 
-### Pattern 1: Scoped Test Doubles (Recommended)
+### Pattern 1: Scope-Based Testing (Recommended)
 
-Use scopes to inject mocks for specific services while keeping the rest of your dependency graph intact.
+Use scopes to inject mocks for specific services while keeping the rest of your dependency graph intact. Registering a different implementation in a scope works the same way - using the generic type parameter to shadow the original registration.
 
 
 <<< @/../code_samples/lib/get_it/main_example_2.dart#example
 
-### Pattern 2: Constructor Injection for Pure Unit Tests
+### Pattern 2: Conditional Registration (Alternative)
+
+Instead of using scopes, you can switch implementations at registration time using a flag:
+
+
+<<< @/../code_samples/lib/get_it/conditional_registration_example.dart#example
+
+This approach is simpler but less flexible than scopes - you must decide which implementation to use before registration, and can't easily switch during runtime.
+
+::: tip Type-Based Shadowing
+When you register `MockPaymentProcessor` as `<PaymentProcessor>`, get_it uses the **type parameter** as the lookup key, not the concrete class. This is what enables switching implementations—the same key retrieves different objects in different contexts.
+:::
+
+### Pattern 3: Constructor Injection for Pure Unit Tests
 
 For testing classes in complete isolation (without get_it), use optional constructor parameters.