Do Design patterns in Object Oriented Programming signal systemic problems of the paradigm of OO? [duplicate]_问答_开发者

This question already has answers here: Closed 12 years ago.

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 progra开发者_StackOverflow社区mming, 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.

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

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).
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).
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).
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.
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

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.

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).

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.

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.