关于面向对象编程的一些摘录

[1] Understanding Object Oriented Programming  --http://www.csis.pace.edu/~bergin/patterns/ppoop.html

[2] Patterns for Objects -- http://www.csis.pace.edu/~bergin/patterns/PatternObjects.html

[3] OOP Story -- http://www.csis.pace.edu/~bergin/patterns/oopstory.html

[4] OOP vs NOOP -- http://www.clear.rice.edu/comp212/99-fall/handouts/week1/person

[5] Once And Only Once --  http://c2.com/cgi/wiki?OnceAndOnlyOnce

[6] Object Orientation Isa Hoax -- http://c2.com/cgi/wiki?ObjectOrientationIsaHoax

[7] Object Oriented Programming Fundamentals -- http://www.jamesbooth.com/OOPBasics.htm

[8] An Interview with A. Stepanov -- http://www.stlport.org/resources/StepanovUSA.html

[9] Aspect Oriented Programming -- http://c2.com/cgi/wiki?AspectOrientedProgramming

[10] Object Orientation Isa Hoax(cn version) -- http://coolshell.cn/articles/3036.html

[11] OOP Isn't a Fundamental Particle of Computing -- http://prog21.dadgum.com/156.html

[12] Don't Distract New Programmers with OOP -- http://prog21.dadgum.com/93.html

[13] 如此理解面向对象编程 -- http://coolshell.cn/articles/8745.html

[14] -- Rob Pike comments on [1] https://plus.google.com/101960720994009339267/posts/hoJdanihKwb#101960720994009339267/posts/hoJdanihKwb

[15] Premature Optimization -- http://c2.com/cgi/wiki?PrematureOptimization

[16] The Cathedral and the Bazaar -- http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

[17] Why Arc Isn't Especially Object-Oriented -- http://www.paulgraham.com/noop.html

[18] 10 Object Oriented Design principles Java programmer should know -- http://javarevisited.blogspot.de/2012/03/10-object-oriented-design-principles.html

[19] Object Orientation Is Dead -- http://c2.com/cgi/wiki?ObjectOrientationIsDead

 

I’m not teaching technologies. I just trigger thoughts on it. Don’t try to persuade s.b., you can only influence him.  

 

Am I OOP if I can write class?

 

IOP -- Intuition Oriented Programming[xhx]

 

POP -- Procedure Oriented Programming

 

MOP -- Money Oriented Programming

 

Design Pattern Oriented Programming[10]

 

Agile Oriented Programming[10]

 

Aspect Oriented Programming[10]

 

 

Q: Procedural programming (PP)? OOP? Functional programming(FP)?

 

Q: What’s the difference between designer and architect?  

 

Q: Difference between principle and pattern

 

Q: What is OO really; is it a real paradigm, different from procedural programming or is it just a packaging mechanism for procedural programming?[1]

 

Both of the authors believe that it is a real paradigm shift, requiring a change in mental model in the practitioners.[1]

 

PP: Top to down. Break tasks to sub tasks.

 

Every “if” and every “switch” should be viewed as a lost opportunity for dynamic polymorphism. If we can replace this with dynamic polymorphism then the program will be much easier to maintain.[1]

 

Note that there is NO ad-hoc polymorphism here except the single test for null in the factory. [1]

 

ad-hoc polymorphism seems like “if” or “switch” statements.

 

Whether it is clear or not, the mental processes of the programmers who wrote these different versions was quite different. The hacker wanted to get the immediate job done at all cost. The procedural programmer views the nature of computation as a decomposition of a function into sub-functions (helper functions) that solve sub-problems. The object-oriented programmers see the nature of computation as a swarm of interacting agents that provide services for other objects. Further, the sophisticated OO programmer lets the system take care of all polymorphic tasks possible. This programmer sees the essence of object oriented programming as the naive object-oriented programmer may not.[1]

 

Object-oriented programs are collections of interacting objects. The objects exhibit behavior and the behavior is encapsulated within the objects so that each object knows what it it capable of.[2]

 

program = data structure + algorithm

 

Pull your own weight;Avoid duplication;Iterate the Design[2]

 

Finding objects

look for the nouns

One major responsibility

think client-server

Connect clients to servers

model the real world

avoid indirect communication

avoid communication bottlenecks[2]

 

When an object asks another for a service, the asker is taking a "client" role and the askee is taking the "server" role.[3]

 

A "Program" is both a description of objects and the behavior that is allowed for each kind of object, and a description of what it is that we want the objects to actually do. The description of the objects must include descriptions of how they carry out their services.[3]

 

A "class" is that part of a program that is a description of a set of objects of the same kind. We sometimes say that the objects are in their class or that they have a class.[3]

 

When we ask an object to perform a service, the request is called a message. A message can contain additional information called arguments (sometimes parameters) that help the server determine exactly what is wanted. These arguments can actually be objects, or perhaps simpler things.[3]

 

"Object Oriented Programming is just a structuring method for procedural programming, rather than a new paradigm."[4]

 

The key to this design is the representation of the abstract notion of a person as an abstract class with an appropriate abstract behavior.   This abstraction of behaviors together with polymorphism allow us to hide away explicit state checking control structures in our code, reducing code complexity.[4]

 

Writing a program using classes does not automatically qualifies it as object-oriented as the above two designs illustrate.  It is the object-oriented thinking (OOT) behind the design of a program that makes it object-oriented.[4]

 

This way of thinking puts the emphasis on first identifying the abstract behaviors of a system instead of the data it must have.[4]

 

 

OOP is a translation of the (mental) model OOT creates into the form of a program .  In theory, OOP can be done via a Turing machine, :-).  But I prefer to use a convenient object-oriented language (OOL) to implement object-oriented designs (OOD).[4]

 

One of the main goals (if not the main goal) when ReFactoring code. Each and every declaration of behavior should appear OnceAndOnlyOnce. Conceptually analogous to normalization in the RelationalModel. See also DontRepeatYourself.[5]

 

OnceAndOnlyOnce is not a pattern. A pattern is something you can teach someone to do in a fairly short amount of time. A day, usually. Perhaps a few weeks. But learning how to refactor classes to form a TemplateMethod does not help you see how to use XML to represent your user interfaces (a recent OnceAndOnlyOnce technique applied to Squeak), or how to make a good virtual machine. These are patterns; OnceAndOnlyOnce is not a pattern. OnceAndOnlyOnce is a principle. -- RalphJohnson [5]

 

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work. --Alexander Stepanov (father of STL) [6]

 

Q:Can I summarize your thinking as "find the [generic] data structure inside an algorithm" instead of "find the [virtual] algorithms inside an object"? Yes. Always start with algorithms.  --Alexander Stepanov (father of STL)  [8]

 

 

Types are usually either tree-based or a list of mutually-exclusive options. It is possible to have multiple orthogonal dimensions by which to group or divide things by, and this tends to be anti-type. For example, types become messy if we try to make Employee types. We might have Manager and Non-manager. But we could also have Part-time and Full-time. But these can be orthogonal. We could have a part-time manager, for example. Thus, either we have a jillion competing "types" (MultipleInheritance?), make a goofy tree (see soda example at LimitsOfHierarchies), or we turn them into attributes of an "instance" of employee and toss the idea of types altogether.[6]

 

Confusing types with attributes in this way is the kind of thing I've learned to expect from someone just starting on OOP. It imposes on Object the Relational idea that identity is tied to attributes; it's not. That's why DBAs are the last to grasp Object concepts. –mt[6]

 

"So what is OO? Certainly not every good program is object-oriented, and not every object-oriented program is good. If this were so, "object-oriented" would simply be a synonym for "good," and the concept would be a vacuous buzzword of little help when you need to make practical decisions. I tend to equate OOP with heavy use of class hierarchies and virtual functions (called methods in some languages). This definition is historically accurate because class hierarchies and virtual functions together with their accompanying design philosophy were what distinguished Simula from the other languages of its time. In fact, it is this aspect of Simula's legacy that Smalltalk has most heavily emphasized.

 

Defining OO as based on the use of class hierarchies and virtual functions is also practical in that it provides some guidance as to where OO is likely to be successful. You look for concepts that have a hierarchical ordering, for variants of a concept that can share an implementation, and for objects that can be manipulated through a common interface without being of exactly the same type. Given a few examples and a bit of experience, this can be the basis for a very powerful approach to design.

 

However, not every concept naturally and usefully fits into a hierarchy, not every relationship among concepts is hierarchical, and not every problem is best approached with a primary focus on objects. For example, some problems really are primarily algorithmic. Consequently, a general-purpose programming language should support a variety of ways of thinking and a variety of programming styles. This variety results from the diversity of problems to be solved and the many ways of solving them. C++ supports a variety of programming styles and is therefore more appropriately called a multiparadigm, rather than an object-oriented, language (assuming you need a fancy label)." – BjarneStroustrup(designer of c++) [6]

 

In principle, OO is simple. If I have those wonderful 5 properties listed in Booch's book (abstraction, specialization, encapsulation, inheritance, polymorphism,communication, reuse), I have object orientation. However, Stroustrup's comment is much closer to the point.OO is not about creating a set of classes with interfaces defining their actions. In fact, that is closer to *modular* programming than OO programming. OO is about creating a set of data-centric objects whose behaviour is defined by their mutual interactions. People ask me how I can write large C++ programs where no method is larger than 10 lines. The answer is that the functionality is defined by the structure of the objects, not in the methods. There is a huge set of misconceptions about OO that have arisen from our naive understanding in the 1980s and early 1990s. People who cling to these misconceptions are not stupid, but they are self limiting. It takes a long time and a lot of effort to grok this stuff. After 13 years I feel like I've only scratched the surface. In fact, I feel like there is a huge universe out there waiting to be discovered.[6]

 

And very wrong, too. I have four of Booch's five properties in FunctionalProgramming, only inheritance is missing. Does that make FP the same as OOP? Of course it doesn't, I'd have to add in inheritance, too, wouldn't I? But that's pointless, since delegation works so much better. It follows, that OOP is crap, quite probably defined in an ad hoc way just to extract more money from gullible programmers. I rest my case.[6]

 

Object orientation, these words can wreak havoc in the minds of developers everywhere.  It doesn’t need to be this way though.  Object orientation is actually a much more direct method of mapping business problems to program code than any methods we have had in the past.[7]

 

 

However, object orientation requires that we adjust the way we think about what we do.  Changing methodology is fairly easy.  Most of us have learned more than one programming language in our careers and it wasn’t the end of the world. But changing the way we think, well that is another beast altogether.[7]

 

Object orientation is an approach to software development in which we focus on objects and their attributes and responsibilities.[7]

 

One interesting part of object orientation is that it closely parallels the real world, much more so than the traditional structured approach of system design.  [7]

 

A class is the definition, or blueprint, for an object.  [7]

 

The concepts of OO can seem academic, but they are important.  The major difference between procedural programming and object oriented programming is how we think about what we do.  Just as there is good and bad procedural code, there is also good and bad object oriented code.  The things that make code good or bad don’t change, just the approach to writing it changes.[7]

 

Abstraction -- This is the ability to represent a complex problem in simple terms.

Specialization -- specialization is the ability to make lower level subclasses more detailed than their parent classes.

Encapsulation -- encapsulation is really the process of making an object as self sufficient as is possible.

Inheritance -- is the ability of one class to incorporate all or part of another class’s definition in its own definition.

Polymorphism -- The general definition of polymorphism is the ability of different things to use the same name.

Communications -- How do objects communicate?  By calling methods or assigning values to properties

Reuse -- new tools that allow for an even better level of reusability.

Inherent polymorphism -- The ability of an operation to apply to different classes.(virtual functions of C++. Dynamic polymorphism. Commented by xhx)

Ad Hoc polymorphism -- Ad Hoc polymorphism is defined as the ability of different operation of different types to have the same name. (function overload or “if” “switch” statement. Static polymorphism. Commented by xhx)[7]

 

As the chief proponent of Java at SGI told me: "Alex, you have to go where the money is." But I do not particularly want to go where the money is - it usually does not smell nice there. [8]

 

AOP -- Advanced preprocessing, where you can say things like: "Take every method that starts with the word 'test', and add it to a list of methods to be run when testing." Allows one to centralize CrossCuttingConcerns that would otherwise appear in many different classes. AOP is motivated by "SeparationOfConcerns". It enables abstraction and modularization of a different kind than OOP provides. [9]

 

If we look back, using POP (Procedure-Oriented Programming), we must deal with all the concerns in a line. Though we can outsource the code into different functions, the main stream still controls all the process. This is the linear model. When OOP is introduced, we can present the world in a more natural way by describing different objects and their functions. Connections between different objects form a network, a matrix of type vs. behavior. This can be called the two-dimensional model. Then AOP comes along and tells us that the change from POP to OOP is not complete and the world need more dimensions. This cross-cutting, distributed code can be seen as interconnections over and beyond the two-dimensional networking that OOP produced. Rules can be well tangled with the objects they govern. If the system is small, it will not be a problem. But if the system is big enough, these crosscutting concerns can significantly bloat the objects, and AOP should be applied. Aspect oriented programming allows one to pick out a set of "join points" within the program, and then specify code ("advice") that should run at each of these points. This allows one to achieve OnceAndOnlyOnce in a new way.

 

It's not that OOP is bad or even flawed. It's that object-oriented programming isn't the fundamental particle of computing that some people want it to be. When blindly applied to problems below an arbitrary complexity threshold, OOP can be verbose and contrived, yet there's often an aesthetic insistence on objects for everything all the way down. That's too bad, because it makes it harder to identify the cases where an object-oriented style truly results in an overall simplicity and ease of understanding. [11]

 

The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture.[12]

 

Rob Pike是当年在Bell lab里和Ken一起搞Unix的主儿，后来和Ken开发了UTF-8，现在还和Ken一起搞Go语言。[13]

 

我觉得，这篇文章的例子举得太差了，差得感觉就像是OO的高级黑。面向对象编程注重的是：1）数据和其行为的打包封装，2）程序的接口和实现的解耦。[13]

 

 

OOP的本质就是——对数据和与之关联的行为进行编程。-- Rob Pike [13]

 

我以前给一些公司讲一些设计模式的培训课，我一再提到，那23个经典的设计模式和OO半毛钱关系没有，只不过人家用OO来实现罢了。设计模式就三个准则：1）中意于组合而不是继承，2）依赖于接口而不是实现，3）高内聚，低耦合。你看，这完全就是Unix的设计准则。-- 陈皓 [13]

 

 

Object-oriented programming, whose essence is nothing more than programming using data with associated behaviors, is a powerful idea. It truly is. But it's not always the best idea. And it is not well served by the epistemology heaped upon it. Sometimes data is just data and functions are just functions. -- Rob Pike [14]

 

Just search a small table! No objects required. Trivial design, easy to extend, and cleaner than anything they present. Their "hacker solution" is clumsy and verbose. Everything else on this page seems either crazy or willfully obtuse. The lesson drawn at the end feels like misguided epistemology, not technological insight. -- Rob Pike [14]

 

It has become clear that OO zealots are afraid of data. They prefer statements or constructors to initialized tables.[14]

 

But there's good news. The era of hierarchy-driven, keyword-heavy, colored-ribbons-in-your-textook orthodoxy seems past its peak. More people are talking about composition being a better design principle than inheritance.[14]

Before people complain about OO programming, they should be sure to understand not only what OO means but what it doesn't mean. -- Bob Wyman [14]

 

separation of interface from implementation[14]

 

 

Premature optimization is the root of all evil – Donald Knuth [15]

 

In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."[15]

 

My own feeling is that object-oriented programming is a useful technique in some cases, but it isn't something that has to pervade every program you write. You should be able to define new types, but you shouldn't have to express every program as the definition of new types.[17]