SOLID Architecture
Favour Adeogo is a seasoned technical writer with a passion for elucidating the intricacies of backend development in scalable applications. With a semi-robust background in software engineering, Favour brings a unique blend of technical expertise and communication skills to his writing endeavors.
Specializing in the .NET ecosystem, Favour has honed his craft in documenting the backend architecture of scalable applications built on the .NET framework. His in-depth understanding of technologies such as C#, ASP.NET, and SQL Server enables her to articulate complex concepts in a clear and concise manner, catering to both novice developers and seasoned professionals alike.
Throughout his career, Favour has collaborated closely with development teams to capture the nuances of backend implementation, ensuring that his documentation remains relevant and up-to-date in rapidly evolving technological landscapes. His meticulous attention to detail and commitment to accuracy have earned him recognition for producing high-quality technical content that serves as a valuable resource for developers worldwide.
In addition to his technical prowess, Favour possesses excellent research skills, allowing him to stay abreast of the latest advancements in backend development methodologies and best practices. He is adept at distilling vast amounts of technical information into comprehensive guides, tutorials, and API documentation that empower developers to leverage the full potential of the .NET stack in building scalable and robust applications.
Favour's dedication to his craft, coupled with his passion for empowering developers through clear and concise documentation, makes him a trusted resource in the tech community. Whether he's crafting tutorials, writing API guides, or documenting architectural patterns, Favour remains committed to fostering a deeper understanding of backend development with dotNET, thereby empowering developers to build innovative and scalable solutions with confidence.
Architecture, Do we all understand the same thing?
People refer to architecture everywhere: posts, in articles and all other publications. And we take this word for granted, I did. We all seem to understand what it is. Are we all understanding the same thing? Ideas floating around concerning why and how you design an architecture and who does it.
First off,
Software architecture can be said to be the fundamental structure of a software system and the discipline of creating such structures and systems.
A layman will look at the above definition and then think of weird patterns, designs
or even charts which is not the goal of the process!
Software as a solution
The major reason for the creation of Software has been for problem solving.
Therefore, If you have the solution to a Software issue at work, you have the Architecture.
Then,
Architecture is the technical solution to a problem .
However, a solution can't be given if the problem isn't known . To proffer a solution in Architecture the Design Principles and Patterns must be followed. ;)
SOLID, A design Principle?
Imagine an Interview where you're asked if the SOLID principles part of software architecture and why, If you never had a profound answer to this, here's the time to get an answer.
SOLID principles are principles of Class design, they're Mnemonic Acronyms of Object Oriented Programs (OOP) coined from the writings of Robert .C. Martin in the early 2000s.
They've been around for a while and withstood the test of time. It was more of a way to think about the quality of OOPs and people basically look at it as Standards or guidelines to keep in mind while writing Object Oriented (OO) codes.
In OOPs, Identifying classes and objects and deciding how they should be used can be complex , depending on the given business problem.
Its also not uncommon for beginners to apply these principles in wrong or unintended ways. For example, Creating a class with properties and methods that shouldn't even be part of it or using Inheritance Hierarchies in the wrong way.
Wouldn't it be cool if you knew some guidelines to put in mind when designing a class?
Drum rolls
The SOLID Principles
S - Single Responsibility Principle (SRP)
O - Open Closed Principle (OCP)
L - Liskov Substitution Principle (LSP)
I - Interface Segregation Principle (ISP)
D - Dependency Inversion Principle (DIP)
We would be going through practical approaches to each of these Principles in the next publication .
PS : In this series, I'll be using C# and a bit of Asp.net for my code examples
