“对象通过传递消息彼此之间到底如何通信"? [英] How exactly do "Objects communicate with each other by passing messages"?

问题描述

在有关面向对象编程的几篇介绍性文章中，我遇到了上面的陈述.

In several introductory texts on Object-oriented programming, I've come across the above statement.

在Wikipedia中，在OOP中，每个对象都可以接收消息，处理数据以及发送消息到其他对象，并且可以被视为独立的机器" '具有独特的角色或责任."

From wikipedia, "In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects and can be viewed as an independent 'machine' with a distinct role or responsibility."

该语句在代码中到底意味着什么?

What exactly does the statement mean in code?

class A
{ 
    methodA()
    {

    }
}


class B
{
    methodB()
    {

    }
}


class C
{
    main()
    {
        A a=new A();
        B b=new B();
        a.methodA(); // does this mean msgs passing??
        b.methodB(); // or does this?? I may be completely off-track here..
    }
}

推荐答案

如果我们在谈论OOP，那么消息传递"一词来自

If we are talking about OOP than the term "message passing" comes from Smalltalk. In a few words the Smalltalk basic principles are:

1. Object 是面向对象系统的基本单元.
2. 对象具有自己的状态.
3. 对象通过发送和接收消息进行通信.

1. Object is the basic unit of object-oriented system.
2. Objects have their own state.
3. Objects communicate by sending and receiving messages.

如果您对Smalltalk感兴趣，请查看 Pharo 或

If you are interested in Smalltalk take a look at Pharo or Squeak.

Java/C#/C ++和许多其他语言使用的方法略有不同，可能源自 Simula .您调用方法，而不是传递消息.

Java/C#/C++ and many other languages use slightly different approach probably derived from Simula. You invoke a method instead of pass a message.

我认为这个术语或多或少是等效的.唯一有趣的区别是，消息传递(至少在Smalltalk中)始终依赖于动态调度和后期绑定，而在方法调用的情况下，也可以使用静态调度和早期绑定.例如，默认情况下，C ++(AFAIK)会进行早期绑定，直到某个地方出现"virtual"关键字为止.

I think this terms are more or less equivalent. May be the only interesting difference is that message passing (at least in Smalltalk) always rely on dynamic dispatch and late binding while in the case of method invocation one can use static dispatch and early binding too. For example, C++ (AFAIK) does early binding by default until "virtual" keyword appears somewhere...

无论如何，无论您的编程语言在两个对象之间使用哪种形式主义进行通信(消息传递或方法调用)，始终被视为一种良好的OOP样式，它禁止直接访问Smalltalk术语中的实例变量或C ++术语中的数据成员或不管您的编程语言中使用了什么术语.

Anyway, regardless of which formalism do your programming language use for communication between two objects (message passing or method invocation) it's always considered a good OOP style to forbid direct access to instance variables in Smalltalk terminology or data members in C++ terminology or whatever term is used in your programming language.

Smalltalk在语法级别上直接禁止访问实例变量.如上所述，Smalltalk程序中的对象只能通过传递/接收消息进行交互.许多其他语言允许在语法级别访问实例变量，但这被认为是不好的做法.例如，著名的有效的C ++ 包含相应的书建议:项目22:声明数据成员为私有.

Smalltalk directly prohibits access to instance variables at the syntax level. As I mentioned above objects in Smalltalk program can interact only by passing/receiving messages. Many other languages allow access to instance variables at the syntax level but it's considered a bad practice. For example, the famous Effective C++ book contains the corresponding recommendation: Item 22: Declare data members private.

原因是:

• 语法一致性(客户端访问对象的唯一方法是通过成员函数或消息传递)；
• 对数据成员的可访问性进行更精确的控制(您可以实现无访问权限，只读访问，读写访问甚至仅写访问)；
• 您以后可以替换数据成员而不会破坏您的公共界面.

最后一个是最重要的.这是封装的本质-信息隐藏在类级别.

The last one is the most important. It's the essence of encapsulation - information hiding on the class level.

关于封装的要点比起初看起来要重要得多.如果您对客户端隐藏数据成员(即封装它们)，则可以确保始终保持类不变式，因为只有成员函数才能影响它们.此外，您保留稍后更改实施决策的权利.如果您不隐藏这样的决定，您很快就会发现，即使您拥有某个类的源代码，您更改公共内容的能力也会受到极大限制，因为太多的客户端代码将被破坏. Public表示未封装，并且实际上来说，未封装表示不可更改，尤其是对于广泛使用的类.然而，最需要封装的类是最广泛使用的类，因为它们是从一种更好的实现中替换一个实现的最大受益.

The point about encapsulation is more important than it might initially appear. If you hide your data members from your clients (i.e., encapsulate them), you can ensure that class invariants are always maintained, because only member functions can affect them. Furthermore, you reserve the right to change your implementation decisions later. If you don't hide such decisions, you'll soon find that even if you own the source code to a class, your ability to change anything public is extremely restricted, because too much client code will be broken. Public means unencapsulated, and practically speaking, unencapsulated means unchangeable, especially for classes that are widely used. Yet widely used classes are most in need of encapsulation, because they are the ones that can most benefit from the ability to replace one implementation with a better one.

(с)Scott Meyers，有效的C ++:改进程序和设计的55种特定方法(第3版)

(с) Scott Meyers, Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)

这篇关于“对象通过传递消息彼此之间到底如何通信"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！