Abstraction Vs Code Readability

[@Qbe_Root]

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

[@kantancoding]

💯

[@JackPunter2012]

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.

[@kantancoding]

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.

[@sp3ctum]

@@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.

[@kantancoding]

@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 🤷‍♂️

[@Nellak2011]

@@kantancoding Bro just use an explicit mapping and in the mapping you can refer to functions or data. It is not that hard.

[@DaveB-w2i]

@@Nellak2011 that is a form of abstraction, which is what this thread was about. And as soon as your collection of mappings need additional data, you need to house those in a closure if not a base class. Further when you are reading the internal code of the system calling function pointers where you don't know the implementation, you are back to the exact same problems. Only now your abstraction as an example, animals.AddAnimal("cow", ()=> {. }, () => {...}) doesn't even benefit from the clarity of the structure of a class and god forbid there is shared logic and state between animals that fly and those that swim. The point being there are many ways to code something. And what is simplest to understand depends on a variety of factors including extensibility, reusability, need to extend in other code models, max number of "implementations", .... If anyone tells you to always do something one way, they are probably wrong.

[@RenderingUser]

This isn't abstraction vs not This is inheritance vs not

[@Effisso]

Data-driven programming is a good alternative. Have data files (e.g. JSON) define some characteristics that the code can use to determine functionality. Then you only need a single Animal class that uses data to define how it behaves, instead of specific classes for each animal permutation.

[@Effisso]

Again, this is an oversimplification that would probably require a more robust implementation of Animal, and potential composite pieces of functionality to create the full Animal object instance, but it can be a good idea to think in terms of data, rather than functional structure for things with wide variance.

[@SquidOnWeed]

If the class is nontrivial, you just end up with a "data file" describing how to dynamically compose the class, which isn't any different in principle from simply defining it in the code, except for the dynamism (which may or may not be needed). I think your approach is more appropriate for filling in templates than for defining structure or behavior, unless you need dynamic behavior.

[@enderstudios3835]

Minecraft does this also which is neat

[@Effisso]

@@SquidOnWeed That's a good point. What I proposed is not a "silver bullet" solution, but it's another tool in the toolbox that can be used effectively in appropriate situations. Adequately assessing the problem domain is critical in choosing what tool to use most effectively.

[@byaruhaf]

LOL, ending the video with the classic software developer response: "It depends."

[@wjrasmussen666]

What does the fox say?

[@kantancoding]

😂

[@rubenk548]

What does the Turtoise say?

[@d2teisen]

Just don't pre-abstract everything, pre-mature abstraction is root of all evil 🤔

[@holl7w]

Pretty sure it was optimus prime-

[@dcmbassi]

My takeaway is that stampeding buffalo are just saying hello.

[@markaurelius61]

I thought that was an antisocial way to greet me.

[@philadams9254]

Why do these examples always use animals? Who the hell is programming animals and for what purpose?

[@anonymous49125]

Biggest thing is when you go to add another 'animal'... you need to find every single switch (or 'if' in this case) and update it there. AT BEST use an enum and switches... which read better... But ideally, you want to add each thing into its own class. ALSO you can have the base class have default implementation and just override the bits that need it, or even shared helper functions in the base class.

[@daniel-guillen-1]

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!

[@greyshopleskin2315]

Do you know this principle is related to stakeholders and not technical reasons?

[@daniel-guillen-1]

@ how so? Like company departments?

[@greyshopleskin2315]

@@daniel-guillen-1 read clean architecture book, there’s a chapter for that

[@greyshopleskin2315]

@@daniel-guillen-1 but yeah, sort of

[@bigombrello]

@@greyshopleskin2315Nope, it’s also related to object oriented programming

[@mienislav]

Thank you for this video! In real-world, we operate mostly on structs / objects because it's much easier to follow and maintain. In this example I agree that when having just a few strings, we could just map them. Hovewer, this approach breaks open/closed principle when we expect to have more cases in the future (as was shown in this video, when there were more animals introduced). I think an alternative solution would be just to have Animal class (very generic) with one property (greet), which is initialized from a config file (any format, even CSV). This would reduce a need for abstraction. But yeah, it was a great video! Keep going!

[@rilauats]

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.

Man says "it depends" and automatically obtains a degree in Computer Sciences

[@AKHalex]

1:19 I don't think that code example works. String comparison with double equals checks that the two strings are the same object. Not that they have the same text value.

[@giodefreitas]

I was just prepared to comment "Open close principle has left the chat". Glad I watched the entire video

[@werneryc]

You don't program a lot do you?

[@funkdefied1]

👎

[@DaveB-w2i]

I love ironic comments like yours. I would think the person who doesn't realize the best way to implement something (abstraction or not) depends on the nature of the specific problem doesn't program a lot. I'll take commenters suffering from Dunning Kruger for 400 Alex.

[@nangz]

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().

[@KazmirRunik]

2:20 So map them to functions instead of strings. Then, because some of those functions have shared code, you abstract further, repeat the process, make it turtles all the eay down 🙃

[@SweetDemon11]

Great video, i would also like to know what is the theme name used in the code, i really liked it!

[@ЕвгенийКрасилов-о9о]

Why would I map strings to strings when I can map it to callable? Or why don't use simple function that uses match-case which is much more reliable cuz you don't need to implement hash for your class to map it? So many questions...

[@SirusStarTV]

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.

[@itskittyme]

doesn't Java have "switch" statements?

[@ReoL_17]

Or you could not use inheritance. Implement it as a component that can be added to the animal class if a greeting is necessary, and now you can have readability and abstraction.

[@GameSteals]

What IDE do you use?

[@BriceFernandes]

Moving to a map is not missing the point. In most cases, it's the right call. A data-structure + functions approach scales much better and is much more flexible than using OO, even for large code bases.

[@rodrigoribeiro8476]

sorry to bother, but what is the font used in the code?

[@kantancoding]

Agave nerd font brother

[@modestmii]

Crazy how the transition at 1:04 was 7.2% of the actual video.

[@eispider]

What theam are you using in intellij ? it looks nice.

[@enchantedplays7860]

I like this no bloat and sharing your opinion and ideas

[@Jake-mp7ex]

Why would I see the parent class before the implementation? Who reads code that way?

[@saryakan]

Abstraction is mostly a problem when it's more than one layer, especially if you are on what I like to call the "business part" of your application. For internal libraries and APIs a second layer can still be done, but nothing more than that.

[@maxbd2618]

What "good code" is changes with the time period, it isn't much of a burden for me to have to click the "go to definition" button in Visual Studio twice. Modern tools means modern code.

[@Nellak2011]

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.

[@GordonRoland]

As illustrated: Different solutions for for different situations. Only disagreement with you: Not "Abstraction Vs Readability." Abstraction can be most readable solution.

[@DaveB-w2i]

very good point.

Everything in life is balanced. Interfaces are good in large projects

[@xlerb2286]

"It depends". That's most always the case and something some developers have a hard time understanding.

[@MH-sf6jz]

So what is abstraction? I don’t think there is a clear definition of abstraction in the video?

[@Fasyle]

Under baked arguments, but sure. It would have been good to demonstrate other ways to abstract code, not just classes. Almost everything is an abstraction. If you need to reuse something, you generally will abstract it to reuse it. The problem isn't abstraction, per se...but it is the hammer everyone goes for when they need to screw in a light bulb.

[@SquidOnWeed]

Generally, if you want to reuse something, you only need to "abstract" it in the narrow sense of lifting free variables into parameters, but this isn't what OO programmers have in mind when they talk about abstractions. OOP promises reusability through "abstraction" but it rarely delivers on this promise, since it encourages abstraction on the wrong level of granularity and in the wrong aspects.

[@imqqmi]

Key value pair is still a good solution and it can scale if you think in terms of records, tables and foreign keys and link tables etc. You can combine it with DI based on workflow definitions etc. The point is how you convey meaning and intent in your code and/or data structures and/or designs. Implementation isn't that important, or rather flows from domain/business logic. Decide if an entity has one, a few or many, what are the expectations, can one become a few or even many? When will you refactor or over abstract/prematurely optimize? Thank me later or blame me now? Foresight and insight or going with the flow and running blind? It not only depends, do what makes the most sense for each step on the way, which requires stopping, thinking/learning then doing over and over. It's the art of doing the right thing at the right time and have a win streak until you finish the job.

[@LooksGoodMusic]

Good abstraction makes code easier to read, not harder to read. If hiding the information makes the code easier to understand, it might be a good idea. Subclasses and inheritance are kind of always more confusing than composition though

[@SirusStarTV]

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?!?"

[@davidgood840]

I noticed you don't have fox implementation , presumably because we don't know how it greets .

[@anion155]

2:50, so basically map is still viable, depends on language it would still be simpler

[@Gravybagel]

Composition solves a lot of the issues associated with hunting through inheritance trees. Also, completely not addressed here. Composition should be the norm with intolerance being the exception.

[@AlexMakovsky]

Wow! With my low skill of programming I have a Smart way of programming :'D

[@GnomeEU]

So what if I want to add a parameter to greet. Or make it generic, or change it's signature in any way. Then I need to open 100 files and change them. This is called legacy code the minute you write it. But it fine we have ai now, ai can refactor that mess for us.

[@DaveB-w2i]

That is called optional named parameters in modern software. Before optional named parameters we created a struct or class with default values and passed it in. And you know when you are creating an abstraction that is likely to have a very large number of implementations to know if this is worth it to consider up front, which you don't have to with optional named parameters.

[@TheBypasser]

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).

[@avidrucker]

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

[@kantancoding]

I don’t think the phrase “polymorphism rather than abstraction” makes sense since polymorphism is inherently abstraction.

[@ult1873]

Well, I mean, what a table can't do, a switch statement can. So it's fine ¯\_(ツ)_/¯

[@Nicholas-nu9jx]

I think interfaces are way to go over inheritance

[@Ariccio123]

Finally, someone who thinks like me!

[@ykristianhd]

Programming is not only about write code 😮

[@venusearth6682]

I hope you have an amazing Thanksgiving ♥️♥️♥️♥️❣️❣️❣️

[@pajeetsingh]

Depends on the person. Some people are good at following orders and some can't stop asking why.

[@Daniel_Zhu_a6f]

imo it's very bad to draw any conclusions from such artificial examples. like there is no way to actually decide whether animals should even inherit from the same class. a game dev might say that they should be all of the same type, and their behavior (sounds they make, health, speed, textures) should be specified by struct fields. a data scientist would say that there should be no animal type, because you already have arrays and data frames, and those are the only two types you need. an embedded dev would prob come up with some sort of null-delimited associative array of animals that lives in the text segment of the binary (btw, there are no types, there are only register sizes and cpu instructions). and a biologist would probably say that taxons are sets, not types.

[@RadenVijaya]

Why dont you use switch / case?

[@osmigtorres2333]

Summary: it depends.

[@mvargasmoran]

Bruh there's nothing that I dislike more than "Class Oriented Programming" I don't have much problem with Objects, but Classes... ooof.

[@NachtmahrNebenan]

Plus, try to avoid "else" and "else if". Just return the greet. Do it like NASA🚀

[@derstreber2]

NASA has a much harder stance on recursion. Recursion is banned. Never use recursion!

[@omegand.]

0:08 just goto implementation instead of definition and problem solved tbh

[@nngnnadas]

just give every species a "sound" variable and use it. Are you trying to write dataless code or something?

[@DaveB-w2i]

Comments similar to when the student didn't understand the assignment.

[@jshowao]

I went into this video expecting to be triggered by another "OOP sucks" video due to lack of understanding it. I left pleasantly surprised that this was not the intent of the video and actually illustrates the flaws of not thinking abstractly. Thank you, my good sir.

[@SquidOnWeed]

Well, it should have been an "OOP sucks" video, because OOP sucks. It sucks due to lack of understanding it on the part of its own adherents, who suffer from the flaw of not thinking abstractly. Only Alan Kay had the right idea. Try erasing every setter in one of your project and see if you can make it work without them (while preserving encapsulation). If you can't, you were not doing OOP.

[@SergLapin]

OOP sucks. In all examples authors show stub classes as implementations, but many if not most of developers take this to extreme for religious reasons and abstract as much as possible, so you have a soup of polymorphism and odd hybrids, which are much harder to trace down to the final composition of an instantiated object. I have seen very large codebase broken to the point where nobody could fix some of the bugs and had to fork from the point where it was believed to be in working condition and port new features to that base. Insanity.

[@jshowao]

@SergLapin Ive seen the same where nobody used classes and it was abject mess of spaghetti code. You had to modify several files with boilerplate nonsense just to implement one feature. Functions had *tens* of parameters and hundreds of global variables sprinkled throughout with no rhyme or reason. Yet another person that doesnt get it. The conclusion isnt "OOP sucks" when you see bad examples anymore than "sorting sucks" when you see bad examples. With the example in the video, you can literally make entire lists of complex objects *easily* because its all typed based through an interface. Want 500 ducks and 20 rhinos? Easy, make list of type Animal. Want to change something in X animal? Go to *one file* that's it. Want to deal with less files? Put all your classes in one. If OOP sucked, why do nearly all programming languages in use today implement OOP paradigms? Are all these people just stupid and copying OOP for no reason? No. Because it makes sense when done right.

[@SergLapin]

@jshowao it is all easy with canned examples. Like in this video, all those classes were stubs, end of story.The real attempt to conceptualize things almost always turns ugly. As an example, you have a class modem. Under the modem you have control class, tx class and rx class. Tx class will have north and south interfaces and hook tho yhe control class and its own fsm. Now you need classes for different modes, which have different interactions with fsm, also need different interfaces for different chips, which have different ways to interact with the host system, so different control implementations. And the rabbit hole is really deep. Now, you compile this code for a particular hardware configuration, where the hydra of polymorphism grows uncontrollably forming objects with multiple overlays of methods from the base classes in almost unpredictable way when resulting object contains hundreds of properties with different scopes. When you have 3-4 layers, you can probably observe the whole structure. When you have 20-30 subclasses, conceptualizing everything, you end up with a maze of virtual methods and the code which never made into the final composition. Adding injury to insult, you crosscompile for embedded with limited ability to step through the code, which meant to run in realtime, synchronized on microseconds level with external world. Good luck.

[@jshowao]

@SergLapin It doesnt "always turn ugly" I have entire application that I work with that uses inheritance a lot and it works perfectly fine and is organized well. Its one of the best code bases Ive ever worked with and it was written mostly by a person with 30+ years of experience. Its a multi-threaded application too. Its not that complicated at all if its organized well. You only need to do this stuff if you try and abstract things a zillion ways from sunday in the beginning. A simple modem most of the time communicates via serial. So just make a Device parent class that is abstract and is composed of a communication interface that reads/writes and some members that hold some information about the modem. You then assign a serialport class or tcpip class to communication on initialization. because you created a base device class, you can inherit it on a bunch of different devices. All devices usually have some way to communicate and you can set this communication via an abstract factory. I did a lot of this with DB connection strings in the past and my god did it make things so much easier. I could support multiple databases and connection string parameters easily and I just used a factory to select which one I wanted. Embedded is a whole different world. You are often memory constrained so you can't just go nuts and reference a bunch of libraries. But for most desktop and mobile apps, it makes zero sense to avoid OOP. I would suggest you read and try and understand a pattern book for example. It makes things much easier to grasp. My application can support multiple devices as long as you just write a driver. All configuration comes from a XML serializer through a parent device class that has common methods. The device can be assigned to a set of tags that is essentially a data structure that the program uses to read/write properties and info to the device. It supports label printers, power supplies, daq cards, VNA, LCR meters, TCP/IP devices, etc. All the files are well organized in a easy to understand folder structure that mimics the namespacing. It's really not that crazy. This simple inheritance structure for devices I just described solves 95% of the cases.

[@distervplays3622]

how dare you use java for the tutorial. atleast use c# or javascript or python something that doesnt require 1000 lines of code just to print something

[@teenriot-de]

Wrong language, try Kotlin, halfs the code in the examples. Sry, :)

[@Nellak2011]

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.

[@DaveB-w2i]

so long as the dog and animal doesn't need any of its own state or the animal needs to be defined in another software library. It is hard to give an example simple enough to distill the concepts being discussed but not so simple that someone won't take the wrong meaning. The presenter even saw this coming and tried to warn about missing the point. "It depends" is almost always the correct answer when choosing the best method to solve a problem in software.

[@Nellak2011]

@DaveB-w2i The presenter missed the point. He wrongly assumed you can only have primitive values in a map where you can actually use functions and other things too. So therefore if you allow this, the whole idea of traditional polymorphism using inheritance falls apart. Explicit mappings is far easier and mlre decoupled. Plus, you said it works as long as things dont need state. Things never need state attached to them. You can store the state separately and pass it in as a parameter.

[@DaveB-w2i]

@@Nellak2011 yikes

[@RunningtoCatchMyBreath]

Love you

[@paarma1752]

I would still choose the long list of if-elses. Code readability does not matter AT ALL. Having no guard rails that prevent you from creating bugs does not matter either. The ONLY thing that matters is how easy and fast it is to fix those bugs. I rather fix small dumb imperative code bugs here and there every now and then than be forced to poke holes to abstractions due to our earlier assumptions, that we based those abstractions on, turning out to be incorrect. They always turn out to be incorrect.

[@NukeCloudstalker]

Note that this video, and all its comments, whatever opinion on the subject matter, fail to bring any clarity or concretely useful conclusions. They do this because you are explaining a group of concrete issues, using abstraction, rendering everyone unable to do anything but assume/presume what must lie underneath. In effect, the video abstracted away readability, from whatever point could be made with a real example, to dealing with some abstract concept that has unclear mappings unto the actual problem the video attempts to describe. For this reason, I can only conclude that the video itself is overabstracted.

[@ryanogden1688]

Perhaps the wrong questions are being asked here. Instead of self-imposing a conceptual 2x2 matrix between abstraction/non-abstraction and readability, just use SOLID principles. These long if statements break the open/closed principle. The greet function is readable because it adheres to the single responsibility principle. Trust the basics and you’ll be fine. Oh, and don’t forget that you can always whip out a debugger to evaluate different implementations as well so you only visit the ones actually affecting the data at hand

[@leshau90]

🤮🤮🤮🤮 java