Moving from OOP to Go: Understanding Structs and Interfaces

🛑 Confession: My first week with Go was a "Mindset Crisis" Coming from a heavy OOP languages background, my first encounter with Go (Golang) felt less like learning a new language and more like unlearning my entire career. I spent hours looking for class definitions. I kept trying to find where to type implements. I felt lost without my deep inheritance trees. I’ll be honest: it was frustrating. I felt like Go was "missing" something. After struggling to force OOP patterns into Go, here is how I had to re-map my OOP brain to survive in the Go world: 1️⃣ The "Capitalization" Revelation (Encapsulation) Do not look for public and private keywords. Go uses Capitalization. Upper Case = Public. lower Case = Private. 2️⃣ Long Live "has-a" (Inheritance) Go forced us to use Struct Embedding. Instead of a complex inheritance chain (A "is-a" B), Go encourages Composition over Inheritance (A "has-a" B) in its purest form. It stops your code from becoming a tangled web of parent-child dependencies. 3️⃣ Polymorphism This was the hardest to grasp. In Go, there’s no "implements" keyword. If your struct has the right methods, it IS an implementation. This "implicit" nature (Duck Typing) makes your code incredibly decoupled. 4️⃣ Abstraction as a Tool, Not a Burden By using Interfaces to define behavior rather than identity, I found I could swap out entire database layers or logic blocks without breaking a single line of consuming code. 💡 The Reality Check Go has its own "Zen." It values simplicity over hierarchy and clarity over cleverness. Is it easy? No. Not because the syntax is hard, but because the mindset shift is massive. It takes consistent practice and a lot of "failed" attempts to stop writing Java-style code in Go. But once you embrace the Go way, you realize that minimalism is actually a superpower for building scalable, maintainable backend systems. 🔗 Check my article for more detail: https://lnkd.in/gzBFzdiR #Golang #BackendEngineering #SoftwareDevelopment #OOP #LearningCurve

🚦🧊 JAVA IMMUTABILITY: THE WORDS MOST DEVS MIX UP: Unmodifiable, Immutable, Shallowly/ Deeply immutable, final 🔸 TL;DR In Java, unmodifiable does not mean immutable. And final does not mean the object can’t change either. If you confuse terms like mutable, unmodifiable view, immutable, shallowly immutable, and deeply immutable, you can easily design APIs that look safe but still leak state and bugs. 👉 I put together a carousel cheat sheet to make this crystal clear. Swipe through it. 🔸 TAKEAWAYS ▪️ Mutable = state can change after creation ▪️ Unmodifiable = this reference blocks mutation, but backing data may still change ▪️ Immutable = state cannot change after construction ▪️ Shallowly immutable = outer object is fixed, inner objects may still mutate ▪️ Deeply immutable = the full reachable state is frozen ▪️ Collections.unmodifiableList(...) is not the same as List.copyOf(...) ▪️ final freezes the reference, not the object ▪️ Records are concise, but they are not automatically deeply immutable 🔸 WHY IT MATTERS A lot of Java codebases say “immutable” when they really mean “harder to mutate accidentally.” That shortcut creates confusion in code reviews, APIs, concurrency discussions, and interviews. Precise vocabulary = better design. And better design = fewer side effects, safer models, cleaner code. ☕ 🔸 SWIPE THE CAROUSEL I turned the whole taxonomy into a simple PPT carousel with: ▪️ one term per slide ▪️ code snippets ▪️ short explanations ▪️ the distinctions that actually matter in real projects 👉 Swipe the carousel and tell me: Which term do you think developers misuse the most: unmodifiable or immutable? #Java #JavaProgramming #SoftwareEngineering #CleanCode #BackendDevelopment #Programming #Developers #Architecture #CodeQuality #JavaDeveloper #TechEducation #CodingTips

𝗧𝗵𝗲 𝗕𝗮𝘀𝗶𝗰𝘀 𝗼𝗳 𝗝𝗩𝗠 𝗮𝗻𝗱 𝗩𝟴 You want to know how Java and JavaScript work. Let's break it down. Programming languages are classified into two main types: statically typed and dynamically typed. - Statically typed languages check types before execution. - Dynamically typed languages determine types at runtime. There are also two main execution models: compiled and interpreted languages. - Compiled languages translate code into machine code before execution. - Interpreted languages execute code directly. But here's the thing: most languages use a hybrid approach. They combine compilation and interpretation to achieve better performance. This is where Just-In-Time (JIT) compilation comes in. It analyzes the code, identifies hot paths, and compiles them to machine code for better performance. The Java Virtual Machine (JVM) and V8 engine are two examples of this hybrid approach. - The JVM is a virtual machine that runs Java bytecode. - The V8 engine is a JavaScript engine that executes ECMAScript and WebAssembly specifications. So, what's the difference between JVM and V8? - The JVM is an abstract machine that runs bytecode, while V8 is a real implementation of the ECMAScript and WebAssembly specs. - The JVM has a public spec for its bytecode, while V8 does not. In the end, understanding how Java and JavaScript work can help you appreciate the complexity of programming languages. You can learn more about the JVM and V8 engine through the following resources: Source: https://lnkd.in/gi8Pne8w Optional learning community: https://lnkd.in/gmwngSRR

"async" is one of those concepts that looks similar across languages… until You look under the hood. Lately, I have been exploring how different languages handle async. At first glance, the answer seems simple: - Use async/await, threads, or some concurrency feature. But the deeper I go, the more I realise this: The syntax may look familiar, but the execution model underneath can be completely different. For example: - JavaScript uses an event loop with non-blocking I/O - Python uses asyncio for cooperative asynchronous programming - Java often relies on threads, executors, and reactive models - Go uses goroutines to make concurrency lightweight - C# provides a very mature Task-based async/await model All of them are trying to solve a similar problem: "How do we handle more work efficiently without blocking everything?" But the way they solve it changes a lot: - How does code feel to write - How systems scale - How errors behave - How debugging feels - How much complexity does the developer have to manage That is what makes backend engineering so interesting to me. Two languages can support “async,” but the model underneath can shape performance, scalability, developer experience, and even architecture decisions in very different ways. That is also why learning only syntax is never enough. - Knowing how to write async code is useful. - Knowing how it actually runs is what helps us design better systems. The more I learn, the more I feel this: "Good engineers do not stop at syntax." "They stay curious about the runtime model underneath." #SoftwareEngineering #AsyncProgramming #BackendDevelopment #Programming #SystemDesign #JavaScript #Python #Java #Go #CSharp

𝗞𝗼𝘁𝗹𝗶𝗻 makes functional programming feel natural—and 𝗦𝗔𝗠 is part of that story. If you’re coming from Java, 𝗦𝗔𝗠 (𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁 𝗠𝗲𝘁𝗵𝗼𝗱) interfaces might feel familiar. But in Kotlin, things get even cleaner with lambda expressions and SAM conversions. Dive into the 𝗯𝗹𝗼𝗴 𝗳𝗼𝗿 𝗱𝗲𝘁𝗮𝗶𝗹𝗲𝗱 𝗲𝘅𝗮𝗺𝗽𝗹𝗲𝘀 𝗮𝗻𝗱 𝗰𝗼𝗱𝗲 👇 https://lnkd.in/gbuNP_PM In this blog, I’ve explained: • What a SAM interface means in a Kotlin context • How Kotlin simplifies usage with lambdas • Interoperability with Java functional interfaces • Practical examples you can plug into your code The real win? Less boilerplate, more readable logic. If you're still writing verbose implementations where a lambda would do, you're missing Kotlin’s elegance.

New post is up: Testing in Functional Programming. Testing looks a bit different when immutability, pure functions, and explicit effects start shaping your code. In this article, I explore some of those differences and why they matter. You can read it here: https://lnkd.in/euMhsPTm How do you approach testing when working with functional ideas in Java or other languages?

You can write Java code for years… and still not understand OOP. Most developers know: ✔ classes ✔ inheritance ✔ polymorphism ✔ Encapsulation But struggle with: ❌ When to use composition over inheritance ❌ Why equals() & hashCode() break systems ❌ How poor design creates tight coupling ❌ What seniors actually mean by “good design.” After 2+ years in production, I realized this gap. So I stopped memorizing concepts… and started understanding how OOP works in real systems. I went deep, really deep, and created structured notes covering: 🔹 Objects & memory model (Heap vs Stack) 🔹 Constructors, chaining & object lifecycle 🔹 Encapsulation & controlled access 🔹 Inheritance vs Composition (real-world usage) 🔹 Polymorphism — what actually happens at runtime 🔹 Abstract class vs Interface — real design decisions 🔹 SOLID principles with practical scenarios 🔹 Immutability & thread safety 🔹 Inner classes & hidden memory leaks 🔹 Wrapper classes & Integer cache pitfalls 🔹 Enums as powerful classes (not just constants) 🔹 Dependency Injection — from scratch to Spring 🔹 Object class — equals(), hashCode(), clone() The biggest realization: OOP is not about syntax. It’s about designing systems that don’t break at scale. This is Part 02 of my Java Interview Prep series (Part 01 was JVM Internals - find the post link in comments ) If you're preparing for Java interviews, struggling with low-level design, or want to think like a senior engineer, this is for you. #Java #OOP #InterviewPrep #SoftwareEngineering #BackendDevelopment #JavaDeveloper #SystemDesign #LearningInPublic #SpringBoot #CleanCode

🚀 Constructor Chaining in Java – Clean Code Made Easy! Ever wondered how to avoid duplicate code in multiple constructors? 🤔 That’s where Constructor Chaining comes into play! 👉 What is Constructor Chaining? It’s a technique of calling one constructor from another constructor within the same class or from a parent class. --- 🔁 Types of Constructor Chaining: ✅ Using "this()" (Same Class) Calls another constructor in the same class. ✅ Using "super()" (Parent Class) Calls constructor of the parent class. --- ⚡ Why use it? ✔ Reduces code duplication ✔ Improves readability ✔ Makes code more maintainable ✔ Ensures proper initialization order --- ⚠️ Important Rules: 🔹 "this()" and "super()" must be the first statement 🔹 Cannot use both in the same constructor 🔹 Used in constructor overloading & inheritance --- 💡 Pro Tip: Constructor chaining ensures that the parent class is initialized first, which is a key concept in OOP. --- 🔥 Quick Example: class Demo { Demo() { this(10); } Demo(int x) { System.out.println(x); } public static void main(String[] args) { new Demo(); } } --- 📌 Mastering concepts like this makes your Java fundamentals strong and interview-ready! #Java #OOP #Programming #Coding #Developers #SoftwareEngineering #JavaDeveloper #InterviewPrep #Learning #Tech

“If you learn Assembly language before you start coding, you’re already ahead…” But wait—have you ever been deep inside a messy PHP or Java codebase and suddenly felt like writing: 👉 goto ... Yeah… same here. That moment says a lot. Learning low-level programming (like Assembly) gives you a strong mental model of how code actually flows: • You think in jumps, conditions, and execution paths • You understand what the machine is really doing • You become very aware of control flow So when you move to high-level languages like PHP or Java, something interesting happens… You start noticing when the structure breaks down. That urge to use goto usually appears when: • The logic is too tangled • There are too many nested conditions • The code lacks clear structure or abstraction In other words—it’s not that you should use goto… It’s that your brain is detecting bad design. 💡 Assembly doesn’t teach you to write messy code— it teaches you to recognize it. Instead of reaching for goto, you start asking: • Can this be refactored into smaller functions? • Should this be a state machine? • Is there a cleaner control flow? That’s the real advantage. Low-level knowledge doesn’t make you write lower-level code—it makes you write better high-level code. So next time you feel like typing goto… Pause. That’s your signal—not to jump—but to redesign. #Programming #SoftwareEngineering #CleanCode #Assembly #Java #PHP #DevThoughts #solobea.com

Every time I opened a new Java project in VS Code, I had to set it up from scratch. I work across multiple Java repositories. IntelliJ is my main IDE, but I use VS Code and Cursor for quick navigation and AI-first coding. Lighter. Always ready. But it doesn't pick up IntelliJ configs automatically. So every new project meant: - Mapping source folders manually - Fixing JAR paths - Setting the JDK again Same steps every time. So I tried something different. Instead of writing a script, I wrote a Markdown file. Step-by-step instructions telling the AI exactly what to do. A small snippet from the file: - Check .idea at root only (ignore subdirs) - Extract source roots from .iml files - Map them to java.project.sourcePaths Now I just type /java-vscode-setup in VS Code or Cursor Agent. The AI scans the project. Generates the correct settings.json. Confirms changes before applying them. No scripts. No extra tools. Just clear instructions. This changed how I think about automation. Instead of writing scripts to do the work, you write instructions that guide the AI to do it. Same result. Less hassle. Works across every repo. Could I have done this with a Python script? Yes. But I'm already in Claude or Cursor anyway. So I built it where I work. Still experimenting with this approach. Curious - what task have you turned into a slash command? #AI #Cursor #Claude #VSCode #DevTools