8

Possible Duplicate:
Are design patterns really language weaknesses?

After spending years pouring over books on OOP and the techniques of OOP, and recently getting involved more and more in Functional Styles of programming, would it be fair to extrapolate that design patterns are pointers to systemic problems with Object Oriented programming as a whole. Is there a fundamental flaw in Object Oriented Programming (not to be confused with Design), in that in the treatment of state through encapsulation, has led to more and more patterns to resolve the problems with such a paradigm.

I have not come to any conclusions on this, but my "gut" feeling is that there might be something more seriously wrong with the paradigm of OOP.

Is the very idea of encapsulation causing more problems than they solve.

Community
  • 1
  • 1
WeNeedAnswers
  • 4,620
  • 2
  • 32
  • 47
  • See http://stackoverflow.com/questions/1579162/are-design-patterns-really-language-weaknesses. –  Jan 30 '11 at 16:21
  • 2
    Are there no patterns that are followed while programming with functional languages? I think there just hasn't been the same level of effort in recognizing and documenting them. My experience with coding using functional languages is that I find myself creating the same general sorts of functions quite often. This is an interesting question - as OOP certainly hasn't been around longer than FP. Perhaps FP's patterns are simple enough that they seem common sense / inevitable, and hence aren't documented to the same degree? – jhouse Jan 30 '11 at 16:28
  • everything follows a pattern I agree, but usually they form a basis to the language. Design patterns are different in that they form around the language but not in the language design itself. – WeNeedAnswers Jan 30 '11 at 16:34
  • http://blog.adaptivesoftware.biz/2009/08/lack-of-design-patterns-in-python.html nice presentation. Think I agree with him – WeNeedAnswers Jan 31 '11 at 02:06
  • In functional languages, you need some incomprehensible pattern just to implement an algorithm that is expressed using conditional branching and assignment to variables. – Kaz Dec 10 '13 at 05:13

5 Answers5

6

A very good question and something that I have thought about some time ago. This is my conclusion \ opinion:

  1. The idea of object oriented programming is not without flaws, but does provide the most complete design paradigm. If the problem domain is expressed properly, clearly defined object, who knows their responsibilities, can interact in a fairly elegant way, that closely resembles the real world interaction of the objects. (or ideas).

  2. To make some of the more abstract concepts, specific, OOP makes some assertive statements. (Like encapsulation, not expose more than you have to and object responsibility).

  3. Like all generic assumptions, there would be exceptions, when what normally would be a good idea, may not fit a particular problem in hand. It is also not helped by the fact that OOP, covers almost all problem conceived ( unlike AOP or even the more complex semantic modeling, that caters to a specific kind of problem).

  4. So in situations, when you need to make exceptions and move away from OOP assertions, the designers needed a way to keep in bounds of good design, so that they do not stray far too much from accepted design practices.

  5. So design patterns, for me is just case studies of problems, that will not be served by some of the core assertion of OOP. Apart from collaboration and collation of solution, design pattern also helps augment OOP. (especially for newbie designers).

Note: Most of the time, design patterns are not needed. There needs to be, clear justification for using patterns. I know, some greenhorns, trying to implement some design pattern, just because they know them ( and sometime not so greenhorns ;)). Its square peg, round hole problem

uncaught_exceptions
  • 21,712
  • 4
  • 41
  • 48
  • Nice answer. I would like to point out that I am a keen advocate of OOP and OOA especially. Some of the patterns have become core parts to the language. For example cross cutting concerns. If the pattern is used in every application, should it thus become lore of the language and integrate more? – WeNeedAnswers Jan 30 '11 at 17:09
  • A good example as someone posted above from another post, is the use of events in c#, being based on the observer pattern. – WeNeedAnswers Jan 30 '11 at 17:15
  • Are we not having the same discussion @Mattis comment thread ? lol. Anyways I agree with you on that. Some people do believe that some patterns should be first class OOP practices. So I guess, any design pattern, that is not a workaround and can be applied to universally, is candidate for being incorporated in the language ( this is what drove Spring right?). – uncaught_exceptions Jan 30 '11 at 17:23
  • There are plenty of frameworks out there, new books, new designs, new messiahs shouting their solutions from the pulpit. I just get the feeling that if there are so many problems that need to be solved by "bolting on" an addition to the "with batteries" core of the language, is there something fundamentally wrong with the original premise of OOP. Many of the problems are so fundamental to good design that its getting harder and harder to provide solutions with just the core frameworks (c#, Java). – WeNeedAnswers Jan 30 '11 at 21:23
1

Good question, I started wondering about this my self a few weeks ago whilst getting more into Python and Scala.

I think yes and no. There are definitely some intrinsic problems with OOP and the encapsulation of state, but it's not to say that OOP itself is inherently a bad way of doing things. I think the problem is that when all you have is a hammer everything becomes a nail. OOP is great for some things, GUIs come to mind first but functional programming has very clear benefits as well.

It's worth noting that the newer functional programming languages like Scala haven't thrown objects away.

I haven't thought about the issue in great detail but I certainly agree that OOP has some issues that I haven't seen addressed, other than in the form of design patters, which really are addressing the symptoms rather than the disease.

Matti Lyra
  • 12,828
  • 8
  • 49
  • 67
  • I am a keen advocate of OOP, but every now and again I think hmmm, there is something there but I can't put my finger on it. I am hoping someone will point out what it is that I am failing to grasp myself. I attended a meeting last week where they were waxing lyrically about IOC and Inversion of Control Containers, I had the same gut feeling. – WeNeedAnswers Jan 30 '11 at 16:29
  • @WeNeedAnswers, I think, the problem is the hunt for "Silver Bullets". There is no single, solution, just that some solutions are more applicable than others. ( and IOC is just a pattern with in OOP, and it is possibly one of the easiest way to have a good design) – uncaught_exceptions Jan 30 '11 at 16:38
  • A good design or a workaround to a problem with the paradigm? – WeNeedAnswers Jan 30 '11 at 16:41
  • I disgree, its not a workaround. OOP does not talk about how to instantiate objects. IOC just is an Implementation detail. It says, if you can manage object interactions, without the objects, themselves taking part in it, you will get a more loosely coupled, better testable applications. – uncaught_exceptions Jan 30 '11 at 16:48
  • IOC is fundamental to loose coupling. Class Responsibility Collaboration techniques (CRC) naturally will give you loose coupling in OOA. Using an IOC Container class is much more fundamental in my opinion to good code. However if you look at the problem using FOP and FOA, its all about transformations and composition of functions that act upon data. The Analysis is different in both, but here I wish to get to the nub of OOP with the use of Design Patterns, should the patterns become part of the language? – WeNeedAnswers Jan 30 '11 at 16:58
  • Some people do believe that some patterns should be first class OOP practices. So I guess, any design pattern, that is not a workaround and can be applied to universally, is candidate for being incorporated in the language ( this is what drove Spring right?). – uncaught_exceptions Jan 30 '11 at 17:13
  • If there is an analogy, good design is like saying to programmer , "Love what you do, the rest will follow". But in some cases introduction of new terminology\methodology makes us revisit previous assertion. For instance, when we started using RMIs, we found out that network latency is an issue and did not want a chatty system . Cue the session facade. (which I hate by the way).This is a plain workaround. – uncaught_exceptions Jan 30 '11 at 17:17
  • I think there has been confusion in the last couple of years of what Objects are. Components and services are far removed from the days of CORBA. I like components and services as they do not rely on programming paradigms. Or do they (pipes, filters, sinks, endpoints etc)? – WeNeedAnswers Jan 30 '11 at 21:36
1

No. Although you see slightly different design patterns, you certainly still see design patterns in functional code as well. The basic difference has little (if anything) to do with lack of state. Rather, it stems primarily from (most) functional languages providing enough more versatility in creating functions that what would be a "design pattern" in another language simply becomes a function in a functional language.

If you provide a (roughly) similar level of versatility in a language that has state, you can get the same effect. Just for example, most of the introduction to Modern C++ Design is defending the position that a design pattern can be encoded as a template (and most of the book is design patterns implemented as templates).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Nice answer, leads me to thinking that there is a problem with OOP. – WeNeedAnswers Jan 30 '11 at 17:02
  • 2
    @WeNeedAnswers: The problem isn't with OOP. The problem is with languages. – Jerry Coffin Jan 30 '11 at 17:08
  • as in implementation of OOP or the lack of multi-paradigm support? – WeNeedAnswers Jan 30 '11 at 17:16
  • @WeNeedAnswers: I'm not sure it really falls into either category. – Jerry Coffin Jan 30 '11 at 17:31
  • can you give me a category, maybe this is the thing I am missing. :) – WeNeedAnswers Jan 30 '11 at 17:46
  • So if all languages had the templating features of C++, would this make patterns redundant or would be still using Design patterns, but in another form? – WeNeedAnswers Jan 30 '11 at 18:02
  • Templates suffice for some patterns, but not others. Even an "expanded" version that sufficed for more current design patterns would simply lead to our recognizing patterns that happen on an even larger scale. – Jerry Coffin Jan 30 '11 at 18:07
  • So anything defined in stone in a programming language could be regarded to a hard core C++ programmer as sugar. The problem I find with C++ is this very freedom, and the abuse of it, by very average programmers. When Java and later C# came on the scene, I liked the idea that there was only so many places a programmer had the freedoms to do what they wanted. I think though, that this lack of freedom might be stifling. Is this the ungraspable truth? – WeNeedAnswers Jan 30 '11 at 21:50
0

I think there will invariably be problems when you try to apply a single programming paradigm to a problem. That's why I like C++: it's multi-paradigm; it doesn't force you into a single set of solutions.

Reinderien
  • 11,755
  • 5
  • 49
  • 77
  • Well thats bad news for C# and Java users, they have been forced into a paradigm though the language constructs of the language. Interesting comment about multi-paradigm language. – WeNeedAnswers Jan 30 '11 at 16:39
  • You can always "break" out of those languages. For example, in C# you can make one big huge class full of static methods if you desperately want it to look more like C. – Reinderien Jan 30 '11 at 16:44
  • No, I think if your going to use one of those languages, I think you got to play to the strengths of the language. C# and Java are excellent languages in most regard. But every now and again......there is something not quite right. I never had these same issues when using Delphi, maybes its a sign of simpler times or as you correctly point out the multi-paradigm is useful. – WeNeedAnswers Jan 30 '11 at 17:05
  • I didn't say breaking the language was a good idea, just that it's possible. – Reinderien Jan 31 '11 at 20:53
0

I am repeating a basic theory of mine, but models are just that - only models. The model defined by OOP is a very effective way to structure a program, and for many application programming domains, is entirely appropriate. For some problem spaces, the model may become decreasingly effective (or less efficient, or both).

A potential metaphore exists with physics. For many, many years Newtonian physics did (and in fact, still does) a remarkable job of modelling the laws of motion, time, and space (with some help from euclidian and sperical geometry). But when science began probing into the micro-and macro aspects of the problem space, Newtonian physics (AND euclidian/Spherical geometry) begin to break down. Hence we now have Relativity and quantumn mechanics. These do a fantastic job of modelling the universe at the macro and micro levels respectively, but are overly convoluted for use as descriptors of every-day, human-scale events.

OOP is very effective for application programming in a lot of cases, when considered in the context of the complexity involved with modelling real-world problems and human interactions for consumption and processing by a linear machine. As someone above observed, there are no silver bullets. And my impression (having never used C++) is that languages which attempt to be multi-paradigm also become more complex, and not necessarily as efficient for smaller problems more easily handled with a higher-level, more targeted language. Much like Quantumn mechanics and/or relativity theories (I mean, really, is anyone interested in the relationship between mass and velocity when travelling at 60 MPH on the freeway? OR the probability of Los angeles being where you expect it to be when you arrive?).

In my impression, adherence to qa specific model is important, so long as the model is suited to the problem space. At the point when this stops being true, the model may need to evolve, and there will be resistence to this. There will be attempts to force the problem space into a model not suited (review the history of physics again, or check into the evolution of the helio-centric model of the solar system, and include the key word "epicycles").

All of the above is simply MY best understanding of the state of things, and if I have missed the mark somewhere, I am happy to hear some contrary news.

XIVSolutions
  • 4,442
  • 19
  • 24
  • In reference to my C++ Comment, I use "efficient" in the sense that a higher level language my be more easily used to address the problem, NOT that C# or Vb are going to be more efficient in terms of performance. Also, of course, one is most efficient in the language with which one is familiar. But from the little I KNow of C++, applying to solve day-to-day business problems faced by mid-sized IT departments in enterprise environments would be overkill (for example). – XIVSolutions Jan 30 '11 at 17:17
  • I think that there should be some separation from OOA and OOP. I agree OOA has not let me down, ever. Come to that neither has OOP with knowledge of patterns. But and here it comes, there seems to be an ever growing list of patterns, and I would add that if just a third of these patterns are fundamental to making OOP work, is there a flaw with OOP. If so, can we get a handle on it. If we know what the flaw is, then all patterns will resolve themselves with maybe a new language, new paradigm etc. – WeNeedAnswers Jan 30 '11 at 21:40
  • I think that Design Patterns are incredibly useful ways to express the implementation of OOP for a particular situation. If you consider OOP to be analogous with Geometry, then the core principles of OOP would be analogous to the Axioms and postulates of that discipline. And design patterns might be analogous to the various theorems by which the rest of geometric structure is derived. Note, this analogy even holds up for those places in which a particular geometry fails.Classic euclidian geometry, works very well, until one encounters a spherical surface. – XIVSolutions Jan 30 '11 at 22:23
  • . . . at which point, the model begins to fail. While you can FORCE the rules of euclidian geometry to approximate those same shapes on a round surface, the model eventually runs out of places to go, and instead a new, somewhat specialized model is needed. One must re-define the nature of a straight line when applying the concept to a spherical surface. – XIVSolutions Jan 30 '11 at 22:27
  • I consider design patterns to be the expreesion of OOP for a particular set of circumstances. You will note that there are those pattersn used quite frequently, and those which only rear their head every now and again. But the evolution of new patterns, to me, does not indicate a flaw in OOP as a practice. Only that there are a multitude of problem spaces, for which someone, somewhere, feels the need to define a new pattern as the solution. Desing patterns might also be likened to equations. There are many ways to express most functions, but there is usually ONE which is simplest. – XIVSolutions Jan 30 '11 at 22:31