I Finally Realised the Value of Software Engineering Design Patterns!

Introduction:

Software Design Patterns have been around for a long time. With that being said, I’d still say my exposure to them has been limited throughout my early career.

Until recently, I don’t think I’ve truly been able to appreciate the greatness and purpose of these patterns.

This week’s blog post aims to document my previous experiences, talk about the lack of structure in them and then compare it to now.

As always, before we get into this week’s blog post, please make sure to applaud, comment and share with your friends.

Happy Reading!

How Things Were Before:

As lots of you know, a lot of my work in the past has been based around JavaScript development (with a little bit of Python however this was more for my own personal projects). To simplify things here, I will focus on the React JS development.

There was little to now structure in these projects in all honesty. Yes projects were split into pages/components/contexts however that was about it.

I had heard of different design patterns however I think the nature of React JS development (Being quite loose, flexible, dynamic) makes it harder to commit to certain patterns. Also my lack of experience with software development meant I’d often just write code that ‘works’ rather than really trying to adhere to particular patterns.

How Things Are Now:

So nowadays I’m working with C# .NET Core and if you’ve used this before then you’ll know that design patterns really are enforced here.

Concepts like Model-View-Controller, Controller -> Service -> Repository are echoed across the framework, really enforcing separation of concerns. I never used to understand terms like “Business Logic” and “Data Layer” but essentially, we want to define the methods in 1 place and use them accordingly somewhere else.

The use of interfaces as a contract is a perfect way to handle what different classes expect, decoupling the implementation of a method from what the class actually needs.

I’ve been away from Object Orientated Programming for a while but coming back to it, that too with C# seems like a great way to get familiar with the fundamentals of programming.

Going Forwards:

Going forwards, I want to delve deeper into C# and Design Patterns. I’ve already mentioned that I believe this will provide a lot more structure to the code that I write.

I would also like to try and apply these principles to any side projects I do, potentially with React JS and TypeScript. Yes, this might be a challenge but I believe that my greater industrial experience nowadays will make it easier to develop more structured programs. The value of maintaining this structure is clear to see and I believe this will help me to significantly enhance my skillset.

Conclusion:

Overall, it’s great that I’m finally starting to understand software design patterns. It’s always valuable when typical concepts can actually be related to present work.

Yes it will take time to engrain these. I think right now, the focus is on making small fixes to code that already incorporates the patterns rather than creating new code myself using the design patterns.

Final Things:

As always, thank you for taking the time to read this article!

All my links are here!