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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en
