Is the Supremacy of Object-Oriented Programming Over? 52
I never expected to see this. When I started my career, Object-Oriented Programming (OOP) was going mainstream. For many problems, it was and still is a natural way to modularize an application. It grew to (mostly) rule the world. Now it seems that the supremacy of objects may be coming to an end, of sorts.
I say this because of recent trends in our industry and my hands-on experience with many enterprise and Internet applications, mostly at client sites. You might be thinking that I’m referring to the mainstream breakout of Functional Programming (FP), which is happening right now. The killer app for FP is concurrency. We’ve all heard that more and more applications must be concurrent these days (which doesn’t necessarily mean multithreaded). When we remove side effects from functions and disallow mutable variables, our concurrency issues largely go away. The success of the Actor model of concurrency, as used to great effect in Erlang, is one example of a functional-style approach. The rise of map-reduce computations is another example of a functional technique going mainstream. A related phenomenon is the emergence of key-value store databases, like BigTable and CouchDB, is a reaction to the overhead of SQL databases, when the performance cost of the Relational Model isn’t justified. These databases are typically managed with functional techniques, like map-reduce.
But actually, I’m thinking of something else. Hybrid languages like Scala, F#, and OCaml have demonstrated that OOP and FP can complement each other. In a given context, they let you use the idioms that make the most sense for your particular needs. For example, immutable “objects” and functional-style pattern matching is a killer combination.
What’s really got me thinking that objects are losing their supremacy is a very mundane problem. It’s a problem that isn’t new, but like concurrency, it just seems to grow worse and worse.
The problem is that there is never a stable, clear object model in applications any more. What constitutes a BankAccount or Customer or whatever is fluid. It changes with each iteration. It’s different from one subsystem to another even within the same iteration! I see a lot of misfit object models that try to be all things to all people, so they are bloated and the teams that own them can’t be agile. The other extreme is “balkanization”, where each subsystem has its own model. We tend to think the latter case is bad. However, is lean and mean, but non-standard, worse than bloated, yet standardized?
The fact is, for a lot of these applications, it’s just data. The ceremony of object wrappers doesn’t carry its weight. Just put the data in a hash map (or a list if you don’t need the bits “labeled”) and then process the collection with your iterate, map, and reduce functions. This may sound heretical, but how much Java code could you delete today if you replaced it with a stored procedure?
These alternatives won’t work for all situations, of course. Sometimes polymorphism carries its weight. Unfortunately, it’s too tempting to use objects as if more is always better, like cow bell.
So what would replace objects for supremacy? Well, my point is really that there is no one true way. We’ve led ourselves down the wrong path. Or, to be more precise, we followed a single, very good path, but we didn’t know when to take a different path.
Increasingly, the best, most nimble designs I see use objects with a light touch; shallow hierarchies, small objects that try to obey the Single Responsibility Principle, composition rather than inheritance, etc. Coupled with a liberal use of functional idioms (like iterate, map, and reduce), these designs strike the right balance between the protection of data hiding vs. openness for easy processing. By the way, you can build these designs in almost any of our popular languages. Some languages make this easier than others, of course.
Despite the hype, I think Domain-Specific Languages (DSLs) are also very important and worth mentioning in this context. (Language-Oriented Programming – LOP – generalizes these ideas). It’s true that people drink the DSL Kool-Aid and create a mess. However, when used appropriately, DSLs reduce a program to its essential complexity, while hiding and modularizing the accidental complexity of the implementation. When it becomes easy to write a user story in code, we won’t obsess as much over the details of a BankAccount as they change from one story to another. We will embrace more flexible data persistence models, too.
Back to OOP and FP, I see the potential for their combination to lead to a rebirth of the old vision of software components, but that’s a topic for another blog post.
Time for a name change?
Very nice post. I particularly liked the point about the ‘ceremony of object wrappers’ couldn’t agree more. How do you like a structural type system like M / Oslo plays into this trend?
I’m really looking forward to the day that people in out industry don’t use words like “supremacy” to describe aspects of it. I don’t believe that technologies are involved in some sort of 19th century imperial conquest.
Anyway, in my understanding of OO there never was a need for a “stable” object model in applications. Of course our computational representation of domain concepts are fluid, of course they change every iteration. Any discomfort felt is not a problem with OO, it’s a problem with the social constructs that surround application building in corporate settings. I see all that stuff about modelling in a modelling language and having a model that was an asset of the business and lived in a repository and from which programmers derived programs as a political, not a technical choice. The high priests of Modelling who used to maintain such models have now moved on to be the guardians of the Enterprise XML Schema. Similarly with RDBMSs, as it happens. From my reading of the early papers Codd thought that he was developing a way to make structured data stores easier to change. But again the social structures that have grown up in corporations reject that.
It happens also to be too hard to manage a changing, fluid, evolving object model in the mainstream “OO” languages. Again, it doesn’t have to be that way, but we chose to go with the curly-bracket flavour of OO, we chose to cripple ourselves with that stupid, unnecessary compile(/link)/package/deploy model that makes any sort of change difficult. And I think we chose that because it turns out to be easier to commoditise curly bracket programmers, which in turn is partly because curly bracket languages are so restrictive and inflexible and lead to such inflexible designs.
These are symptoms of a social problem, at root a refusal to trust people to make and manage change. Because those who can change a thing have power over it, and in corporate settings power is the property of the hierarchy.
As it happens, the technologies that are succeeding in the world of transducing between HTTP and SQL (and there’s so much more to system building than that, when will we remember?) are much more fluid, and rightly so. That’s the change I want to see and encourage. I think that came about because for a long time slapping together web sites wasn’t really taken seriously as “programming”. And so the people who did it were not forced into the “serious programmer” technology choices. But now we do have to take building web sites seriously and indeed the Java model of how to do that doesn’t carry its weight. For suitable values of Java. That has opened the door to more dynamic approaches sneaking back in to mainstream programming and for that I am grateful.
I prefer (and practice) a multi-paradigm approach to programming. If that comes hand-in-hand with the idea that systems should be easy and quick and safe to change, and that we should trust people to do that, then we all stand to win big.
> For example, immutable “objects” and functional-style pattern matching is a killer combination.
Immutable object is a nonsense. Objects encapsulate and carry state. The very reason to bundle methods with fields, is to use those methods to change the internal state of the object. If the object is immutable suddenly everything in the OOP becomes meaningless. There’s no reason for private and protected fields and methods anymore. You can make everything public (immutable, right ?) There’s no point to bundle methods with object, because at most those methods would be able to returns NEW values instead of changing existing. And thus your object becomes a simple data structure with all fields visible and no bundled methods.
@Vagif: of course it’s not nonsense. Immutable objects can have very useful methods associated with them that don’t change the state of the object at all.
Think of something as simple as an immutable Date object which could have methods to calculate the difference between two dates. Or the day of the month/year that the date represents.
At the same time if you need to change the date you just create a new one with the required changes.
Also remember that being immutable does NOT mean that none of its attributes never change! It just means that it’s behaviour will not change from one call to another. But to be able to do that you still need your private attributes (otherwise the changing state would be accessible and therefore the advantages of an immutable object would be lost).
Common Lisp ticks all the boxes for being ideally placed for a resurgence IMHO
Combining FP with OO. Supporting internal DSLs. In-built support for changing the object model at runtime.
I remember about 10 years ago a colleague wondering what would happen to Java when OO went out of fashion…
Mark:
Except that Common Lisp is untyped.
One hype leaves, another one comes.
@FunctionMentor?
;) The thought crossed my mind. PolyglotMentor? PolyannaMentor? ...
@alexj,
I’m only familiar with structural typing in Scala. I assume it’s more or less the same thing. I find it very useful; a type-safe form of duck typing.
@Vagif,
As you say, “objects encapsulate and carry state”, which is very useful. I’m saying there are distinct advantages if we don’t allow a particular instance to change its state. Rather, new instances are created for state changes. This is very useful for robust concurrency and robustness in other ways. However, I’ll completely give up mutability when they pry it from my cold dead hands… By the way, Clojure has a lot to teach us about “principled” approaches to mutability. Worth learning about…
@Quintesse,
Continuing with your comments, one of the dumbest parts of the JDK is mutable Date objects. No sense at all. Any change should return a new Date. You don’t get to April 21st by modifying the state of April 20th…
@Ricky and @Mark,
I think Clojure will drive renewed interest in Lisp-like languages. It will be one of those languages that probably isn’t used a lot, because people have a strange aversion to (...), but it will be hugely influential, IMHO.
@all, apologies for the double comment issue. I think you have to trust the typo blog engine when you click the submit button the first time. The comment eventually shows up, but too slow for my tastes…
Nice post. I always enjoy it when you industry veterans discuss trends.
@Keith There’s no reason for supremacy to have that imperialist connotation you ascribe. Supremacy can just mean the top of or highest in achievement.
@Keith So, basically you’re just saying that you like RoR?
@Keith,
Good comments, all. You’re right that object models have always been fluid and our “culture”, including tool choices, has created unnecessary inertia. Interesting comment about Codd’s vision for databases vs. the reality we live in today. :(
One of the reasons I mentioned the idea of “just put the data in a map (or list)” was because that’s actually a very sensible and nimble way to respond to a domain model that changes fast enough or isn’t the same from one service to another. If you work and think in a language where everything must be statically typed and all parts of an object’s state must be declared as fields, then it can seem dangerous to use hash maps in this way, but what other way is there to use hash maps? Why do we have them in Java, etc. in the first place?. In fact, HttpSession (in Java…) uses a hash map essentially for this purpose, because there is no fixed set of fields for such a session. The resurgence of dynamically-typed languages will certainly help us assess our options more broadly, I think. Polyglot and polyparadigm programming, FTW!
You mention the success of relatively simple protocols like HTTP and SQL. I think such simplicity is the key to a successful component model, which is the subject of the future blog post I promised ;)
So do you thing is Scala the language to learn?
Funny, I just finished a series talking about these some of these very issues, and more, on my personal coding blog here – after having wrestled with some of them trying to create my own programming language.
@hmart, I’m biased, because I’m writing a book on Scala. ;) It’s a great step forward from Java that lets you continue to use all your existing Java code. If you’re a .NET person, F# is a good choice. (Scala is also available on .NET)
I also think Clojure is very interesting for its innovative ideas and design principles. I’m a big fan of Ruby, too, but it’s not the best choice if your goal is to learn functional programming. If that’s your goal, Haskell will teach you a lot about “pure” FP.
I agree till you say FP and OO language mixins has potential to be hyper productive in software development. However your point (a clear generalization) on how OO is failing and what is the real problem with OO makes me smile.
You say
“The problem is that there is never a stable, clear object model in applications any more. What constitutes a BankAccount or Customer or whatever is fluid.”
This is more of a genuine problem of domain dynamics then OO’s own problem, both FP and OOP has its own mechanisms to handle it. How can we say OO is failing because domain is volatile and our incompetent team can’t be agile with OO because domain is fluid?
In my experience, Everything boils down to ‘people’. No problem is bigger than ‘people’ problem in software development, if a team can’t be agile enough with OO it can’t be agile enough with FP either. So, no I don’t think OO is over to your point.
@Nirav, I don’t disagree with your points about people problems, etc. I also didn’t say that OO is failing and I certainly don’t consider FP to be the new “magic bullet”.
OOP is a tool like any other, appropriate at times and not appropriate at other times. I’m seeing too many designs bog down while trying too hard to be object oriented in some sense of the term (usually, as defined by the team’s language of choice), when alternatives would be more appropriate. I still believe in OOP and I use it regularly.
@Jonathon, I guess we’re not the only people thinking about these topics. I’m looking forward to reading your posts.
I deleted the accidental duplicate comments. Yell at me if I goofed up…
@Dean
re:Clojure – I find that language seriously intoxicating from the outside. Built in STM, functional data structures, and dynamic typed to boot? How odd but strangely enticing.
I also agree that FP is no “magic bullet”. Programming languages have the weird distinction that people are either drawn to them or ignore them. Something almost has to achieve a “magic bullet” status before people will pick it up and use it in large numbers. Partly I think that is due to the lack of strong interop, but I can’t say for sure why exactly it is.
Is World War II over?
newLISP combines FP and OOP into something we call FOOP (Functional Object-Oriented Programming). The objects are immutable and are represented as lists (naturally, newLISP being a Lisp). The first element is the name of a context, which contains the object’s methods. The methods are polymorphically called using the : (colon) operator. Mixins are used rather than inheritance.
Here is an example of using FOOP in newLISP:
(new Class ‘Point) ; defining a new class
(Point 10 20) ; creating an object
(define (Point:string p) (string (p 1) “@“ (p 2))) ; defining a method
(:string (Point 10 20)) ; applying the method
The definition of Point:string uses implicit indexing to access the attributes of the object. Accessors could just as easily be written:
(define (Point:x p) (p 1)) (define (Point:y p) (p 2))
(define (Point:string p) (string (:x p) “@“ (:y p)))
Perhaps it may be more accurate to view these as abstract data types rather than true objects, but in practice, FOOP has proven to be a simple, straightforward way of combining functional and object-oriented programming.
Why the Lucky Stiff of Ruby fame is also working on a language called Potion that appears to use something similar to FOOP (e.g., separation of methods and objects; using mixins instead of inheritance).
m i c h a e l
P.S. For more information about newLISP or FOOP, visit newLISP’s website at www.newlisp.org
>> The fact is, for a lot of these applications, it’s just data. >> The ceremony of object wrappers doesn’t carry its weight.
Well, that sums up 15 years of OOP for me! Designing a nice object heirarchy with UML, and then getting into the coding and finding that I was spending more time shifting things around in the object model, than adding features. Then, at the end of the project, rewriting the UML doc.
Still, I’ve been around long enough to remember what it was like before OO, so I’m grateful for lot’s of exciting software in the last 15 years, and the beauty of the GOF patterns.
I’m currently working in F# – in fact, I have the privilege of writing an ASP.NET application in C# 3, and prototyping it in F#. The F# is always nicer, and more intuitive. However, the .Net libraries have too much gold to ignore, so F#, being an FP language with .Net, looks good as a next generation language.
The “immutable” objects debate is interesting. C# really hit a sweet note (over Java) by allowing structs. F# takes it one step further, where the “ceremony” for a record type is much less than for a class, so one naturally prefers them. My rule of thumb is to only use a class when there is mutable data.
Rickie wrote:
> Except that Common Lisp is untyped.
Not strictly accurate.
By default you don’t have to specify a type for things but there are in fact several language constraucts to allow you to specify types if you want/need to and these declarations are used extensively by CL practitioners for example to get performance and in assertions.
@Dean
Clojure is indeed very exciting – particularly if you’ve come from a Common Lisp background as I have.
I never did get the aversion to ( .. ) thing – I came from a PASCAL background but got over the different syntax after a week or so using CL.
Now – having to indent code to specify block structure – that’s something that scares me :-)
Halleluja.. the king has arrived and he wears clothes. Instead of screaming like a preacher that everything is upside down.. wouldnt it have been enough to say that OO is extended with FP functionality. I mean.. what parts of OO will be thrown away? Yo’ll likely keep your data and functions together in “Objects”.
Awesome post, Dean. I’ve been feeling this way about objects for awhile now. Great abstraction for functional components, but their utility as models borders on painful in a fast-changing bidness app.
Also, I appreciate your referring to me so often by my initials. You’re too kind! ;-)
Lisps traditionally have had three things in their favor along this line… syntax macros are so simple that building a “DSL” is trivial; the core paradigm is applicative rather than imperative; and methods are usually implemented as “multi-methods” which allows “objects” themselves to be these very simple data structures (records, hashes, lists, atoms) when full-blown classes are overkill.
@Al
No, I don’t especially like RoR. I do like that RoR has helped make to possible to have a conversation with, eg corporate IT folks about building anything in something other than some monolithic one-size-fits-all technology choice from 5-15 years ago
@Steven
That’s a pretty sucky world all right. But we can substitute lots of things for “object” and “UML” in that sentiment and it will be equally true description of some other equally sucky world.
@ Dean
Simple is the key to everything. Bob made that point in his keynote here at ACCU yesterday: S*MTP *SNMP, the not-so-simple protocols either faded away or turned out not to be needed. One could make the same observation about LDAP
text*ile* fail
I think Keith is right, supremacy is not the term I would use. I would even suggest that OO never went ‘mainstream’ in the first place. Just like agility, it is the label and not the intent of their early proponents that have become ‘mainstream’.
@Nirav – agree, people/social issues are the root cause of many perceived ‘failures’.
There is nothing wrong with OO per se, just in the interpretations of how to apply it. Corporate constraints and politics aside, its down to the individual programmer what languages, tools and techniques they are most comfortable with. Good people learn by practice and experience which tools are appropriate to use in a particular context and for my money, being able to make that choice is more valuable than a prescriptive approach.
“Supremacy”? – Hardly relevant for a technical debate. For supposedly rational intellectual people we suffer immensely from fashion and spin.
In the sense of being fashionable, then it’s true a particular interpretation of OO ideas have been supreme. If we go back to the Original OO research however that took place at Xerox Parc in the 1970’s and early 80’s – what has been spun and popularised as OO today is very different from what they had in mind.
I will call their ideas “Pure OO”. Pure OO had a brief commercial success with Smalltalk-80, but was largely killed off by the competition which had a ‘superior’ business model. It was difficult to justify paying £3K for Smalltalk licenses when Sun Microsystems chose to give away a VM based language for free that they claimed was OO too. So free Java put an end to pure OO.
Even before Java, there was a strong bias against using anything that didn’t derive from C/Unix. So C++ another hybrid OO language was championed as the ‘OO’ language of choice. All this has to do with politics and vendors protecting market share and has nothing to do with computer science.
On the computer science front, pure OO, based on late-binding and message sends has always built on functional ideas and encourages a declarative programming style. Lisp and Smalltalk have much in common. The best way to look at it is that a function can be an object too. So I see no or very little conflict between OO and functional programming.
The real issue is that pure OO has been viewed (rightly so) as a disruptive technology. The incumbent technology base, built on C and Unix have found ways to neutralise the potential disruptive effect and hold on to their market. As a consequence we have spent the last 20 years using curly bracket languages that are ‘OO’ in name only.
This is what prompted the famous Alan Kay quote:
“I coined the term OO and I can tell you I didn’t have C++ in mind..”.
And just to show he wasn’t just picking on C++:
“Java is the worst thing to happen to computer science since MSDOS…”
Pure OO is still in obscurity. Languages like Ruby and Python show what is possible with Pure OO ideas and late-binding, but they do not extend these ideas or take them even as far as Smalltalk did.
A new language called Newspeak is attempting to extend the concepts expressed in Smalltalk and later the Self Language and take them to their ultimate expression. Unfortunately Newspeak remains obscure and is currently struggling for funding :)
So from a computer science view point, I wouldn’t call Pure OO supreme at all. No, it’s still languishing in obscurity and we are still to discover what exactly it is trying to be.
To quote Alan Kay one more time:
“The computer revolution hasn’t happened yet…”.
Paul.
nice article
Good article. Personally, I never took OOP for serious. As I learned OO back in 1988, I thought it must be a very specific programming model, for a very specific usage (i.e for modelling REAL objects, like planets, space-crafts, orbits, etc…).
My favourite is a singleton concept within OOP… That looks like apopheosis for all OOP misconcept :)
How could anyone even think it will become a prevailing technology in the next 20 years!
Good article. Personally, I never took OOP for serious. As I learned OO back in 1988, I thought it must be a very specific programming model, for a very specific usage (i.e for modelling REAL objects, like planets, space-crafts, orbits, etc…).
My favourite is a singleton concept within OOP… That looks like apopheosis for all OOP misconcept :)
How could anyone even think it will become a prevailing technology in the next 20 years!
Nice read, though I think you’re pretty biased. I wouldn’t think map-reduce is anywhere close to mainstream. Yes, you can read a lot about it, and it does make sense in a few cases, but it won’t replace relational databases, its a niche.
Sounds like baiting for flames, links and whatever popularity you can get – and I must say this is a very succesful post if you look at it from the point of view of getting the word out
Your comments are spot-on, and illustrate exactly why Flow-Based Programming (FBP) is garnering more and more interest – plus the fact that it offers a simple, consistent approach to developing applications for the new multi-core computers that everyone says are so difficult to program. Some time ago I wrote a comparison of FBP and OO, and I think they have held up – http://www.jpaulmorrison.com/fbp/oops.htm
I’m happy to say that I never drank the Kool-Aid :-)
Don’t get me wrong: There were many times when an OOP architecture made a lot of sense. There were also a lot of times when it was just plain the wrong technology.
Frankly, if you’re not taking advantage of inheritence in a significant way, you’d be just as well off with name-spaces as a full-blown OOP. And 95% of what I saw people using OOP for was nothing more than name-space separation.
I’d rather see a well-architected procedural solution that fits the problem than a bloated OOP solution that has been so mutilated over time that it “fits” only if you stand on your head and whistle Dixie.
PS Common Lisp is typed—Every datum has a very specific data-type. The variables are free to take on any value, as it should be. I happen to hate static-typed languages, personally. Too many pointless hoops.
Dean wrote: ”...just put the data in a map (or list) ... hash maps? Why do we have them in Java, etc. in the first place? ...”
I think it is very disturbing and surprising to see hash tables are being recommended on this site which is associated with the publisher of books about how to write Clean Code and applying SOLID principles.
Why we have hash maps ? Well, as long as we use them for internal private usage only (and of course without exposing a public getter to the mutable “private” hash table that would destroy the encapsulation) they can be useful for example to implement a table look up (i.e. as an alternative to if/switch statements), for example a parameterized factory method might return Command objects from a typed hashmap with a key lookup.
Regarding the comparison with HttpSession, I would say that one should make a distinction with domain/application specific code and the code that is intended for being used in all kind of applications. In other words, in your own application code you should use your own domain abstractions, but if you create an application framework (e.g. the servlet API with HttpSession) which is intended for all kind of domains then it is hard to avoid all usages of things that generally should be avoided such as using Object in method signatures (as in the method “Object HttpSession.getAttribute(String)” ).
Another thing worth mentioning, regarding making a distinction between domain/application code and generic code is the usage of reflection. The reasoning (about why it exists if we should not use it) is similar, i.e. reflection is hard to avoid for creating frameworks such as Hibernate that should support all kind of domain objects. Otherwise reflection should be avoided in runtime (but can be used in design time, for code generation) not because it is difficult to write reflection but difficult to maintain due to its worthless semantic.
Regarding sending around hash maps in PUBLIC method signatures, it is an awful anti-pattern that should never be considered as even remotely acceptable. I have seen a system where virtually all method signatures were very “generic” :-( and received one hashtable as input parameter and returned another hashtable. Within the methods, the hashtables were often passed on to other methods, which sometimes populated them with more values or even removed values, and of course you can never feel sure that you do not break any code in such a system (assuming you do not have great unit/integration test coverage for your semantic-less hashtables) i.e. you do not dare to change more than you really have to, and it is NOT refactoring-friendly.
It is not only difficult to change existing code when using hash tables, but you will aso get problems when you want to try to reuse (e.g. invoke) an existing method, since it is difficult to get the whole picture about what kind of parameters the hashtable need to contain in the invocation. If you look in the method, it is not enough but you also have to keep looking in the all other methods that are invoked from within the method… Typically, you have to debug the method to get a feeling of what kind of stuff you have to push into the hashtable.
Please also keep in mind that if you want your code base to be considered as being good, then you should not have to even look in the implementation code, and definitely you should not have to debug it to understand it.
The hash table oriented architecture should really be strongly discouraged as an ANTI-PATTERN (!) and certainly not recommended at this kind of site (objectmentor with Robert C Martin) with a good reputation.
/ Peter
Dean wrote: ”…just put the data in a map (or list) ... hash maps? Why do we have them in Java, etc. in the first place? ...”
I think it is very disturbing and surprising to see hash tables are being recommended on this site which is associated with the publisher of books about how to write Clean Code and applying SOLID principles.
Why we have hash maps ? Well, as long as we use them for internal private usage only (and of course without exposing a public getter to the mutable “private” hash table that would destroy the encapsulation) they can be useful for example to implement a table look up (i.e. as an alternative to if/switch statements), for example a parameterized factory method might return Command objects from a typed hashmap with a key lookup.
Regarding the comparison with HttpSession, I would say that one should make a distinction with domain/application specific code and the code that is intended for being used in all kind of applications. In other words, in your own application code you should use your own domain abstractions, but if you create an application framework (e.g. the servlet API with HttpSession) which is intended for all kind of domains then it is hard to avoid all usages of things that generally should be avoided such as using Object in method signatures (as in the method “Object HttpSession.getAttribute(String)” ).
Another thing worth mentioning, regarding making a distinction between domain/application code and generic code is the usage of reflection. The reasoning (about why it exists if we should not use it) is similar, i.e. reflection is hard to avoid for creating frameworks such as Hibernate that should support all kind of domain objects. Otherwise reflection should be avoided in runtime (but can be used in design time, for code generation) not because it is difficult to write reflection but difficult to maintain due to its worthless semantic.
Regarding sending around hash maps in PUBLIC method signatures, it is an awful anti-pattern that should never be considered as even remotely acceptable. I have seen a system where virtually all method signatures were very “generic” :-( and received one hashtable as input parameter and returned another hashtable. Within the methods, the hashtables were often passed on to other methods, which sometimes populated them with more values or even removed values, and of course you can never feel sure that you do not break any code in such a system (assuming you do not have great unit/integration test coverage for your semantic-less hashtables) i.e. you do not dare to change more than you really have to, and it is NOT refactoring-friendly.
It is not only difficult to change existing code when using hash tables, but you will aso get problems when you want to try to reuse (e.g. invoke) an existing method, since it is difficult to get the whole picture about what kind of parameters the hashtable need to contain in the invocation. If you look in the method, it is not enough but you also have to keep looking in the all other methods that are invoked from within the method… Typically, you have to debug the method to get a feeling of what kind of stuff you have to push into the hashtable.
Please also keep in mind that if you want your code base to be considered as being good, then you should not have to even look in the implementation code, and definitely you should not have to debug it to understand it.
The hash table oriented architecture should really be strongly discouraged as an ANTI-PATTERN (!) and certainly not recommended at this kind of site (objectmentor with Robert C Martin) with a good reputation.
/ Peter
Object-Oriented Programming DOES NOT EQUAL Object-Oriented Analysis & Design.
Functional programming is an excellent technique for code implementation, as it is more amenable to program proof techniques, is easier to test (stateless, no side effects), and does not require code to be littered with locks (the mainstream imperative OOP languages solution for concurrency).
Objects in the large, functions in the small.
@Dean, I think that SOA really helps to simplify overcomplicated OOP design. In short: leave to an object what really belong to an object, move complex interactions between objects, which are not cohesive to any single object to service layer. Udi Dahan gave an interesting talk on this matter on InfoQ: http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan. There is another attempt called DCI architecture (http://www.artima.com/articles/dci_vision.html) and fiercely criticized by John Zaborsky (http://www.artima.com/forums/flat.jsp?forum=226&;thread=253008&start=0&msRange=100). While I mostly agree with his arguments on DCI, I strongly disagree with his OOP-above-all attitude. SOA really helps. And, of course, functional approach greatly simplify things.
@Dean, I think that SOA really helps to simplify overcomplicated OOP design. In short: leave to an object what really belong to an object, move complex interactions between objects, which are not cohesive to any single object to service layer. Udi Dahan gave an interesting talk on this matter on InfoQ: http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan. There is another attempt called DCI architecture (http://www.artima.com/articles/dci_vision.html) and fiercely criticized by John Zaborsky (http://www.artima.com/forums/flat.jsp?forum=226&;thread=253008&start=0&msRange=100). While I mostly agree with his arguments on DCI, I strongly disagree with his OOP-above-all attitude. SOA really helps. And, of course, functional approach greatly simplify things.
... When I mentioned SOA I’m not necessary meant Web Services, but rather a broader approach of moving functionality, which doesn’t belong to a simple object, to “sevice” or “manager” layer. A good introductory example of it (using C# static manager classes) is shown in “N-Layered Web Applications with ASP.NET” articles by Imar Spaanjaars http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=476. When we implemented our application following Imar’s approach, we found that functional constructs (like using LINQ extension methods of Where(), Select() , etc. instead of loops and using lambda expressions instead of stupid object wrappers) greatly simplify service layer. Also, things like extension methods in C# / implicits and traits in Scala improve OOP, make it more flexible.
are much more severe: diseases than epidemics. In Alaska, a state with a person that has Ordering Tamiflu
I think OOP in some form will be around for a long time. Although how it is leveraged may change considerably.
Very interesting. I think we are entering a very interesting time when it comes to the evolution of programming languages. With increased computing power I believe the way we go about designing and coding software is on the verge of revolutionary changes.
Very nice article, thank you.
Warning 1: Dean mentioned his favored usage of OO in a pretty controversial way; he could have brushed the truth in a more amenable way to strong OO proponents. In any case, with proper knowledge and experience, his way of putting it makes a lot of sense.
Warning 2: This article could mislead the reader into thinking that polymorphism is only available through object orientation.
That said, the fact that FP has access to much more powerful types of polymorphism than is ever possible to use in typical OO just makes this article’s conclusions even much more true!
Thanks again.
Welcome to Freshstyleshop, the hottest urban clothing site on the net! We offer great products from Gucci sneakers, prada sneakers, LV shoes, True Religion Jeans and many more! Our selection of products are always increasing for the fact that we have new items added weekly to our selection. All products on our site are already marked down 40-60% off retail price. Freshstyleshop also backs all its orders with a 110% satisfaction guarantee, making sure that our customers are left satisfied with the hottest products on the net.
Welcome to Freshstyleshop, the hottest urban clothing site on the net! We offer great products from Gucci sneakers, prada sneakers, LV shoes, True Religion Jeans and many more! Our selection of products are always increasing for the fact that we have new items added weekly to our selection. All products on our site are already marked down 40-60% off retail price. Freshstyleshop also backs all its orders with a 110% satisfaction guarantee, making sure that our customers are left satisfied with the hottest products on the net.
Buy mens belts with a price guarantee and top rated customer service. You can compare multiple mens belts styles and find exactly your size and width.
Largest selection of discount Timberland Boots for sale, Saving a lot at our Timberland Outlet Store. We assure you of our Best Services at all times.