物体，物体，这么多物体！ ;-) [英] Objects, objects, so many objects! ;-)

问题描述

大家好，


关于对象，我有一个非常普遍但非常重要的问题。


我的问题是，我应该何时创建他们？我知道这是一个垃圾问题所以

让我进一步解释一下。


让我们举一个针对数据库的用户管理的例子。我可能需要做的事情包括：


- 创建新用户

- 更改用户电话号码

- 删除用户

- 吸引用户年龄

- 更新用户密码


所有这些都不是那些操作之一，需要实现一个User对象的
实例化。你可以通过静态方法来实现。


问题是，你上面的那种操作必须占用户所有

操作的80％左右。同样，类似于这些的操作会影响大多数商业实体，无论是Bug还是角色或Car对象。


所以我的问题是 - 是确实如此，那个时间很长的一部分，你根本不需要实例化一个物体来实现你的目标，或者说我用差劲的方法来赚钱。设计我的应用程序？


非常感谢任何可以分享建议的人。


最基本的问候


tce

Hi all,

I have a very general but quite significant question about objects.

My question is, when should I create them? I know thats a crap question so
let me explain a bit further.

Lets take an example of user management against a database. Things I might
like to do include:

- Creating a new user
- Changing a users phone number
- Deleting a user
- Getting a users age
- Updating a users password

The thing with all this is not one of those operations require the
instantiation of a User object. You could do it through static methods.

The thing is, you the sort of operations above must make up 80% or so of all
operations on users. Likewise, operations similar to these ones effect most
business entities, be it a Bug or a Role or a Car object.

So my question is - is it really the case, that a good proportion of the
time, you dont need to instantiate an object at all to achieve your aims, or
am I using a poor approach to design my applications?

Many thanks to anyone who can share some advice.

Kindest Regards

tce

推荐答案

嗨tce，


创建新用户时，将通过静态方法，你会

仍然将实例化一个新的User对象作为该方法的返回值。

这里我假设你可以拥有多个用户，

实例必备。另一个需要新用户对象

的操作可能是更新。例如，当持续更改时，检索更改后的值是合理的，这可能无法在原始对象中保持原样。


Joe

-
http ：//www.csharp-station.com


" thechaosengine" < sh856531@microsofts_free_email_service.com>写在

消息新闻：en ************** @ TK2MSFTNGP11.phx.gbl ...

Hi tce,

While creating a new User would be performed via a static method, you would
still be instantiating a new User object as the return value of that method.
Here I make the assumption that you could have multiple users, making an
instance necessary. Another operation that would require a new User object
could be Update. For example, when persisting changes, it is quite
reasonable to retrieve the changed values, which could possibly not be held
in the original object.

Joe
--
http://www.csharp-station.com

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:en**************@TK2MSFTNGP11.phx.gbl...

- 创建新用户
- 更改用户电话号码
- 删除用户
- 让用户年龄
- 更新用户密码

所有这些都不是那些需要实例化User对象的操作之一。你可以通过静态方法来实现。

- Creating a new user
- Changing a users phone number
- Deleting a user
- Getting a users age
- Updating a users password

The thing with all this is not one of those operations require the
instantiation of a User object. You could do it through static methods.

我们都没有_needs_对象。正如您所指出的，我们可以使用静态方法和静态属性编写

所有内容。这就是我10年前曾经做过的事情。它被称为结构化编程，我使用了
C.


我不是在讽刺：人们用非OO语言编程为

years。现代的等价物，用OO语言，是使

一切都是静态的。


你的问题归结为，基本上是：什么是

面向对象编程优于结构化编程的优势，

以及何时应用对象技术与结构化

技术？

您在

中描述的使用结构化编程的困难如下：


o没有一个对象可以防范用户你的电话号码是多少

你能确定电话号码只能通过静态的

方法设置，而你的来电者是不是已经打过电话了？如果您使用的是

私人用于存储电话号码的静态字符串，并且只允许通过公共静态方法访问
，然后本质上你创建了一个

单例并且只允许存在一次在内存中的一个用户。如果

你想在内存中同时拥有多个用户，那么有人，某个地方，
必须记住他们的电话号码。如果没有对象，你可以依赖

应用程序来保证不要使用电话号码来敲打

，除非通过调用你的方法，因为没有对象你不能
封装状态。


o如果没有对象，就不能轻易地封装业务规则。什么

如果用户的电话号码被更改，您还必须拨打

来更新Exchange中的地址簿？该应用程序是否要记住要执行此操作？
？对象使这种事情变得更容易：

应用程序可以说user.PhoneNumber =" ..." ;;和对象

验证新号码并通知地址簿

已更改。


但是，对象不是一切都好。我在其他地方评论过

我见过的一些最糟糕的设计是新手的结果

程序员试图让一切成为对象。对象真的很好用于你可以命名的低级别的东西，比如用户或

采购订单。一旦你达到一个足够高的水平，比如应用程序的顶级水平，调用这么大的复杂东西对象的有用性。开始快速消失。

None of us really _needs_ objects. As you pointed out, we could write
everything using static methods and static properties. That''s what I
used to do 10 years ago. It was called structured programming, and I
used C.

I''m not being sarcastic: people programmed in non-OO languages for
decades. The modern equivalent, in an OO language, is to make
everything static.

What your question boils down to, essentially, is: what are the
advantages of object oriented programming over structured programming,
and when should you apply object technology versus structured
technology?

The difficulties with using structured programming as you described in
your example are as follows.

o WIthout an object to stand guard over your user''s phone number, how
can you be sure that the phone number is being set only by the static
method and isn''t being diddled by your caller? If you''re using a
"private" static string to store the phone number, and only allowing
access through a public static method, then in essence you''ve created a
singleton and only allow there to be one user in memory at a time. If
you want multiple users in memory at once, then somebody, somewhere,
has to remember their phone numbers. Without objects you rely on the
application program to promise not to muck with the phone numbers
except by calling your methods, because without objects you can''t
encapsulate state.

o Without an object you can''t easily encapsulate business rules. What
if whenever a user''s phone number is changed you have to also make
calls to update the Address Book in Exchange? Does the application have
to remember to do this? Objects make this sort of thing much easier:
the application can just say user.PhoneNumber = "..."; and the object
verifies the new number and looks after informing Address Book that it
has changed.

However, objects aren''t good for everything. I remarked elsewhere that
some of the worst designs I''ve seen were the result of newbie
programmers trying to make everything an object. Objects are really
good for low-level stuff that you can put a name to, like "user" or
"purchase order". Once you get up to a sufficiently high level, like
the top level of an application, the usefulness of calling such big,
complex things "objects" starts to fade rapidly.

tce，


我很少使用静态方法和成员 - 而且大部分都是那些

是通用帮助器或实用程序函数，它们不需要实例

数据，而不是通过参数传递的数据。


以这种方式思考可能会有所帮助：一个类代表一个真实世界的东西

或概念（或一个抽象）包括其数据（字段/

属性）和行为（方法）。它只是一种将数据和/ b $ b操作数据组织成一个连贯的包的方法。通常，程序处理的大多数事物具有从一个实例变化的数据。另一个。

您将从这些类创建对象。如果您的方法适用于多个类，那么您可能已经错误地组织了代码

- 或者您实际上可能具有通用实用功能

可以是实用程序类的静态方法，可能永远不会实例化。


如果你有一些数据是同样的*任何*类的实例，

然后使它成为该类的静态字段。如果你对某个类的* any *实例有一些动作

是相同的，那么使它成为一个静态的方法，即
那个类。否则，是的，创建对象，并且不用担心它们很多很多 - 数量不是连贯组织的问题。

请记住与对象关联的目标代码只加载一次

，无论你有多少个实例。只有实例数据需要每个实例的内存存储量为
。大多数物品没有那么多实例

数据，所以你真的不会匆忙吃掉你所有的RAM。

假设你使用的是基本的在你的设计中常识，担心

只有当它成为真实世界的资源或

性能问题时才有太多对象实例。


--BOB


" thechaosengine" < sh856531@microsofts_free_email_service.com>写在

消息新闻：en ************** @ TK2MSFTNGP11.phx.gbl ...

tce,

I use static methods and members fairly infrequently -- and most of those
are general purpose helper or utility functions that require no instance
data other than whatever is passed in via arguments.

It may help to think of it this way: a class represents a a real-world thing
or concept (or an abstraction of one) including its data (fields /
properties) and behaviors (methods). It''s just a way to organize data and
operations on that data into a coherent package. In general, most "things"
a program deals with have data that varies from one "instance" to another.
You will create objects from these classes. If you have methods that are
appropriate for more than one class then you may have organized the code
incorrectly -- or you may actually have a general purpose utility function
that can be a static method of a utility class that may never be
instantiated.

If you have some data that would be the same for *any* instance of a class,
then make it a static field of that class. If you have some action that
would be the same for *any* instance of a class, make it a static method of
that class. Otherwise, yes, create objects, and don''t worry about having a
lot of them -- quantity is not so much the issue as coherent organization.
Remember that the object code associated with an object is only loaded once
no matter how many instances you have. Only the instance data requires
per-instance memory storage. Most objects don''t have that much instance
data, so you really aren''t going to eat up all your RAM in a hurry.
Assuming you use basic common sense in your designs up front, worry about
having too many object instances only if it becomes a real-world resource or
performance issue.

--Bob

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:en**************@TK2MSFTNGP11.phx.gbl...

大家好，

关于对象我有一个非常普遍但非常重要的问题。

我的问题是，我应该何时创建它们？我知道那是一个垃圾问题所以
让我进一步解释一下。

让我们举一个针对数据库的用户管理的例子。我可能喜欢做的事情包括：

- 创建新用户
- 更改用户电话号码
- 删除用户
- 获取用户年龄
- 更新用户密码

所有这一切都不是那些需要实例化User对象的操作之一。你可以通过静态方法来实现。

事情是，你上面的那种操作必须占用户所有操作的80％左右。同样，类似于这些的操作会影响大多数商业实体，无论是Bug还是角色或Car对象。

所以我的问题是 - 它是否真的如此，一个好的时间的比例，您根本不需要实例化一个对象来实现您的目标，或者我是否使用糟糕的方法来设计我的应用程序？

非常感谢任何可以分享一些建议的人。

最诚挚的问候

tce

Hi all,

I have a very general but quite significant question about objects.

My question is, when should I create them? I know thats a crap question so
let me explain a bit further.

Lets take an example of user management against a database. Things I might
like to do include:

- Creating a new user
- Changing a users phone number
- Deleting a user
- Getting a users age
- Updating a users password

The thing with all this is not one of those operations require the
instantiation of a User object. You could do it through static methods.

The thing is, you the sort of operations above must make up 80% or so of
all operations on users. Likewise, operations similar to these ones effect
most business entities, be it a Bug or a Role or a Car object.

So my question is - is it really the case, that a good proportion of the
time, you dont need to instantiate an object at all to achieve your aims,
or am I using a poor approach to design my applications?

Many thanks to anyone who can share some advice.

Kindest Regards

tce

这篇关于物体，物体，这么多物体！ ;-)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！