Saying that without abstraction you have to duplicate the greet logic "over and over again" is a complete disservice to other paradigms. Your right absolutely noone in they're right mind would do that... But functions exist for a reason. Inheritance isn't the only solution to these problems and videos like this, imo, do a bad job at demonstrating the options, new programmers will see this and agree with what's being said (which isn't wrong) but they'll take away that abstraction is the mechanism to solve this problem. When In A lot of cases alternatives are better suited.
Name one alternative or paradigm that doesn’t involve abstraction… I think your misunderstanding comes from the fact that you think inheritance is the only form of abstraction when in fact, it is not. Those “other paradigms” that you speak of likely also use abstraction. And just because I’m using inheritance in the example, it doesn’t mean that I am saying that inheritance is the only solution. I’m not talking about ‘inheritance’ specifically. I’m talking about abstraction, which includes but is not limited to inheritance.
@@kantancoding yes, exactly. Also, I think what is being talked about here is polymorphism, inheritance being one way to implement it. I think the subject is complex and the video does a great job at demonstrating it.
@sp3ctum Good point! The sad part is, most beginners/juniors won’t read further into this thread. They will just agree with what op said even though it’s ill-informed 🤷♂️
Basically, just make sure your interfaces make sense, and document them well, so no one has to look for the actual implementation just to understand the intent. And know when it's not worth the hassle to do all that
Here is a simplification of my map based approach if the previous comment was confusing. --- const animalBehaviors = { dog: { greet: () => console.log("Woof!"), eat: () => console.log("Dog food time!"), }, cat: { greet: () => console.log("Meow!"), eat: () => console.log("Cat food time!"), }, bird: { greet: () => console.log("Tweet tweet!"), eat: () => console.log("Bird seed time!"), }, } const performAction = (animal, action) => animalBehaviors[animal][action]() performAction('dog', 'greet') // Output: Woof! performAction('cat', 'eat') // Output: Cat food time! ---- There is no need for inheritance, no boilerplate classes, and this is highly extensible. Yet it provides the same level of abstraction as the OOP approach.
To abstract or not abstract is a hard question I would just base it off of the single responsibility principal As soon a function or service has more than one reason to change, it should be abstracted Just my opinion tho!
A good example might also be when an animal's greeting is individually more complex. Say, an animal that has a different greeting based on its gender or age. Or when the greeting is more complex than just a sound, say the greet() performs other actions like wag() or jump().
You're right, abstraction is good when it helps us develop and maintain code. Like abstraction is good to obtain simplicity in many other areas of our daily life. Like instruction chart for your next flat box furniture - or - cooking recipe for your next dinner. They all use abstraction.
Lol just figured it was Java xD Because you said using a map is wrong, but that is what I normally do in C: a constant array of structures containing the function and resource pointers as well as, if needed, a literal name (say, it is a command a user can either run from a console or get a description of).
The problem isn't Abstraction, it is improper abstraction using OOP bullshit. You can make things abstract in an intuitive way. --- Ex: import Heading from 'whereever you made it' const headersData = [{ text: 'example header' }] const componentMap = { Heading } const dataMap = { 'Heading' : headersData } const layout = [ { data: [{ titleComponent: 'Heading', titleContent: 0 }] // refer to the pre-made Heading component and fill it with the 0th thing in that list } ] const mapper = layout.map(section => ( { ... map through it the way you need } )) ---- In the above example, I made an abstraction that makes it to where you can define both the Component and Data Content for a page by simply swapping out references to it in the data part. The data part has no need to know about the details about the functions or components you use, only what they are called. So therefore, the component that uses this will not need to know "how" only "what". --- Component using it (Example) export const AboutPageBody = ({ state }) => { const { body } = state || {} return (
) } ------- The AboutPageBody component acts as a very compressed component. It doesn't need to know the details or really dictate many things, it just reads from what it is given. It is an Abstraction since it says "what" instead of "how", but it isn't complicated since all you have to do to debug it is to visit the data file with the explicit mappings and adjust the specific components and other functions you use to map it. The complexity is bounded to at most 2 hops instead of the implicit bindings used in OOP. The advantage of this approach is that now we can scale up our sites dramatically by supplying Data rather than hard-coded websites.
Isn't this an example of polymorphism rather than abstraction? Or are you using the term "abstraction" more in the general, broad, "doing OOP" sense (as opposed to procedural)? The term doesn't seem to be clearly defined here
When learning materials explain the concepts behind OOP through some Animal analogy, amateur programmers could be confused "why tf we need to create classes for animals?!?"
As illustrated: Different solutions for for different situations. Only disagreement with you: Not "Abstraction Vs Readability." Abstraction can be most readable solution.
Saying that without abstraction you have to duplicate the greet logic "over and over again" is a complete disservice to other paradigms. Your right absolutely noone in they're right mind would do that... But functions exist for a reason. Inheritance isn't the only solution to these problems and videos like this, imo, do a bad job at demonstrating the options, new programmers will see this and agree with what's being said (which isn't wrong) but they'll take away that abstraction is the mechanism to solve this problem. When In A lot of cases alternatives are better suited.
Name one alternative or paradigm that doesn’t involve abstraction…
I think your misunderstanding comes from the fact that you think inheritance is the only form of abstraction when in fact, it is not.
Those “other paradigms” that you speak of likely also use abstraction.
And just because I’m using inheritance in the example, it doesn’t mean that I am saying that inheritance is the only solution.
I’m not talking about ‘inheritance’ specifically. I’m talking about abstraction, which includes but is not limited to inheritance.
@@kantancoding yes, exactly. Also, I think what is being talked about here is polymorphism, inheritance being one way to implement it. I think the subject is complex and the video does a great job at demonstrating it.
@sp3ctum Good point! The sad part is, most beginners/juniors won’t read further into this thread. They will just agree with what op said even though it’s ill-informed 🤷♂️
@@kantancoding Bro just use an explicit mapping and in the mapping you can refer to functions or data. It is not that hard.
Basically, just make sure your interfaces make sense, and document them well, so no one has to look for the actual implementation just to understand the intent. And know when it's not worth the hassle to do all that
💯
What does the fox say?
😂
Just don't pre-abstract everything, pre-mature abstraction is root of all evil 🤔
My takeaway is that stampeding buffalo are just saying hello.
Here is a simplification of my map based approach if the previous comment was confusing.
---
const animalBehaviors = {
dog: {
greet: () => console.log("Woof!"),
eat: () => console.log("Dog food time!"),
},
cat: {
greet: () => console.log("Meow!"),
eat: () => console.log("Cat food time!"),
},
bird: {
greet: () => console.log("Tweet tweet!"),
eat: () => console.log("Bird seed time!"),
},
}
const performAction = (animal, action) => animalBehaviors[animal][action]()
performAction('dog', 'greet') // Output: Woof!
performAction('cat', 'eat') // Output: Cat food time!
----
There is no need for inheritance, no boilerplate classes, and this is highly extensible.
Yet it provides the same level of abstraction as the OOP approach.
To abstract or not abstract is a hard question
I would just base it off of the single responsibility principal
As soon a function or service has more than one reason to change, it should be abstracted
Just my opinion tho!
Do you know this principle is related to stakeholders and not technical reasons?
@ how so? Like company departments?
@@danielg4681 read clean architecture book, there’s a chapter for that
@@danielg4681 but yeah, sort of
A good example might also be when an animal's greeting is individually more complex.
Say, an animal that has a different greeting based on its gender or age.
Or when the greeting is more complex than just a sound, say the greet() performs other actions like wag() or jump().
You're right, abstraction is good when it helps us develop and maintain code. Like abstraction is good to obtain simplicity in many other areas of our daily life. Like instruction chart for your next flat box furniture - or - cooking recipe for your next dinner. They all use abstraction.
LOL, ending the video with the classic software developer response: "It depends."
What theam are you using in intellij ? it looks nice.
Of course you can get rid of abstraction on your own project when it's your source code, but when you're using libraries you don't have a choice.
I like this no bloat and sharing your opinion and ideas
Lol just figured it was Java xD Because you said using a map is wrong, but that is what I normally do in C: a constant array of structures containing the function and resource pointers as well as, if needed, a literal name (say, it is a command a user can either run from a console or get a description of).
The problem isn't Abstraction, it is improper abstraction using OOP bullshit.
You can make things abstract in an intuitive way.
--- Ex:
import Heading from 'whereever you made it'
const headersData = [{ text: 'example header' }]
const componentMap = { Heading }
const dataMap = { 'Heading' : headersData }
const layout = [
{
data: [{ titleComponent: 'Heading', titleContent: 0 }] // refer to the pre-made Heading component and fill it with the 0th thing in that list
}
]
const mapper = layout.map(section => (
{ ... map through it the way you need }
))
----
In the above example, I made an abstraction that makes it to where you can define both the Component and Data Content for a page by simply swapping out references to it in the data part.
The data part has no need to know about the details about the functions or components you use, only what they are called.
So therefore, the component that uses this will not need to know "how" only "what".
--- Component using it (Example)
export const AboutPageBody = ({ state }) => {
const { body } = state || {}
return (
{body?.map(bodySectionData =>
{bodySectionData?.data?.map(titledComponentData => )}
)}
)
}
-------
The AboutPageBody component acts as a very compressed component. It doesn't need to know the details or really dictate many things, it just reads from what it is given.
It is an Abstraction since it says "what" instead of "how", but it isn't complicated since all you have to do to debug it is to visit the data file with the explicit mappings and adjust the specific components and other functions you use to map it.
The complexity is bounded to at most 2 hops instead of the implicit bindings used in OOP.
The advantage of this approach is that now we can scale up our sites dramatically by supplying Data rather than hard-coded websites.
You don't program a lot do you?
👎
sorry to bother, but what is the font used in the code?
Agave nerd font brother
Isn't this an example of polymorphism rather than abstraction? Or are you using the term "abstraction" more in the general, broad, "doing OOP" sense (as opposed to procedural)? The term doesn't seem to be clearly defined here
I don’t think the phrase “polymorphism rather than abstraction” makes sense since polymorphism is inherently abstraction.
just give every species a "sound" variable and use it. Are you trying to write dataless code or something?
When learning materials explain the concepts behind OOP through some Animal analogy, amateur programmers could be confused "why tf we need to create classes for animals?!?"
Well, I mean, what a table can't do, a switch statement can. So it's fine ¯\_(ツ)_/¯
Bruh there's nothing that I dislike more than "Class Oriented Programming" I don't have much problem with Objects, but Classes... ooof.
As illustrated: Different solutions for for different situations. Only disagreement with you: Not "Abstraction Vs Readability." Abstraction can be most readable solution.
Depends on the person.
Some people are good at following orders and some can't stop asking why.
I hope you have an amazing Thanksgiving ♥️♥️♥️♥️❣️❣️❣️
Plus, try to avoid "else" and "else if". Just return the greet. Do it like NASA🚀
NASA has a much harder stance on recursion. Recursion is banned. Never use recursion!
0:08 just goto implementation instead of definition and problem solved tbh
Why dont you use switch / case?