什么是OOP的Jargons和复杂性 [英] What are OOP's Jargons and Complexities
问题描述
什么是OOP'的Jargons和复杂性
Xah Lee，20050128
类，方法，对象
在计算机语言中，函数定义通常如下所示：
子程序f（x1，x2，...）{
变量...
这样做或那个
}
在LISP系列等高级语言中，这种情况并不少见
定义函数内的函数。例如：
子程序f（x1，x2，...）{
变量...
子程序f1（ x1 ...）{...}
子程序f2（x1 ...）{...}
}
通常这些f1 f2内部函数在f中使用，而不是在f之外相关的
。这种语言的力量逐渐发展成为一种编程风格。例如：
子程序a_surface（）{
coordinatesList = ...;
子程序翻译（距离）{.. 。$
子程序旋转（角度）{..}
}
这样的风格是a_surface不再作为一个函数被视为。
而是一组盒装函数，以一块
数据为中心。而且，操作这个数据的所有函数都是在这个函数中体现的
。例如：
子程序a_surface（arg）{
coordinatesList = ...
子程序translate（distance）{set coordinatesList翻译
版}
子程序旋转（角度）{将coordinatesList设置为旋转版本}
子程序return（）{return coordinatesList}
if（no arg）{什么都不做}
else {apply arg to coordinatesList}
}
通过这种方式，人们使用a_surface作为捆绑的基准片段
及其自己的一组功能：
mySurface = a_surface //将子程序分配给变量
mySurface（旋转（角度））//现在表面基准已经旋转
mySurface（翻译（距离））//现在翻译
newSurface = mySurface（return（））
现在，a_surface不再被视为子程序，但是盒装套装
以一条基准为中心的东西。所有用于
基准的函数都包含在盒装集中。这种范式可能在
函数式语言中得到了很大的改进，以至于它扩展到其他的b $ b组并被称为面向对象编程，并且完成了
出现了这种方案的新语法语言。
在这些语言中，不要像这样写它们：
mySurface = a_surface;
mySurface（旋转（角度））;
语法改为这样，例如：
mySurface = new a_surface（）;
mySurface.rotate（angle）;
在这些语言中，超级子程序a_surface不再被称为
a函数或子例程。它现在被称为a ?? Classa ??。现在，
变量保存了函数mySurface。现在被称为a ?? Objecta ??。
函数a_surface中的子程序不再被称为inner-
子程序。它们被称为?? Methodsa ??。将超级
子例程分配给变量的行为称为实例化。
这种编程和语言风格变得如此狂热，以至于
像Java这样的专用语言，语言中的所有内容都是
类。人们不能只定义一个变量或子程序。
相反，我们定义了这些具有内部
子程序（方法）的超级子程序（类）。每行代码现在都在这样的超级
子程序中。并且将子例程分配给其他
子例程中的变量以创建对象。一个人通过这些对象调用内部子程序
（方法）？变量来操纵超级子程序中定义的数据
。以这种方式，即使是基本原语，例如数字，字符串和列表也不再是原子实体。它们现在是带有内部子程序的子程序。
例如，在Java中，字符串是一个String类。在类内部
String中，有一些方法可以操作字符串，例如查找字符串的数量，或者提取部分字符串。这可能会非常复杂。例如，在Java中，实际上有两类
字符串：一个是String，另一个是StringBuffer。使用哪一个
取决于你是否打算更改数据。
所以，用普通语言这样的简单代码：
a ="一个字符串" ;;
b ="另一个" ;;
c = join（a，b）;
打印c;
或lisp风格
（设置一个字符串）
（设b另一个）
（设置c（加入ab））
（打印c）
成为Java：
公共类测试{
public static void main（String [] args）{
String a = new String（" a string"）;
String b = new String（" another one"）;
StringBuffer c = new StringBuffer（40）;
c.append（a）; c.append（b）;
System.out.println（c.toString（））;
}
}
在这里，一个新的Stringa？创建一个String对象。 a ??新的
StringBuffer（40）a ??创建可更改的字符串对象StringBuffer，
，可容纳40个字符。一个?? appenda？是StringBuffer的一种方法。这是用来连接两个字符串的
。
注意语法a ?? c.append（a）a ??，我们可以将其视为在一个超级子程序中调用了一个
内部子程序a ?? appenda ??，它已经分配给了c，其中，内部子程序修改了内部数据通过
将a的值附加到它。
在上面的Java示例中，StringBuffer类有另一种方法
a？ ？的toString（）的ΔΣ用于将其转换为String类，必需
因为System.out.println'的参数需要String类型，而不是
StringBuffer。
有关类和方法复杂性的示例，请参阅
文档。 //java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html\"target =_ blank> http://java.sun.com/j2se/1.4.2/docs/ ... ingBuffer.html
（本地副本）
同样地，Java中的数字已成为许多人的正式化/>
类：Double，Float，Integer，Long ......每个都有一个
a ??方法的集合？操作或从一个转换为另一个。
而不是
aNumber = 3;
打印aNumber ^ 2;
在Java中，程序员需要掌握几个
数字类的细节，并决定使用哪一个。 （如果一个程序后来需要从一种类型的数字改为另一种类型，那通常很麻烦。）
这种面向对象的编程风格和专用语言（如
C ++，Java）已经成为业内无知的编程群体中的狂热之火。部分是因为以数据为中心的新视角，部分是因为新语法的新颖性和神秘性
和行话化。
机会主义者Sun Microsystems特别大肆炒作，1995年左右，Java，互联网和Web应用程序开始兴起。
在那些时候，OOP（和Java）是以为要彻底改变行业并解决所有软件工程问题，特别是通过
确定一个组件的重复使用？被认为带来的概念
OOP。 （我们将在继承部分介绍a ... reusea ??问题
稍后。）
作为这种新语法和纯度的一部分，凡是一切在一个程序中
是类和对象和方法，许多复杂的问题和概念
来自OOP语言机器以及一个
工程实践。
我们现在知道行话类最初是有效的仅仅是一组数据和子程序的盒装数据和子程序一个子程序。
而且行话对象只是一个已经设置为这个
超级子程序的变量。内部子程序就是所谓的方法。
-----------
以上是摘录自文章
a ??什么是OOP'的Jargons和Complexitiesa ??
完整的文章可在
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
Xah
xa*@xahlee.org
a ?? http://xahlee.org/
Xah Lee写道：
作为这种新语法和纯度的一部分，程序中的所有内容
是类和对象和方法，许多复杂的问题和概念
来自OOP语言机制以及
工程实践。
我认为OOP的许多设计模式在功能编程的存在中是多余的这一事实非常有趣。我想看看
更多关于此的文章，尤其是因为它可以作为一个优秀的
介绍函数式编程的大多数程序员
只精通面向对象（主要是C ++，Java和C＃
程序员）。
GOF上有一篇旧论文在OCaml中实现的OOP设计模式
但它不是由OCaml-savvy程序员编写的，并且包含许多错误
和遗漏。也许Lisp社区已经产生了更好的东西？
此外，模式匹配是许多现代函数式编程的基础
语言。在这里，模式匹配通常是操纵具体数据结构的唯一方法，并且通常会导致代码比任何面向对象的等效代码更快，更简洁。我最近给了一个用OCaml / F＃编写的小符号简化器的例子
很难且很乏味很难翻译成许多其他语言
（包括C ++，Java，C＃甚至是Lisp）。
-
Jon D Harrop博士，飞蛙咨询公司
科学家的OCaml
http：// www。 ffconsultancy.com/product...ex.html?usenet
请不要跟进xah'的帖子到comp.lang.perl.misc。他不想在那里获得
，被认为是巨魔。他讨厌perl所以他为什么要b / b
crossposts有一个问题。如果你想跟进，只能在
你自己的小组发帖。让他和他无用的线程脱离clpmisc。
uri
-
Uri Guttman - ---- ur*@stemsystems.com -------- http://www.stemsystems.com
- 私人咨询，干线开发，系统架构，设计和编码 -
搜索或提供Perl工作---------------------------- http://jobs.perl.org
Uri Guttman写道：
请不要跟随xah'的帖子进入comp.lang.perl.misc。他不想在那里获得
，被认为是巨魔。他讨厌perl所以他为什么要b / b
crossposts有一个问题。如果你想跟进，只能在
你自己的小组发帖。让他和他无用的线程离开c.l.p.misc。
我们也听过其他新闻组关于Xah Lee的类似报道。
- Lew
What are OOP''s Jargons and Complexities
Xah Lee, 20050128
Classes, Methods, Objects
In computer languages, often a function definition looks like this:
subroutine f (x1, x2, ...) {
variables ...
do this or that
}
In advanced languages such as LISP family, it is not uncommon to
define functions inside a function. For example:
subroutine f (x1, x2, ...) {
variables...
subroutine f1 (x1...) {...}
subroutine f2 (x1...) {...}
}
Often these f1 f2 inner functions are used inside f, and are not
relevant outside of f. Such power of the language gradually developed
into a style of programing. For example:
subroutine a_surface () {
coordinatesList = ...;
subroutine translate (distance) {...}
subroutine rotate (angle) {..}
}
Such a style is that the a_surface is no longer viewed as a function.
But instead, a boxed set of functions, centered around a piece of
datum. And, all functions for manipulating this piece of datum are all
embodied in this function. For example:
subroutine a_surface (arg) {
coordinatesList = ...
subroutine translate (distance) {set coordinatesList to translated
version}
subroutine rotate (angle) {set coordinatesList to rotated version}
subroutine return () {return coordinatesList}
if (no arg) {do nothing}
else { apply arg to coordinatesList }
}
In this way, one uses a_surface as a piece of datum that are bundled
with its own set of functions:
mySurface = a_surface // assign subroutine to a variable
mySurface(rotate(angle)) // now the surface datum has been
rotated
mySurface(translate(distance)) // now its translated
newSurface = mySurface(return())
So now, a_surface is no longer viewed as a subroutine, but a boxed set
of things centered around a piece of datum. All functions that work on
the datum are included in the boxed set. This paradigm possible in
functional languages has refined so much so that it spread to other
groups and became known as Object Oriented Programing, and complete
languages with new syntax catered to such scheme emerged.
In such languages, instead of writing them like this:
mySurface = a_surface;
mySurface(rotate(angle));
the syntax is changed to like this, for example:
mySurface = new a_surface();
mySurface.rotate(angle);
In such languages, the super subroutine a_surface is no longer called
a function or subroutine. It is now called a a??Classa??. And now the
variable holding the function "mySurface" is now called a a??Objecta??.
Subroutines inside the function a_surface are no longer called inner-
subroutines. They are called a??Methodsa??. The act of assigning a super-
subroutine to a variable is called instantiation.
This style of programing and language has become so fanatical that in
such dedicated languages like Java, everything in the language are
Classes. One can no longer just define a variable or subroutine.
Instead, one defines these super-subroutines (classes) that has inner-
subroutines (methods). Every line of code are now inside such super-
subroutine. And one assigns subroutines to variables inside other
subroutines to create objects. And one calls inner-subroutines
(methods) thru these a??objecta?? variables to manipulate the data defined
in the super-subroutine. In this fashion, even basic primitives like
numbers, strings, and lists are no longer atomic entities. They are
now subroutines with inner-subroutines.
For example, in Java, a string is a class String. And inside the class
String, there are Methods to manipulate strings, such as finding the
number of chars, or extracting parts of the string. This can get very
complicated. For example, in Java, there are actually two Classes of
strings: One is String, and the other is StringBuffer. Which one to
use depends on whether you intend to change the datum.
So, a simple code like this in normal languages:
a = "a string";
b = "another one";
c = join(a,b);
print c;
or in lisp style
(set a "a string")
(set b "another one")
(set c (join a b))
(print c)
becomes in Java:
public class test {
public static void main(String[] args) {
String a = new String("a string");
String b = new String("another one");
StringBuffer c = new StringBuffer(40);
c.append(a); c.append(b);
System.out.println(c.toString());
}
}
Here, the a??new Stringa?? creates a String object. The a??new
StringBuffer(40)a?? creates the changeable string object StringBuffer,
with room for 40 chars. a??appenda?? is a method of StringBuffer. It is
used to join two Strings.
Notice the syntax a??c.append(a)a??, which we can view it as calling a
inner-subroutine a??appenda??, on a super-subroutine that has been
assigned to c, where, the inner-subroutine modifies the inner datum by
appending the value of a to it.
And in the above Java example, StringBuffer class has another method
a??toString()a?? used to convert this into a String Class, necessary
because System.out.println''s parameter requires a String type, not
StringBuffer.
For a example of the complexity of classes and methods, see the Java
documentation for the StringBuffer class at
http://java.sun.com/j2se/1.4.2/docs/...ingBuffer.html
(local copy)
In the same way, numbers in Java have become a formalization of many
classes: Double, Float, Integer, Long... and each has a collection of
a??methodsa?? to operate or convert from one to the other.
Instead of
aNumber = 3;
print aNumber^2;
In Java the programer needs to master the ins and outs of the several
number classes, and decide which one to use. (and if a program later
needs to change from one type of number to another, it is often
cumbersome.)
This Object Oriented Programing style and dedicated languages (such as
C++, Java) have become a fad like wild fire among the programing mass
of ignoramuses in the industry. Partly because of the data-centric new
perspective, partly because the novelty and mysticism of new syntax
and jargonization.
It is especially hyped by the opportunist Sun Microsystems with the
inception of Java, internet, and web applications booms around 1995.
At those times, OOP (and Java) were thought to revolutionize the
industry and solve all software engineering problems, in particular by
certain a??reuse of componentsa?? concept that was thought to come with
OOP. (we will cover the a??reusea?? issue in the inheritance section
later.)
As part of this new syntax and purity, where everything in a program
is of Classes and Objects and Methods, many complex issues and concept
have arisen in OOP from both the OOP language machinery as well as a
engineering practice.
We now know that the jargon Class is originally and effectively just a
boxed set of data and subroutines, all defined inside a subroutine.
And the jargon Object is just a variable that has been set to this
super-subroutine. And the inner-subroutines are what''s called Methods.
-----------
The above is a excerpt from the article
a??What are OOP''s Jargons and Complexitiesa??.
The full article is available at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
Xah
xa*@xahlee.org
a?? http://xahlee.org/
Xah Lee wrote:As part of this new syntax and purity, where everything in a program
is of Classes and Objects and Methods, many complex issues and concept
have arisen in OOP from both the OOP language machinery as well as a
engineering practice.I think the fact that many design patterns from OOP are redundant in the
presence of functional programming is very interesting. I''d like to see
more written about this, not least because it would serve as an excellent
introduction to functional programming for the majority of programmers who
are versed only in object orientation (primarily C++, Java and C#
programmers).
There is an old paper on the GOF''s OOP design patterns implemented in OCaml
but it was not written by OCaml-savvy programmers and contained many errors
and omissions. Perhaps the Lisp community have generated something better?
Also, pattern matching is fundamental to many modern functional programming
languages. Here, pattern matching is often the only way to manipulate
concrete data structures and often results in code that is both faster and
more concise than any object-oriented equivalent. I recently gave the
example of a small symbolic simplifier written in OCaml/F# that is
difficult and tedious to translate into many other languages efficiently
(including C++, Java, C# and even Lisp).
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
please DO NOT EVER followup xah''s posts into comp.lang.perl.misc. he is
not wanted there and is considered a troll. he hates perl so why he
crossposts there is a question. if you want to followup, post only in
your own group. keep him and his useless threads out of c.l.p.misc.
uri
--
Uri Guttman ------ ur*@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Uri Guttman wrote:please DO NOT EVER followup xah''s posts into comp.lang.perl.misc. he is
not wanted there and is considered a troll. he hates perl so why he
crossposts there is a question. if you want to followup, post only in
your own group. keep him and his useless threads out of c.l.p.misc.We''ve heard similar reports about Xah Lee on other newsgroups as well.
-- Lew
这篇关于什么是OOP的Jargons和复杂性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
