I understand the way you're seeing this - the examples around it are very much around an OOP world - but I don't think they have to be.
Take Single Responsibility for instance, at its definition it says that "classes should only have a single reason to change" - however, wouldn't it be a good idea to create structures/components/functions that only have a single reason to change as well?
I think maybe abstracting SOLID a bit, you can find it applicable to most of software engineering. (Most not all lol)
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
let's have a look at Open-Close - "Classes should be open for extension, closed for modification". Apply this to functions - could we say that "functions should be closed for modification, and created in such a way that we can chain/compose them together (think higher-order functions)". Again, I guess it's just perspective. Liskov Substitution is a bit of a tough one tho haha :D
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
SO then. A beginner might say I know I'm using SOLID in an FP context but when interviewed, they may find it hard to apply the other principles and perhaps feel a bit silly 🤷♂️. Missinformation is the killer of budding careers that could have been. Or perhaps it's not reading up on your design patterns.
Anyway I know I'm guilty, I say stupid stuff all the time. To be corrected years later, Anyways thanks for stopping by.
I understand the way you're seeing this - the examples around it are very much around an OOP world - but I don't think they have to be.
Take Single Responsibility for instance, at its definition it says that "classes should only have a single reason to change" - however, wouldn't it be a good idea to create structures/components/functions that only have a single reason to change as well?
I think maybe abstracting SOLID a bit, you can find it applicable to most of software engineering. (Most not all lol)
But this is my point you want the S from solid and nothing else. Single responsibility sounds great!
I built my application using the S principle. 🎉😁👌
let's have a look at Open-Close - "Classes should be open for extension, closed for modification". Apply this to functions - could we say that "functions should be closed for modification, and created in such a way that we can chain/compose them together (think higher-order functions)". Again, I guess it's just perspective. Liskov Substitution is a bit of a tough one tho haha :D
SO then. A beginner might say I know I'm using SOLID in an FP context but when interviewed, they may find it hard to apply the other principles and perhaps feel a bit silly 🤷♂️. Missinformation is the killer of budding careers that could have been. Or perhaps it's not reading up on your design patterns.
Anyway I know I'm guilty, I say stupid stuff all the time. To be corrected years later, Anyways thanks for stopping by.
Haha! I am the king of saying stupid things - I guess the important part is not being scared to do that, and learning from it too.