Comments by "MrAbrazildo" (@MrAbrazildo) on "Object Oriented Programming vs Functional Programming" video.

@plan.b2 Let's say you want to hide data in C, kind of a class in C++. You will have to put that data aside, in other file, to be seen only in that file, with some f()s to talk to public. And how could you inherit this code? You could repeat it with macros, but it would be awful, because of too many code. I love macros, but not for an entire class. And let's say you want several objects of that "class" in C. There's no way, unless you transform all from that file into arrays, but the resulting code would be prone to errors, compared to a C++ array of objects.
2
@nathanhedglin931 Respecting the chosen inheritance flow, I never get messy inheritance. From the most generic to the most specific class or from the class with less data to the most resourceful 1, keeps the concept.
2
@nathanhedglin931 As I said in my previous comments, FP has encapsulation, but it's clunky. OO has a pretty automatized process, cleaning the path for inheritance. I think it's an actual improvement. For inheritance, I don't use virtual. I think base class doesn't has to say what should come next. And it's slow.
2
@plan.b2 I think the linked video failed to see OO advantages. I leaved comments there too. Inheritance is an automatized process, leading to clean code, which in my opinion is better for reading and maintainability. At least in C++, you can configure how the inheritance will apply: accessing restrictions, change access to specif f()s or data, reuse of constructors, and so on.
2
@plan.b2 The DRY principle (Do not Repeat Yourself) protects the coder from errors. Inheritance works with it. Let's say you must compute objects and people. Both have locations, and you want compress locations coordinates to save memory, leading to not intuitive code. It's nice to have that in a class, with f()s to unpack info behind the scenes and keep a higher level dialogue. Both classes inheriting that is DRY. Even if you use hash table, trying to say that won't inherit, because it will be an unique array/list/container, you can reach a situation in which you realize it's better to have 2 hash tables, because let's say, people is the "hot data" (more accessed), and the whole app will be faster if accessed separately. In this case, the locations class could hold an array itself, being inherited by both hash tables, keeping the DRY principle.
2
@nathanhedglin931 I guess the discussion OO vs FP is all about implementing OO features in FP, which I don't recommend. For instance, FP is kind clunky to hide a variable. And since this is crucial to me, I use classes. But of course every time a can avoid a class, I use just f()s or lambdas - i.e. when I don't need to keep upgrading data throughout N calls.
1
@plan.b2 But OO protects you from you far better than FP. It's only for performance that 1 can consider to risk a little bit.
1
@plan.b2 If all you are dealing with is a database, which asks to the user what action to take, does that, and asks again, it's fine to use FP. But if you are handling a highly interactive project, such as a game, operating system or multimedia at all, things can get really dangerous in FP. Let's suppose the user starts frantically kidding with window resizing. This will try to access many data, before concluding some tasks, testing the stability of the system. OO has much more chances to catch any error, due to its restrictions. For instance, you have control of who is trying to reach the hidden data. Here's an example of that: https://www.youtube.com/watch?v=0Yh80SvW9mo
1
@tommornini2470 ??
1
@ewildgoose No, it's Joker, with objects instead of $$. Anyway, OO is "late binding", so it's expected to send messages, copy them into something, to later do something or send another message.
1