3 ms·
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 i
by 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.
- jewbacca 16y agoDon't know any jQuery, but that looks like a monad. Glad it's found it's way into practice.
- kls 16y agoSure and I get that they are compatible, but I think jQuery may be a bad example. Have you ever tried to write a huge web app with jQuery? I have and I can say hands down that Dojo is an easier toolkit to develop large apps with. The reason, everything is implemented on the jQuery tree and you have to chain stuff together. So long as you don't have to extend jQuery, it works well, but as soon as you have to provide a large code base with custom plugins to manage the code it becomes untenable quickly. I know I have done quite a few of them. Please don't take this as me knocking jQuery, I love it and use it extensively for quick solutions in which I am going to use existing functionality, but if you have a problem set that grows beyond whats in the box or that you can't find in a box. It becomes a massive time sink. One of the major reasons is it does not have the concept of jQuery code existing outside of the jQuery tree you build on jQuery and not with jQuery while subtle it is a huge distinction. It is a monolithic philosophy, you have a hard dependency on jQuery while Dojo does require a dojo API to declare and construct objects they exist independent of the dojo tree. It is not my intention of devolving this into a toolkit war, but I wanted to highlight that jQuery exemplifies my assertions, it is great for quick a dirty, there is nothing faster, but it does not provide the depth of a more OO centric framework for those of us that produce the building blocks that other people use. I think this post sums up what I am trying to say better than I am communicating it: http://news.ycombinator.com/item?id=1805143 http://news.ycombinator.com/item?id=1805143 As well for sake of clarity, when I say UI development, I am not talking about putting text boxes on a page, grabbing the values and submitting them to a service. OO provides no advantage over functional in controller or work-flow logic. When I am talking about OO's advantage it is specific to new and novel UI components that are packaged for others to use off the shelf in controllers and work-flows, in fact I think OO is inferior for work-flow. Just wanted to ensure that I provided clarity on where I believe OO provides superior advantages over functional. In fact, the way most people I have seen do OOP sure people do bad OO they also do bad functional the reality is there are more hacks than there are good programmers. It is not an exclusive trademark of OO programmers. I will give you though bad OO is much harder to fix than bad functional. It's the nature of the beast. To quote uncle Ben "With great power comes great responsibility". I realized that this is just a matter of opinion You are correct it is my opinion, that is why when I posted my first comment I called it a philosophy. It is all opinion, some of it relies completely on how an individual developers mind works. But for me, and most of the developers that I know that have been doing UI for a long time the opinion is that OO provides a superior philosophy. If you find that something suits you better by all means use what works for you.