Howard Phung’s Post

Five object-oriented design principles that together make your code more bug-proof, easier to understand, nicer to maintain, and simple to expand/scale.

Mastering concepts like abstraction, inheritance, and polymorphism is essential, but good object-oriented design goes beyond those fundamentals. It requires an understanding of principles like SOLID, design patterns, and the ability to anticipate and accommodate changes. A true design expert focuses on flexibility, maintainability, and scalability, ensuring that the system can evolve without breaking down. In short, knowing concepts like abstraction, inheritance, and polymorphism do not make you a good object oriented designer. A design guru thinks about how to create flexible designs that are maintainable and that can cope with change. #OOPDesign #SoftwareDesign #Maintainability #FlexibleDesign #DesignPatterns #SOLIDPrinciples #CleanArchitecture #CodeQuality #ObjectOrientedProgramming #ScalableSystems

What is more complex your domain or the things that your models have to do to interact with other contexts? I would suggest that if you were able to focus on what it is that defines your domain model, the things that are on the outside of this world are more complicated. The essence of domain driven design is to support this idea. When you need to mix other contexts that are from the outside world from the perspective of your domain, complexity grows at a faster pace that you would like. The answer to this is to separate your concerns so that multiple contexts do not strangle your ability to create. How do you separate contexts within a domain model? Often there are separate classes, or naming conventions for different fields that would collide because they would have the same name. How do you know if your code is mixing too many contexts? Likely it will feel more complicated than it should be.

After completing our deep dive into "𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀", it's time to move forward in our design patterns journey with "𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀". These patterns focus on simplifying the structure of code by identifying relationships between objects and classes. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 Design Pattern is a design pattern that acts as a bridge between incompatible interfaces. Think of it like this: Imagine you’ve got a round hole (your expected interface) but only a square peg (your existing class) to fit into it. Instead of re-designing the hole or the peg, you create an adapter that makes the square peg fit the round hole perfectly. In code, this pattern allows a class with an incompatible interface to work seamlessly with others. This is particularly useful when working with legacy systems or third-party libraries. 𝗪𝗵𝘆 𝘂𝘀𝗲 𝗶𝘁? 1. To integrate new features without breaking existing systems. 2. To enhance code reusability. 3. To ensure systems remain flexible and scalable. I'll keep this explanation simple, but if you’re looking for more depth or examples, here are a few great resources: 1. https://lnkd.in/gJagjbjR 2. https://lnkd.in/gdxgfmfX 3. https://lnkd.in/gYEdPGDv Structural design patterns are all about making the architecture of your code both elegant and efficient. Stay tuned as I explore more such patterns in the coming weeks! 😉 . . . . . . . #designPatterns #systemDesign #lld #hld #code #software

The purpose of object oriented design is to reduce the cost of change.

Summarising use case of Creational Design patterns.

Learn how implementing design patterns can transform your code into a more efficient and maintainable asset Visit crantechllc.com for insights. 🚀

💡 Low-Level Design: Got to Know About SOLID Principles Recently, I’ve been diving deeper into low-level design, and the SOLID principles have stood out as game-changers for writing clean, maintainable code. Here’s a quick rundown: 1. S - Single Responsibility Principle: Every class should have only one job, making systems easier to understand and modify. 2. O - Open/Closed Principle: Code should be open for extension but closed for modification, ensuring flexibility without breaking existing functionality. 3. L - Liskov Substitution Principle: Objects of a superclass should be replaceable with objects of a subclass without altering the correctness of the program. 4. I - Interface Segregation Principle: Don’t force clients to depend on methods they don’t use. Break large interfaces into smaller, specific ones. 5. D - Dependency Inversion Principle: High-level modules shouldn’t depend on low-level modules. Both should depend on abstractions. #LowLevelDesign #SOLIDPrinciples #SoftwareArchitecture #BackendDevelopment #CleanCode #SoftwareEngineering #SystemDesign

5 Important Design Patterns

Let's talk about Design Systems. Breaking things down into a granular set of atomic pieces that can formulate a greater pattern through the use of slot design mechanics can allow you to rapidly iterate quickly and cycle through a myriad of design styles in an A/B fashion to compare which design works best when it comes to the testing and acceptance criteria stage. I'll be blogging about how to use and write tokens for JSON and component building architecture when it comes to shipping designs with Design Systems supporting your work. What would you like to know about design systems?