+Julius Mboli You're welcome, and thank you very much for your nice comment! You're right, nothing beats knowing I was of help to someone. I'm glad you found my work useful =)
Was researching the OOP concepts, watching videos and reading online luckily I stumbled upon your channel. Thank you! I have mock interviews to prepare for and you have helped me understand data abstraction.
Probably one of the best explanations of Abstraction I've heard. I am in a data structures with Java and I have an exam tomorrow and this cleared it up. My book explained it in a very poor way. You should try to make a video on encapsulation at some point, I think that can be more confusing to people than abstraction. It is to me atleast.
Great video. I'm not gonna lie, when I hear a thick accent on a video I often have a tough time watching it since I'm usually expending most of my mental energy deciphering half of what they're saying, but your English is excellent, and I actually found that you articulate better than many native English speakers. The video was succinct while being very informative. Thank you! I'll definitely be subscribing.
+John Nettles Hello and thank you so much for your comment! I'm really relieved to hear that about my English - My geographical region tends to have pretty strong accents so I'm glad you could understand me well. Glad you liked the video! I'm very happy to have been of help :)
Great explanation brother. Very eye opening for me. I pride myself in trying to learn every detail of every thing i usually do but this is infeasible. Thanks for the knowledge.
Thank you for your video, it really helped me a lot to understand the meaning of abstraction. I wish you could also create some mini series of Java Programming.
the good explain on youtube . the concept of abstraction is hard term in oop and necessary one to understand all other terms ( data hiding , encapsulation , polymorphism , ........)
Putting it simply, 'abstraction' in computing is really organisation - grouping actions so that the number of named actions is reduced to a handful. For example, a game of snakes and ladders may have a hundred or so steps. These can be divided up into the top level abstractions: 'Start', 'Middle' and 'End'. This easy to follow - you can handle that in your head without too much trouble! Each of these can then be further subdivided into further abstractions until you reach the fundamental or elemental actions e.g. 'roll the dice'. Once you have divided the problem (the game) into a hierarchy of abstractions, with appropriate control structures connecting them, you will have your algorithm and can then write your code. Abstraction in this sense doesn't belong to computing - it belongs to thinking and especially planning and managing processes. It is how we work with the world when we plan and manage. We say, 'Monday', we do not attempt to say all of the things that make up Monday. We say, 'Lunch' to deal with the concept of eating at midday. We break that down into, 'First course' and so on. The problem with abstraction in computing is that ever since the early days, in the late 1960s, when the term started to be used by Dijkstra et al to solve the 1968 Software Crisis, so the error of confusing it with abstraction in art has been made over and over again. In the UK it is so widely wrongly used that it is hard to see how it is all going to be undone and put to rights!
Hello and thank you very much for your comment! While thinking of abstraction as "organization" is a generally good way of describing _how to do_ it, it doesn't capture the essence of _why_ we do it or what makes it so powerful. The key advantage of abstraction comes about because it allows us to ignore implementation details, and you are right - It is a bigger part of life than computing. For example, can use a fan, or a washing machine, without knowledge of its internal implementation, and that's abstraction at work. The term certainly does not _belong_ to computing in the sense that it has an application outside of a computing context, but that's no reason to say that it's _wrong_ to be used in computing. It has its significance and part to play when used in this context. It's meaningful and expressive, so why should it be "undone"?
0612 TV w/ NERDfirst Hi. There was nothing wrong with what you said. I was just thinking out loud really as I have been working on this concept and wished to float a few ideas. Sorry I didn't mean that it didn't belong in computing, just that it was bigger than its application in software and hardware engineering. Re why we do it. Yes, for the user but also in the process of analysis and design. Without using abstraction software design becomes impossible CF the 1968 software crisis and the development of Structured Programming as a response. I think Dijkstra puts it well in EWD 340 where he refers to intellectual manageability; abstraction gives intellectual manageability both in design and implementation. Before the adoption of structured languages, with functions/abstractions there was an insurmountable problem. Programmers just couldn't write code that worked. The solution was to use abstraction to reduce the number of things that you need to think about at one time by dividing the problem up into parts, each of which held further levels of abstraction i.e. the details that you don't need to see when working at higher levels.
Hello again! I too apologize. On a second reading, I'm not entirely sure I understand what your original comments about confusing the term with abstraction in art really means. From what I understand "abstraction" in computing refers to what we've both described - The act of "hiding away" low-level implementation in favor of a higher-level outlook as a means of easing mental burden. What have you been working on? And I'm also interested to see where the confusion with the use of the term in art arises.
Take a look at: www.bbc.co.uk/education/guides/zttrcdm/revision in which the BBC try to explain abstraction but make the mistake of confusing it with the meaning in art/literature rather than in CS.There is a long history of this error being made dating right back to the 1970s. More disturbing is this Open University page, with a video of Wing demonstrating that she doesn't have much idea of what she is talking about. Nor do the people who wrote the pages. www.open.edu/openlearn/science-maths-technology/computing-and-ict/introduction-computational-thinking/content-section-2The way I see it the whole of the CS computational thinking curriculum in the UK is currently based on the misunderstanding of abstraction! I am working to put that right but am not having much luck persuading people that they have got it wrong. They think that they are right as the software model appears to be an abstraction of the real-world situation - and they are right in that so far as the meaning of abstraction in literature / art is concerned. Problem is that that isn't the meaning that is important in computing and detracts from an understanding of the part played by abstraction - or, as I would say, nested, hierarchical organisation, which is what it really is.
Unfortunately I'm unable to access the open.edu link (it redirects me back to the site's front page). As for the BBC one, it actually does focus on the "details you don't have to care about" side of the definition so I think I can give it a pass, even though I think its examples are pretty weak. (They could've just said "You know how to use your iPhone but you probably don't know what's going on in its guts - That's abstraction"). Certainly if the definition of abstraction used is "software as an abstraction of a real-world situation" then that's troubling. I can't see that definition being very useful for much either. I'm still not sure if I would say abstraction is necessarily an "organizational" thing though, I think the meaning of the word itself is more - pardon me - abstract. At its highest level abstraction as a concept is just the whole act of hiding away details. When implementing it in programming, it _then_ becomes a problem of modularization and organization.
i guess i'm far behind cause you made this video 2 years ago, but i found it very useful, i had to learn this because i was learning dependency injection in inversion control and i had to wonder if i really understand the concept of abstraction, please can you do a video on inversion control?
Hello and thank you for your comment! Don't worry about being behind, I would say abstraction is a timeless fundamental concept =) Unfortunately I have never heard of inversion control pattern before today. I'll do a bit of research and see what I can do!
Dude, a small doubt, if data abstraction is not concerned about how the datum is manipulated then ArrayList and other Collection API's and ofcourse even int,char... are based on data abstraction , right?,but can u quote some API level example for control abstraction..
+Aditi Rajendran Hello and thank you for your comment! In the context of Java, I would say that there really isn't a lot of abstraction going on with int and char, since they are primitives. However, you are right to say that Java Collections are an abstraction since they hide away how the data is actually stored (eg. ArrayList and LinkedList both implement the Collection interface, but in very different ways). Finding control abstractions in API isn't straightforward - Normally examples of control abstractions include things like OOP, but that's not really at the API level. After digging through the API a little, I think I've found something that works - Look for classes in the Java API that end with the word "Factory". These are normally convenience classes that help you generate some other type of object. For example, you can create a border in GUI by instantiating and setting up a border, but you can also use the BorderFactory class to generate a border for you. This isn't a great example of control abstraction since not a lot of implementation details are being "hidden away", but I do believe it counts.
Hello and thank you very much for your comment and support! Glad you liked my work and hope to see you around on the comments section of more videos to come :)
Hello and thank you for your comment! Indeed I am, and that is deliberate! As you can see from the vast majority of the comments, this is sorely needed. No assumptions, no skipping steps, but just going step by step, using examples etc, it helps with understanding! But it's good news if you think I'm being slow - It means you already know your stuff =)
Hello and thank you for your comment! I'm afraid I'm not sure what you mean. Is the plan to create a math quiz program, and the question is asking about how you would create levels of abstraction in such a program?
+Anand Singh Mann I think this question is pretty open. It's entirely up to you how you want to design the architecture of such a system in the first place. Here's how you may want to design the highest level of abstraction. In your main function, do: initProgram() loadQuestions() answers = getAnswersFromUser() reportScore(answers) Further levels of abstraction will then implement the above functions.
Hello and thank you for your comment! The two terms are not perfectly synonymous. Using function calls is one way to _do_ abstraction, but there are many ways to do it. Abstraction, when applied to coding, is a generic way of saying that "I have arranged my code such that there are high-level and low-level areas, and that you can work on or understand one without understanding of the other."
Thanks. Clarifying, in an operating system, there's a widget that closes the window (the x button). Is the abstraction the x button. Are icons which we can select or double click to open something the abstraction? Thank you. Have a great day.
You're welcome! Hmm... I feel that in this context, while we could "coerce" the definition of abstraction onto those examples, it's probably still the most relevant in coding terms. In this case, sure, you can say that an icon is an abstraction for running a command to open a file (eg. Double clicking the firefox icon instead of typing "firefox.exe" in the command line) - It does imply to a certain extent that you can now do something without knowledge of lower-level details. So yes it works, but I'm not sure how good of an example it is, or whether it fully captures the essence of the term.
Whats the problem is knowing the implementation? Why is it necessary to hide? I know I don't have to know the function implementation, but what's the problem in knowing?
Hello and thank you for your comment! For the most part, "knowing" in and of itself isn't necessarily bad, but "not knowing" can have its advantages. For example, if you're writing a module in a system that interacts with another, not knowing about its internals means you will only write code in accordance to the interface or API that is externally available. This means less coupling among modules, creating code that is more maintainable. Of course, usually abstraction is used in the context of not _needing_ to know - You can use a car or a washing machine perfectly fine without understanding its internals. All you need to know is the interface it exposes, and that is basically abstraction at work.
Thanks for your answer, but I did not understand it yet. What if I write my code in accordance to class internals (implying it's shown)? Sorry, but I think it's impossible. I readed Deitel's explanation in his book 'How to Program C++ fifth edition' and he says that if class client can write their code based on class implementations and if those implementations change, client's code would broke. But how can it be possible?
Hello and thank you for your comment! Let's try with an example and see if you can understand it better - Note that this is a very contrived example, and that when it happens in the real world, it could be a lot more subtle: Let's say you are trying to work with a class that has some storage capability. The class provides functions for you to read and write to the storage. Because the class is open-source, you see that the underlying data structure is an array. You decide to bypass the functions given to you, and to directly manipulate the underlying array instead. Everything works just fine. Some months later, the author of the class decides that they want to use a better data structure, say a hash table, for better performance. They change the underlying data structure from an array to a hash table, and update the read and write functions so they work with the new data structure. Since most users use those functions, they don't have to change their code at all. They enjoy the benefits of the updated data structure without touching a single line of code in their program. However, your code breaks, because it continues to assume that the internal data structure of the class is an array, which in fact no longer exists. If you still choose not to use the functions made available by the author, you'll have to find out how their hash table works, and to update your code accordingly. Of course, that might just break again when the author makes another performance breakthrough in his class. That's the advantage of "not knowing"! Hiding away implementation-specific details can reduce *coupling* , ie. To cut down on dependencies between modules, because these modules only communicate through a known interface. Again, this is an extremely contrived example, but hopefully can serve to demonstrate the point.
Hello again! Yeah, sure! That's what I thought, but if the author of the class is a good programmer he would put that data structure as a private member, sure? So the client couldn't access it directly even knowing it. That's my point, do you understand? So we're assuming that it's only possible when the author write the class wrong and declare that member as public for some reason, correct? In fact, if the programmer put everything that should be private as private, it makes impossible that kind of problem happen, right?
Bearing in mind that abstraction is a general concept that can exist outside of OOP - For example, if you write a program in a team, with different modules in different files, you can still provide a teammate with "an interface". If they choose to break it, it could result in more coupling. You can do abstraction in a programming language that doesn't even support OOP or knows that notion. Then again, even in OOP, we are assuming that the language can rigorously do data hiding for us, which is not always true. For example, languages like Python and JavaScript don't enforce "private" values at all. Abstraction on its own is a concept worth knowing and bearing in mind. Following best practices is never bad, and if you end up using a language one day that doesn't help you in this regard, you can still write high quality code without compromise.
+lcc0612 keep your channel going and the videos coming. i enjoy your style and personality! i watched your video late last night but your energy lifted me up! :P
Now I atleast know one thing Mr. Bucky Roberts ( TheNewBotson ) doesn't know anything about. I'm sadly a person that will consume too much time narrowing down in depth of everything myself.
Hello and thank you for your comment! Of course, there's no real problem going in depth, it's a great learning experience! Just that in some situations perhaps it's not practical to spend too much time there.
Hello and thank you for your comment! You're spot on in terms of *what* to do. (Of course, you can also use functions or other files to do the same thing). However, with such discussions about abstraction, the *what* is easy, the hard part is the *why* and the *how*.
lcc0612 you're simplifying too much to the point that what you think you say to what is being said are two different things. It's a common mistake made with most educators really.
+Flash Man Thanks for sharing! That's actually really interesting - In my experience the vast majority of educators tend to overcomplicate. Far too few people in technical fields are capable of transmitting information at a high level in plain English. I find that far too many of my peers have difficulty learning because of information overload that is more often than not too detached from any context. It makes it very difficult to absorb content in that manner. The entire premise behind this channel is to address this problem, and that's why I chose my particular style! Do you have any specific examples in which meaning was lost through oversimplification? Of course, simplifying is walking a fine line, and I'm entirely aware that I'm never rigorous as a result, but the last thing I want is to be misleading!
lcc0612 when you're talking about abstraction you need to specify the difference between polymorphism, encapsulation, inheritance and abstract data types. If you're going to use an API as an example to explain abstraction then it's going to lead to confusion especially when it comes to interface and function prototypes. Like what's the difference between an abstract class from an interface? Or a declarative preprocessor from a prototype? What's the difference between implementation of an interface from a class composition? See how things can become messy quite easily without proper terminology. Programming is such a complex topic that any method to simplify it always leads to confusion. Like how is abstraction handled differently in OOP over functional programming? Programming is serious business. I hope you reach your goal to make it as accessible as possible.
+Flash Man Hello again! While I see where you're coming from, I'm afraid I also strongly disagree - See, this video is aimed at people who don't know the difference between classes and interfaces, or what ADTs and polymorphism are. Abstraction is by no means a complex concept, so why should we demand so much pre-requisite knowledge to explain a fundamentally simple idea? Abstraction is really just hiding away something complex behind a simpler facade - That's all there is. Explaining it in terms of heavy programming concepts is a surefire way to turn someone off the idea, and that is the exact thing I'm trying to avoid. Sure, what the learner gains at the end of the day from me is something that is imprecise and non-rigorous, but for the beginner, it gives a good picture of what's to come. When the term "abstraction" comes up in their formal education, they have an intuitive and pictorial understanding of the concept, which helps with the assimilation of the more complex applications of the idea. While I agree that programming is indeed serious business, I think it's important to take that serious tone _away_ from it. That's the only chance we have to make it more acceptable and accessible to beginners. Keeping up the serious tone with beginners, especially those learning on their own time, is the quickest way to turn them away. That's why everything I do paints pictures and appeals to intuition!
