Spring Autowired Best Practices: Avoid Blindly Using @Autowired

🚀 #100DaysOfCode – Day 12 | Backend Journey Continues 💻🔥 Consistency is starting to feel powerful now. Day 12 done ✅ 🧠 LeetCode Daily Challenge 📌 Problem: Maximum Walls Destroyed by Robots 💡 Approach & Learnings: Today’s problem was a mix of Sorting + Binary Search + Dynamic Programming, which made it super interesting. 🔹 Sorted robots and walls to process efficiently 🔹 Used Binary Search to quickly count walls in a given range 🔹 Applied Dynamic Programming to maximize total walls destroyed 👉 The key challenge was handling overlapping ranges between robots and deciding the optimal strategy to avoid double counting. This problem really tested how well I can combine multiple concepts into one optimized solution. Submission Link: https://lnkd.in/gp99D5sS 🌱 Spring Boot Learning Today I focused on some very important backend concepts: 🔹 PUT vs PATCH Mapping 👉 PUT Mapping Used when updating the entire object Missing fields → become NULL Best for full replacement 👉 PATCH Mapping Used for partial updates Only updates required fields Avoids unnecessary null values 🔹 ReflectionUtils in PATCH Learned how to use Reflection to dynamically update fields inside an entity. 💡 This helps in: Updating fields without writing multiple setters Making PATCH APIs more flexible Writing cleaner and scalable backend code 🔹 ResponseEntity Understood how to structure API responses properly: ✅ Control HTTP status codes ✅ Customize response body ✅ Improve API clarity and standards 📈 Key Takeaways ✔️ Combining multiple DSA concepts is key for optimization ✔️ PATCH is essential for real-world API design ✔️ Reflection adds flexibility to backend logic ✔️ Clean API responses improve overall system design NotesLink: https://lnkd.in/gNZWz96m 🔥 Day 12 done. Still consistent. Still improving. #BackendDevelopment #SpringBoot #Java #LeetCode #100DaysOfCode #CodingJourney

Are you still using @Autowired on private fields? It might be time to refactor. 🛑 While Field Injection is short and easy to write, it hides dependencies and makes your code harder to maintain. As your application grows, Constructor Injection becomes the superior choice. Why the shift? ✅ Immutability: You can define your dependencies as final, ensuring they aren't changed after initialization. ✅ Testability: No need for Reflection or Mockito's @InjectMocks magic just to run a simple Unit Test. You can just pass mocks through the constructor. ✅ Object Integrity: It prevents the "NullPointerException" trap. Your object is never in an inconsistent state; it either has all its dependencies or it doesn't compile. Tip: If your constructor has more than 5 dependencies, it's a "Code Smell." It’s telling you that your class is doing too much and needs to be split (SRP violation). Do you use @Autowired for speed, or do you stick to Constructor Injection for safety? Let's debate! 👇 #Java #SpringBoot #CleanCode #SoftwareArchitecture #Testing #BackendDevelopment #CodingTips

⚙️ @Autowired vs Constructor Injection — Which One Should You Use? Most beginners use @Autowired everywhere… But in real-world projects, that’s not the best practice. Let’s understand 👇 👉 @Autowired (Field Injection) @Autowired private UserService userService; ✔ Easy to write ❌ Hard to test ❌ Not recommended for production 👉 Constructor Injection (Recommended) private final UserService userService; public UserController(UserService userService) { this.userService = userService; } ✔ Better testability ✔ Immutability (final fields) ✔ Recommended by Spring 💡 Why Constructor Injection is better: Dependencies are explicit Easier for unit testing Prevents null issues 🚀 In my Spring Boot project, I switched to constructor injection and it made my code cleaner & more maintainable. 🧠 Key Insight: Good code is not just working code — it’s maintainable code. Which one are you using in your projects? #Java #SpringBoot #CleanCode #BackendDevelopment #FullStackDeveloper

“Understanding definition ≠ ability to implement cleanly in real code.” This line hit me hard today. We often feel confident after: ✔️ Reading docs ✔️ Watching tutorials ✔️ Understanding concepts But the real test begins when you **write actual code**. 🔍 What I realized I knew `Optional`, `map`, `flatMap` — conceptually clear. But during a simple login implementation: → Fetch user → Extract email I ended up with: ```java Optional<Optional<String>> ``` That moment exposed the gap: 👉 I understood the *definition* 👉 But not the *application* --- ### ⚠️ The Hidden Trap ```java findUserById(id) .map(user -> Optional.ofNullable(user.getEmail())) ``` This creates nesting. Code works… but design becomes messy. ✅ The Clean Way ```java findUserById(id) .flatMap(user -> Optional.ofNullable(user.getEmail())) ``` Now it’s: ✔️ Clean ✔️ Composable ✔️ Readable 🧠 The Real Learning Concepts are just the starting point. Real growth happens when: * You hit confusion * You debug deeply * You refine your thinking 🚀 Takeaway Don’t stop at *“I understand this”* Push until you can say: 👉 *“I can apply this cleanly in production code.”* Because in engineering: Clarity in thinking → Simplicity in code #Java #SpringBoot #CleanCode #BackendDevelopment #LearningJourney

I open-sourced 𝗱𝗲𝗰𝗸 — think docker-compose, but for your whole local dev stack, not just containers. It started as a Makefile + shell scripts I built for onboarding a Go+React monorepo — postgres, keypair generation, DB setup, migrations, services with log tailing and cleanup. One command to start everything. Worked well, totally hardcoded to one project. I looked at the result and thought: this should be a real tool. 𝗱𝗲𝗰𝗸 𝘂𝗽 — one YAML config, one command: • Deps with multi-strategy fallback (docker → brew → whatever) • Idempotent bootstrap with interactive prompts for first-time setup • Service dependencies with readiness checks (depends_on + ready) • Env vars from strings, shell scripts, or structured files (JSON/YAML/TOML/INI) • Colored log tailing, crash recovery with auto-restart • deck.local.yaml for personal overrides — you use docker, I use brew Also: deck doctor to diagnose your stack, deck run api -- goose up for one-off commands in a service's context, selective targeting (deck up api webapp), and stack-aware deck init that detects your project type. Single Go binary, ~2500 LOC, 7 releases. Available via Homebrew. Built with Claude Code handling implementation and Codex running execution and review passes on chunks of work. I focused on design and architecture. Honest take: the velocity is wild, but you still need to know what you're building and catch what it gets wrong. Named after the cyberdeck from Shadowrun 🤖 https://lnkd.in/dRhUvhg3

6 Pillars of code quality I’ve recently been reading 'Good Code, Bad Code' by Manning, and the section on the 6 Pillars of Code Quality really resonated with me. I figured it would be a great idea to summarize my takeaways in this blog post. To make things more practical, I’ve included code examples in .NET (C#), Spring, and Go based on my own understanding of these concepts....

The most common Spring Boot annotation you should probably stop using. Early in my career, I put @Autowired on every private field I could find. It was like magic. I needed a Service? Just add @Autowired and Spring injected it instantly. @Service public class OrderService { @Autowired private PaymentService paymentService; @Autowired private InventoryService inventoryService; } It feels productive. But after nearly a decade of debugging Spring applications, I’ve realized that Field Injection is a silent architecture killer. The Trap: 1. Unit Testing is a nightmare: You can't instantiate the class without firing up the entire Spring Context or heavily relying on reflection frameworks like Mockito to force mocks into private fields. 2. Hidden God Classes: When adding a dependency is just one line of code, it’s too easy to inject 15 different services into one class. It hides violations of the Single Responsibility Principle. 3. Null Pointer Exceptions: Field injected dependencies are not guaranteed to be initialized when the object is created. The Senior Fix: Constructor Injection. Stop using @Autowired on fields. Inject via the constructor instead. @Service public class OrderService { private final PaymentService paymentService; private final InventoryService inventoryService; // Spring 4.3+ automatically injects this! No @Autowired needed. public OrderService(PaymentService paymentService, InventoryService inventoryService) { this.paymentService = paymentService; this.inventoryService = inventoryService; } } Why is this the gold standard? • Immutability: You can make your fields final. Once the service is created, its dependencies can never be swapped out at runtime. • Bulletproof Testing: You can write lightning-fast unit tests using the new keyword. No Spring context required. • Design Pressure: If your constructor suddenly needs 10 parameters, it becomes painfully obvious that your class is doing too much. We threw out Lombok’s @Data to protect our entities. It’s time to throw out Field Injection to protect our architecture. Are you enforcing Constructor Injection in your code reviews yet, or is field injection still sneaking in? 👇 #Java #SpringBoot #CleanCode #BackendDevelopment #SoftwareEngineering #Microservices #TechTips #LogicLedaMagic

🚨 Today wasn’t about solving problems… it was about fixing what was broken. Day 37 of my Backend Developer Journey — and honestly, 👉 this felt more like a real developer day 🧠 LeetCode Breakthrough Solved today’s Daily Challenge using Median + Math Optimization 💡 What clicked: → Flatten the grid into a single array → Check if all elements follow same modulo → Use median to minimize operations ⚡ The Real Trick 👉 If modulo condition fails → impossible ❌ 👉 If valid → median gives minimum operations ✅ 🔍 Key Insight 👉 Median minimizes absolute differences 👉 Math-based optimization beats brute force 🔗 My Submission: https://lnkd.in/gf43YBkq ☕ Spring Boot Learning 🐛 Debugging Day (Real Dev Life) Today was not smooth… and that’s okay 👇 👉 Faced issues with Lombok + Java 24 👉 Switched back to Java 21 👉 Bugs reduced, but still debugging ⚡ What I learned 👉 New versions ≠ always stable 👉 Compatibility matters more than hype 👉 Debugging is a core developer skill 🔌 Database Progress 👉 Successfully connected PostgreSQL to my server 👉 Backend is now interacting with real data 🧠 The Shift 👉 Not every day is productive — but every day teaches 👉 Debugging builds deeper understanding than coding 👉 Real growth happens when things don’t work 🔗 GitHub Repo (Lovable Clone): https://lnkd.in/gwHmAZaK 📈 Day 37 Progress: ✅ Learned median optimization technique ✅ Handled real-world debugging issues ✅ Connected DB to backend successfully 💬 What’s one bug that taught you more than any tutorial? 👇 #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #Debugging #CodingJourney

Day 94/100 – #100DaysOfLeetCode 🚀 🧩 Problem: LeetCode 155 – Min Stack(Medium) 🧠 Approach: Use an additional stack to keep track of the minimum element at each step. While pushing, store the current minimum; while popping, update the minimum accordingly. 💻 Solution: class MinStack:   def __init__(self):     self.stack = []     self.min_stack = []   def push(self, val: int) -> None:     self.stack.append(val)     if not self.min_stack or val <= self.min_stack[-1]:       self.min_stack.append(val)   def pop(self) -> None:     if self.stack:       val = self.stack.pop()       if val == self.min_stack[-1]:         self.min_stack.pop()   def top(self) -> int:     return self.stack[-1] if self.stack else None   def getMin(self) -> int:     return self.min_stack[-1] if self.min_stack else None ⏱ Time | Space: O(1) | O(n) 📌 Key Takeaway: Maintaining an auxiliary stack helps achieve constant-time retrieval of the minimum element. #leetcode #dsa #development #problemSolving #CodingChallenge