我应该使用存取器吗? [英] should I use accessors or not?

问题描述

我已经编写了大约2-3年的程序，实际上我正在用动作脚本atm开发游戏.我有一个角色类，其中包含一些字段，例如名称，级别，经验，伤害，防御等.现在，我已经保护了它们，以便派生类可以看到它们，并且我使用了getter和setter封装它们，因此其他类只能看到getter.但是，在动作脚本中，似乎不能使访问器受到保护，因此它们必须是公共的.但是，如果有人可以看到访问者并进行编辑，为什么我应该完全使用访问器呢?我是否应该跳过封装，而只使用公共字段并封装那些需要在设置时执行其他一些语句的字段.例如，如果我增加了经验字段，则应该在增加的同时检查级别.

我喜欢c#中的访问器，因为它们使编码更容易，因为您无法在其他类中看到私有/受保护的访问器.

希望有一些经验丰富的程序员对访问器有意见.

I have programmed for about 2-3 years now and actually I am developing a game in actionscript atm. I have a character class which have some fields like name, level, experience, damage, defence and so on. right now I have made them protected so the deriving classes can see them, and I have used getters and setters to encapsulate them, so other classes only can see the getters. However in actionscript it seems that you can''t make accessors protected, so they must be public. But why should I use accessors at all if anybody can just see them and edit them anyway? Should I just skip the encapsulation and just go with public fields and encapsulate the ones who need to do some other statements when set. For instance if I increase the experience field it should check for a level up while increasing.

I like accessors in c# because they make the coding easier as you can''t see private/protected accessors in other classes.

It would be nice to have some more experienced programmers opinion on accessors.

推荐答案

只是因为该语言没有提供保护/封装的方法，所以没有并不意味着您应该放弃访问器.

我直接从Barbara Liskov了解了OOP和封装的重要性.

此后我的第一个专业编程工作是在C中.即使我们使用C编写，我们仍然编写了面向对象的代码.我们拥有在这些结构上运行的数据结构和功能(或宏).如果要操纵这些结构之一或设置或获取其中的数据，则可以使用该函数(或宏).您永远都无法直接访问数据.

为什么?因为我们希望能够在必要时更改基础表示形式，而不必重新编写使用这些对象的代码.

简单的例子是:

假设您有一个矩形对象，但不确定将其存储为x，y，宽度和高度还是将其存储为上，左，下，右的效率更高.

如果您以一种方式进行编码，然后发现以另一种方式进行呈现，则图形呈现代码(或其他方式)会更快，那么您可以更改基础表示形式而不会产生任何影响.

或者，就像爱德华建议的那样，您可能会发现您想要缓存某些内容.如果通过访问器进行设置并获取所有内容，则可以在需要时对需要缓存的内容实现缓存.


基本课程是:

如果编写访问器并严格要求仅使用访问器来访问数据，则可以根据需要自由更改实现细节，而不会影响任何其他代码.

这意味着您不必预先做出所有低级设计决策.您可以根据需要更改实现.

您唯一不提供访问器的时间是，当您绝对知道设置或获取数据时永远不想做其他事情，并且永远也不想更改其基本表示形式.您期望代码保留的时间越长，提供访问器就越重要.

仅仅因为该语言无法提供保护某物的手段，并不意味着您不能在此处发表大量评论，内容如下:

我保留随时更改此实现的权利.只能使用访问者.直接访问数据可确保最终导致无效代码."

如果在类定义中看到类似的内容，我会三思而后行，直接访问原始作者告诉我的内容.

Just because the language doesn''t provide a means of protection / encapsulation, doesn''t mean you should abandon accessors.

I learned OOP and the importance of encapsulation directly from Barbara Liskov.

My first professional programming job after that was in C. Even though we were writing in C, we wrote Object Oriented code. We had data structures and functions (or macros) that operated on those structures. If you wanted to manipulate one of those structures or set or get data in them, you used the function (or macro) for that. You NEVER EVER, ON PAIN OF DEATH, accessed the data directly.

Why? Because we wanted to be able to change the underlying representations if necessary without having to re-write the code that used those objects.

The simple example is:

Suppose you have a rectangle object but you aren''t sure if it''s going to be more efficient to store it as x, y, width and height, or to store it as top, left, bottom, right.

If you code it one way and then find that your graphical rendering code (or something) would be faster if you rendered it the other way, then you can change the underlying representation without effecting anything.

Or, as Edward suggests, you might find that you want to cache certain things. If you set and get everything via the accessors then you can implement a cache for the things you decide that need to be cached when you decide it''s needed.


The basic lesson is:

If you write accessors and strictly enforce that only accessors are used to access the data, then you are free to change implementation details as needed without effecting any other code.

It means you don''t have to make all the low level design decisions up front. You can change implementation as necessary.

The ONLY time you wouldn''t provide accessors is when you KNOW ABSOLUTELY that you are NEVER going to want to do something else when that data is set or get and you are NEVER going to want to change it''s underlying representation. The longer you expect your code to leave, the more important it is to provide accessors.

Just because the language doesn''t provide a means of protecting something doesn''t mean you can''t put a huge comment there that says:

"I RESERVE THE RIGHT TO CHANGE THIS IMPLEMENTATION AT ANY TIME. USE ACCESSORS ONLY. ACCESSING THE DATA DIRECTLY IS GUARANTEED TO RESULT IN NON-FUNCTIONING CODE EVENTUALLY."

If I saw something like that in a class definition I''d think twice about directly accessing anything the original writer told me not to.

几乎所有内容都由爱德华(Edward)在评论中解释.问题.我只添加一点.

这是关于不同访问修饰符的基本原理的非常有趣的讨论:
http://www.actionscript.org/forums/archive/index.php3/t- 113383.html [ ^ ].

请注意有关读取和分配操作的不同访问可能有用的情况的描述.它经常用在C ++，C#，Delphi Pascal等中.

顺便说一句，我建议不要忘记internal访问修饰符，该修饰符定义了与包一起访问的访问public，并且在跨包访问时也像private一样.这个想法是这样的:您不应提供超出实际需要的更多访问权限.

我还应注意，即使访问方法很简单并且在逻辑上等效于仅使用字段，通常的做法是使用getter或setter.在这种情况下，这些方法仅提供了一个线索，即从(私有)数据结构中抽象了公共/内部getter/setter接口，并且可以在以后随时添加非平凡的访问(获取或设置)算法.从意识形态上讲，这类似于使用空的基类或接口:它们只带有表示现实元素的语义，并根据 指代 取自自然语言；它也充当类或接口成员的占位符，这可能有助于在以后的开发中表达语义.这是一种使用计算机语言语法的方法，不仅可以支持代码的运行时语义，还可以支持开发过程.

最后，我要注意问题的以下部分:

Almost everything is explained by Edward in his comment to the question. I will add just a bit.

This is a pretty interesting discussion of the rationale for different access modifiers:
http://www.actionscript.org/forums/archive/index.php3/t-113383.html[^].

Pay attention for description of cases where different access for read and assignment operations can be useful. It is often used in C++, C#, Delphi Pascal, etc.

By the way, I would advice not to forget internal access modifiers which defined access public if accessed withing the package and like private when accessed across packages. The idea is this: you should not provide more access than it is really needed.

I should also note that the common practice is to use getters or setters even when the access methods are trivial and logically equivalent to using just the fields. In this case, these method just provide a clue that a public/internal getter/setter interface is abstracted from the (private) data structure, and non-trivial access (get or set) algorithms can be added at any moment later. Ideologically, this is similar to using empty base classes or interfaces: they just carry some semantic representing the elements of reality and named according to a denotation taken from natural language; it also serves as a placeholder for the class or interface member which may help to express the semantics during later development. This is a way of using computer language syntax in order to support not only the run-time semantics of code, but the process of development.

Finally, I want to note on the following part of the question:

Chrene91写道:

Chrene91 wrote:

我是否应该跳过封装并只使用公共字段…?

Should I just skip the encapsulation and just go with public fields…?

很明显，您正在尝试使用术语封装在某种程度上非常狭义，既不是默认值，也不是习惯.通常，一旦您以任何明智的方式简单地使用类，在OOP中该术语的隐含含义就不允许您跳过封装".它通常意味着信息隐藏，可以通过代码维护和纪律来理解.请参阅:
http://en.wikipedia.org/wiki/Encapsulation_in_object-oriented_programming [

It is apparent that you are trying to use the term encapsulation in some very narrow sense which is neither default nor customary. Usually, the implied sense of this term in OOP does not allow you to "skip encapsulation" as soon as you simply use classes in any sensible way. It generally means information hiding understood in terms of code maintenance and discipline. Please see:
http://en.wikipedia.org/wiki/Encapsulation_in_object-oriented_programming[^].

—SA

这篇关于我应该使用存取器吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！