3 ms·

What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein O

by Xurinos 16y ago

What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein OO can be in opposition? In other words, how are you programming your class methods, and how are you programming the things that call those methods in a way that is not "procedural, functional, or declarative"? OOP is not a philosophy. It is a way to glue data together. OOP is not separate from "procedural, functional, or declarative" programming, so it cannot possibly be "superior". I object to this becoming a religion or a we vs them. Here is an example for clarity: x = new(Complex); set_real_part(x, 4); set_imag_part(x, 10); imag_part = get_imag_part(x); Did I program that with OOP? How can you tell? Is it just syntax (because we can rearrange syntax)? x = new(Complex); x->set_real_part(4); x->set_imag_part(10); imag_part = x->get_imag_part(); And back to my hint: x = new(Complex); x = x->set_real_part(4); x = x->set_imag_part(10); imag_part = x->get_imag_part(); x could be a function.

kls 16y ago
OOP is not a philosophy philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it" It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well. I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation. You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application. External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO. Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.
- contextfree 16y ago
  Those are really benefits of data abstraction, not necessarily OOP (which is a specific approach to achieving data abstraction)
  - kls 16y ago
    Yes, I agree and that was my point, OO provides the simplest mechanism to achieve that abstraction when it comes to the UI. I know it can be done with the others but my experience has been that it is at the cost of added complexity. I see beauty in simplicity and for the UI OO provides simplicity to the problem domain.
- Xurinos 16y ago
  For UI elements it is OO hands down. I was thinking about this assertion on a walk, and I realized that this is just a matter of opinion. I can see it apply if you were programming with Tk. The same goes for Gtk, but when you add glide, the UI construction becomes declarative, and to be honest with you, I have preferred that style of UI construction over having to figure out my arrangements by pencil and paper. I would say that for 90% of your cases, you are not writing a truly dynamic UI that requires OOP to construct things. When we talk about responding to events, we respond with functions. Presumably, we bury those functions in random placeholders, like a class dedicated to the callbacks, but they are still just functions that describe how to behave. When I do web programming, I find myself with a mixed approach: HTML and CSS (declarative), javascript with jQuery (OOP and functional). jQuery is an interesting use case of the blending of OOP and FP. Consider that when you make changes to objects in jQuery, a jQuery object is returned. Thus, you can chain things like this: jQuery(element).action().action().action(); This is actually an improvement over typical OOP as implemented by people who do not understand the benefits of FP, and it reinforces the fact that OOP and FP are compatible, not some kind of opposing forces. In you example I have to package up the functions Packaging issues really have little to do with OOP. Yes. One way to do that is with a class. Another might be a package or namespace. Organization is a social issue. What you described is not a strength of OOP. In fact, the way most people I have seen do OOP is bulky because they are trying to mitigate this packaging issue: they try to put everything into one single class that is easy to share, as opposed to breaking it down to its logical parts with multiple classes. Take a simple textarea widget, for example. Let's say you want to extend it to have a spell-checking feature. You extend the class to be TextAreaWithSpellChecking. The typical poorly designed resulting class will include the spell-checking code as opposed to implementing spell-checking in a separate module. It is easier to send the single class than multiple classes, right? Where should the spell-checking live? The answer is not about OOP or FP or other approaches/tools. It is about how you choose to abstract and break things apart.

by Xurinos 16y ago

kls 16y ago

OOP is not a philosophy philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it" It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well. I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation. You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application. External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO. Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.

contextfree 16y ago
Those are really benefits of data abstraction, not necessarily OOP (which is a specific approach to achieving data abstraction)
- kls 16y ago
  Yes, I agree and that was my point, OO provides the simplest mechanism to achieve that abstraction when it comes to the UI. I know it can be done with the others but my experience has been that it is at the cost of added complexity. I see beauty in simplicity and for the UI OO provides simplicity to the problem domain.
Xurinos 16y ago
For UI elements it is OO hands down. I was thinking about this assertion on a walk, and I realized that this is just a matter of opinion. I can see it apply if you were programming with Tk. The same goes for Gtk, but when you add glide, the UI construction becomes declarative, and to be honest with you, I have preferred that style of UI construction over having to figure out my arrangements by pencil and paper. I would say that for 90% of your cases, you are not writing a truly dynamic UI that requires OOP to construct things. When we talk about responding to events, we respond with functions. Presumably, we bury those functions in random placeholders, like a class dedicated to the callbacks, but they are still just functions that describe how to behave. When I do web programming, I find myself with a mixed approach: HTML and CSS (declarative), javascript with jQuery (OOP and functional). jQuery is an interesting use case of the blending of OOP and FP. Consider that when you make changes to objects in jQuery, a jQuery object is returned. Thus, you can chain things like this: jQuery(element).action().action().action(); This is actually an improvement over typical OOP as implemented by people who do not understand the benefits of FP, and it reinforces the fact that OOP and FP are compatible, not some kind of opposing forces. In you example I have to package up the functions Packaging issues really have little to do with OOP. Yes. One way to do that is with a class. Another might be a package or namespace. Organization is a social issue. What you described is not a strength of OOP. In fact, the way most people I have seen do OOP is bulky because they are trying to mitigate this packaging issue: they try to put everything into one single class that is easy to share, as opposed to breaking it down to its logical parts with multiple classes. Take a simple textarea widget, for example. Let's say you want to extend it to have a spell-checking feature. You extend the class to be TextAreaWithSpellChecking. The typical poorly designed resulting class will include the spell-checking code as opposed to implementing spell-checking in a separate module. It is easier to send the single class than multiple classes, right? Where should the spell-checking live? The answer is not about OOP or FP or other approaches/tools. It is about how you choose to abstract and break things apart.