@Joost , Excellent Description. Of the sort that I was really hoping for! Indeed a heavy meal to digest, for an OOP person, but I see your point.
Thanks! Ajay On Sat, Dec 12, 2009 at 12:21 PM, Joost <jo...@zeekat.nl> wrote: > On 12 dec, 14:13, ajay gopalakrishnan <ajgop...@gmail.com> wrote: > > Hi, > > > > I come from a OOPS (Java) world and I am used to Singletons, Inheritance, > > Statics, Interfaces etc. > > I am reading the Programming Clojure book and I understand multi-methods > and > > when it is used. > > But I am still not able to see how to achieve the effects of Singletons, > > Inheritance, Statics, Interfaces etc. in Clojure. If the book explains it > > somewhere, I would be glad to get a pointer to that too. > > When I say "achieve the effects" , I am not asking if there is a way to > > define a Singleton class etc. I am asking that if the design in my head > has > > all these things, how would I translate that into Clojure (some way or > the > > other) or what modifications would need to be made to my design (in my > head) > > to able to directly write it in Clojure terms. > > Hi Ajay, > > Trying to translate from "traditional" OO concepts to functional > constructs is not always useful, and I'll try to explain why. When I > started writing this it sort of turned into a critique of fixed-type > class-based OO (the kind of thing you find in Java and C++) - I'm > sorry if you're not really interested in that. :) > > 1. Many of the concepts are there ONLY because there is no straight- > forward means of implementing them if you have to state everything in > terms of classes and objects. Examples: > > * Static members/methods: these are almost always just a way of > defining global functions and variables. The exception is when you > have multiple classes that implement the same static members and you > pass around the classes to get different values for the same member > names, but while this is a useful technique, it's actually not > something I've seen used in any Java program I've looked at - in my > experience, that sort of technique is used a lot more in more dynamic > OO languages that emphasize "reflection" or "meta-programming" (which > are both concepts that also seem to be solutions to the traditional > OO problems instead of radically novel concepts). > > * Singletons are nothing more than functions that always return the > same object or value. You can even implement them just as a global > variable. In my experience, actual singletons as put forth in the gang > of four book are often mistakes brought about by a lack of > imagination. > > * Interfaces are a way to deal with the fact that in traditional OO > systems, you can't treat unrelated classes the same way. The fact that > you can use interfaces to explicitly document the way your classes > work is nice but incidental. Many more dynamic OO languages (and > 'basic' clojure) don't have or need interfaces since they just check > the existence of a member or method at runtime. > > * Inheritance is overrated. it tends to be abused as a way to share > implementation details more than anything else. All the points I made > about interfaces also apply to inheritance. See also traits, for a way > to really do reuse: http://scg.unibe.ch/research/traits > > 2. In my mind, the single most important use of OO is polymorphism. > The ability to associate functions with multiple implementations > depending on their parameters is very useful since it means you can > generalize algorithms without having to know the implementation > details of the data that's passed in. Clojure has a couple of ways to > do this; multimethods are just one of the more explicit constructs. > > 3. Classes in particular are difficult concepts in Java-style OO. > Classes tend to be not really objects for one: you can't easily pass > around a class and construct instances of it later - hence Factory > methods and reflection APIs. You also can't construct new classes at > run-time, but at the same time, the language strongly suggests you to > map certain concepts to classes. Both problems are much easier dealt > with in a more dynamic language like JavaScript or Ruby, but in Ruby > especially, there seems to be a risk of turning everything in sight > into a dynamically constructed class. > > In conclusion, try to forget about OO for now and see how far you can > get using just "really functional" constructs, like closures and > higher-level functions. It's sometimes amazing to see how much cleaner > and simpler the results of a functional approach can be when compared > to objects and classes, but it does require a very different mindset - > do not try to map directly from classes and objects to functions; it > will only confuse. In my experience, it's more useful to think in a > higher level of abstraction - a set of components to do this part of > the code, and another to do that part. For instance, you can easily > implement a Model-View-Controller system functionally, but that is > because Model, View and Controller are NOT objects; they're distinct > sets of responsibilities. Software "patterns" at that level of > abstraction are useful even in a non-OO language, but you can't > directly translate their implementations. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
