请你的意见 [英] Your opinion please

查看:69
本文介绍了请你的意见的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在创建一个数据库类,其中包含一个名为

Open()的成员。使用此方法,用户可以打开不同的数据库当用户

尝试打开一个恰好用useraccounts

(用户名,密码等)保护的数据库时,应该通知用户登录。


现在,在我看来他们有3种方法可以应对这种情况:

1.使用错误代码很好地退出方法(例如拒绝访问,指定

账户信息并再试一次)

2.发起例外

3.发起一个事件(例如一个LoginEvent,带有取消选项)并等到

用户在异常处理程序中指定其用户名,密码

等。这意味着Open()必须等待

直到用户回复。


我不是在寻找一个好的解决方案,但我是对opions的兴趣更多。

好​​参数。


有没有人愿意分享他的意见?


thnx


DD

解决方案

排名第一的是要走的路。

2不适用,因为你描述的情况是预期的。

3.对初学者来说太复杂了,无论如何都可能过度杀伤。
<祝你好运。祝你好运。

彼得


-

联合创始人,Eggheadcafe.com开发人员门户网站:
http://www.eggheadcafe.com

UnBlog:
http://petesbloggerama.blogspot.com



" C#Beginn呃"写道:


我正在创建一个数据库类,其中包含一个名为

Open()的成员。使用此方法,用户可以打开不同的数据库当用户

尝试打开一个恰好用useraccounts

(用户名,密码等)保护的数据库时,应该通知用户登录。


现在,在我看来他们有3种方法可以应对这种情况:

1.使用错误代码很好地退出方法(例如拒绝访问,指定

账户信息并再试一次)

2.发起例外

3.发起一个事件(例如一个LoginEvent,带有取消选项)并等到

用户在异常处理程序中指定其用户名,密码

等。这意味着Open()必须等待

直到用户回复。


我不是在寻找一个好的解决方案,但我是对opions有兴趣,并且好好参数。


有谁在那里?谁愿意分享他的意见?

thnx


DD


彼得是正确的,他的意见也是如此。 :)


第一个选项是有意义的:你尝试打开你知道的东西

可能打开也可能不打开,结果表明状态为

操作。由于您可能打开或不打开数据库,

TryOpen()可能在道德上更正确,但由于

方法名称上的Try-前缀已经意味着什么微妙的不同,Open()

已经意味着你要做的事情,Open(),就像你拥有它一样,

也可能是最好的名字。


第二个选项涉及一个例外。彼得说,没有什么事情可以发生。例外情况应保留给用户在我们访问USB设备时拔掉USB设备,或者磁盘没有足够的空间来写日志或临时文件。抛出

例外会带来开销;虽然开销并不是什么东西可以消除,但是这个案例甚至没有遵循异常隐喻,所以

它纯粹是浪费了开销。 />

说第三个是太复杂了可能是轻描淡写。

当你想要非常非常重量级的物品

时,有些时候和地点可以做火灾事件和等待结果。只有我能想到的只有两个用户非常接近对象模型或者系统有能力应对的地方。

包含缺少信息和断开连接等内容。


第一种情况是API和用户可编程系统之类的东西。

在这些情况下,您有时会想要包装对象。围绕你的核心

对象。包装器使API更像UI,在这种情况下适合

。不过,我很难相信这是任何API的最佳模型。


第二种情况是智能 ;系统。我设计了系统

,其中包含默认值和基本情况。如果你告诉他们

的东西,他们会尝试不同的排列,直到任何东西

有效,或者他们用完了选项。有很多方法可以做到这一点,但

一个是发起一个事件并等待更多信息。例如,如果

你有一个默认的用户名和密码,你可以发起一个事件,等待
超时,然后尝试默认,如果没有收到任何信息。这是非常复杂的系统模型和优秀的设计,指明你永远不会这样做,除非有充分的理由这样做。

选择最简单的门号。

Stephan


Peter写道:


第一个是要走的路。

2不适用,因为你描述的情况是预期的。

3.对于初学者来说太复杂了,好吧反正可能有点过头了。


好​​运。

彼得


-

联合创始人,Eggheadcafe.com开发者门户网站:
http://www.eggheadcafe。 com

UnBlog:
http:// petesbloggerama .blogspot.com


" C#Beginner"写道:


我正在创建一个数据库类,其中包含一个名为

Open()的成员。使用此方法,用户可以打开不同的数据库当用户

尝试打开一个恰好用useraccounts

(用户名,密码等)保护的数据库时,应该通知用户登录。


现在,在我看来他们有3种方法可以应对这种情况:

1.使用错误代码很好地退出方法(例如拒绝访问,指定

账户信息并再试一次)

2.发起例外

3.发起一个事件(例如一个LoginEvent,带有取消选项)并等到

用户在异常处理程序中指定其用户名,密码

等。这意味着Open()必须等待

直到用户回复。


我不是在寻找一个好的解决方案,但我是对opions的兴趣更多。

好​​参数。


有没有人愿意分享他的意见?


thnx


DD




thnx ssamuel和peter


我要求选择的原因是,正如我的名字所说,我是C#初学者。

虽然我很快就学会了这门语言,但是在课堂和课程之间画一条线似乎有困难

。哪个任务应该是由班级处理的
以及哪些应由程序处理。

登录尝试是由班级处理还是由程序处理?等等


我想通过使用一个活动,课程可以控制情况

(只需给我一个名字和密码,然后处理它)把这个问题推迟到程序中(访问被拒绝,自己解决),因为我已经使用VB6试图打开一个安全的数据库。



我已经阅读了很多书,我已经学会了创建例外,事件&

代表等等,但我从未读过一本书来解释我在哪里

情况我应该使用例外或事件(我指的是荷兰书籍)。


虽然解决方案很好,但我是对意见更感兴趣,因为它是最好的学习方式。


thnx再次


DD



" ssamuel" < ss ***** @ gmail.comschreef in bericht

news:11 ********************* @ 14g2000cws.googlegrou ps.com ...

彼得是正确的,他的意见也是如此。 :)


第一个选项是有意义的:你尝试打开你知道的东西

可能打开也可能不打开,结果表明状态为

操作。由于您可能打开或不打开数据库,

TryOpen()可能在道德上更正确,但由于

方法名称上的Try-前缀已经意味着什么微妙的不同,Open()

已经意味着你要做的事情,Open(),就像你拥有它一样,

也可能是最好的名字。


第二个选项涉及一个例外。彼得说,没有什么事情可以发生。例外情况应保留给用户在我们访问USB设备时拔掉USB设备,或者磁盘没有足够的空间来写日志或临时文件。抛出

例外会带来开销;虽然开销并不是什么东西可以消除,但是这个案例甚至没有遵循异常隐喻,所以

它纯粹是浪费了开销。 />

说第三个是太复杂了可能是轻描淡写。

当你想要非常非常重量级的物品

时,有些时候和地点可以做火灾事件和等待结果。只有我能想到的只有两个用户非常接近对象模型或者系统有能力应对的地方。

包含缺少信息和断开连接等内容。


第一种情况是API和用户可编程系统之类的东西。

在这些情况下,您有时会想要包装对象。围绕你的核心

对象。包装器使API更像UI,在这种情况下适合

。不过,我很难相信这是任何API的最佳模型。


第二种情况是智能 ;系统。我设计了系统

,其中包含默认值和基本情况。如果你告诉他们

的东西,他们会尝试不同的排列,直到任何东西

有效,或者他们用完了选项。有很多方法可以做到这一点,但

一个是发起一个事件并等待更多信息。例如,如果

你有一个默认的用户名和密码,你可以发起一个事件,等待
超时,然后尝试默认,如果没有收到任何信息。这是非常复杂的系统模型和优秀的设计,指明你永远不会这样做,除非有充分的理由这样做。

选择最简单的门号。

Stephan


Peter写道:


第一个是要走的路。

2不适用,因为你描述的情况是预期的。

3.对于初学者来说太复杂了,好吧反正可能有点过头了。


好​​运。

彼得


-

联合创始人,Eggheadcafe.com开发者门户网站:
http://www.eggheadcafe。 com

UnBlog:
http:// petesbloggerama .blogspot.com


" C#Beginner"写道:


我正在创建一个数据库类,其中包含一个名为

Open()的成员。使用此方法,用户可以打开不同的数据库当用户

尝试打开一个恰好用useraccounts

(用户名,密码等)保护的数据库时,应该通知用户登录。


现在,在我看来他们有3种方法可以应对这种情况:

1.使用错误代码很好地退出方法(例如拒绝访问,指定

账户信息并再试一次)

2.发起例外

3.发起一个事件(例如一个LoginEvent,带有取消选项)并等到



用户在异常处理程序中指定他的用户名,密码

等。这意味着Open()必须等待

直到用户回复。


我不是在寻找一个好的解决方案,但我是对opions更感兴趣

with

好​​参数。


有没有人愿意分享他的意见?


thnx


DD



I''m currently creating a database class, which contains a member called
Open(). With this method users can open different databases. When a user
tries to open a database which happens to be secured with useraccounts
(username, password etc), the user should be notifed to login.

Now, in my opinion their are 3 ways to cope with situation:
1. Exit the method nicely with an errorcode (eg access denied, specify
accountinformation and try again)
2. Fire an exception
3. Fire an event (eg a LoginEvent, with cancel option) and wait until the
user specifies his username, password
etc within an exceptionhandler. This means that the Open() must wait
until the user responses.

I''m not looking for a good solution, but I''m more interested in opions with
good arguments.

Is there anybody out there who′s willing to share his opinion?

thnx

DD

解决方案

number one is the way to go.
2 is not applicable because the situation you describe is an expected one.
3. Is too complex for a beginner, and probably overkill anyway.

Best of luck.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"C# Beginner" wrote:

I''m currently creating a database class, which contains a member called
Open(). With this method users can open different databases. When a user
tries to open a database which happens to be secured with useraccounts
(username, password etc), the user should be notifed to login.

Now, in my opinion their are 3 ways to cope with situation:
1. Exit the method nicely with an errorcode (eg access denied, specify
accountinformation and try again)
2. Fire an exception
3. Fire an event (eg a LoginEvent, with cancel option) and wait until the
user specifies his username, password
etc within an exceptionhandler. This means that the Open() must wait
until the user responses.

I''m not looking for a good solution, but I''m more interested in opions with
good arguments.

Is there anybody out there who?′s willing to share his opinion?

thnx

DD


Peter is correct, as is his opinion. :)

The first option makes sense: you try to open something that you know
may or may not open, and the result indicates the status of the
operation. Since you may or may not be able to open the database,
TryOpen() may be more morally correct, but since the Try- prefix on
method names already means something subtly different, and Open()
already means what you''re trying to do, Open(), as you had it, is
probably the best name too.

The second option involves an exception. As Peter stated, nothing
exceptional has happened. Exceptions are to be reserved for things like
users unplugging USB devices while we''re accessing them, or disks not
having enough space to write log or temporary files. Throwing an
exception carries overhead; while overhead isn''t something to be
eliminated, this case doesn''t even follow the exception metaphor, so
it''s purely wasted overhead.

Stating that the third is "too complicated" may be an understatement.
There are times and places when you want very, very heavyweight objects
that do things like fire events and wait for results. The only two I
can think of off the top of my head are either where the user is very
close to the object model or where the system has some ability to cope
with things like missing information and broken connections.

The first case is for things like APIs and user-programmable systems.
In these cases, you sometimes want "wrapper objects" around your core
objects. The wrappers make the API more like a UI, which is appropriate
in those circumstances. I''d have a hard time believing that this is the
best model for any API, however.

The second case is for an "intelligent" system. I''ve designed systems
that have things like defaults and base cases. If you tell them
something, they try different permutations until either something
works, or they run out of options. There are many ways to do this, but
one is to fire an event and wait for more information. For instance, if
you have a default username and password, you can fire an event, wait
for a timeout, then try the default if nothing''s been received. This is
a highly complex system model and good design specifies that you never
do this unless there''s a really good reason to do so.

Go with the simplest door number one.
Stephan

Peter wrote:

number one is the way to go.
2 is not applicable because the situation you describe is an expected one.
3. Is too complex for a beginner, and probably overkill anyway.

Best of luck.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"C# Beginner" wrote:

I''m currently creating a database class, which contains a member called
Open(). With this method users can open different databases. When a user
tries to open a database which happens to be secured with useraccounts
(username, password etc), the user should be notifed to login.

Now, in my opinion their are 3 ways to cope with situation:
1. Exit the method nicely with an errorcode (eg access denied, specify
accountinformation and try again)
2. Fire an exception
3. Fire an event (eg a LoginEvent, with cancel option) and wait until the
user specifies his username, password
etc within an exceptionhandler. This means that the Open() must wait
until the user responses.

I''m not looking for a good solution, but I''m more interested in opions with
good arguments.

Is there anybody out there who′s willing to share his opinion?

thnx

DD





thnx ssamuel and peter

The reason I asked for opions is that I''m, as my name states, a C# beginner.
Though I''m learning the language very quickly, I seem to have difficulties
with drawing a line between a class and a program. Which tasks should be
handled by the class and which ones should be handled by the program. Should
login attempts be handled by the class or handled by the program? etc.

I thought by using an event, the class could take control over the situation
(just give me a name and password and I handle it) intead of shoving the
problem to the program (access denied, solve it yourself), as I have
experienced using VB6 trying to open a secured database.

I''ve read a lot of books and I''ve learned to create execeptions, events &
delegates and so, but I never read a book explaining to me in which
situations I should use exceptions or events (I''m refering to dutch books).

Though solutions are good but I''m more interested in opinions because it''s
the best way to learn.

thnx again

DD


"ssamuel" <ss*****@gmail.comschreef in bericht
news:11*********************@14g2000cws.googlegrou ps.com...
Peter is correct, as is his opinion. :)

The first option makes sense: you try to open something that you know
may or may not open, and the result indicates the status of the
operation. Since you may or may not be able to open the database,
TryOpen() may be more morally correct, but since the Try- prefix on
method names already means something subtly different, and Open()
already means what you''re trying to do, Open(), as you had it, is
probably the best name too.

The second option involves an exception. As Peter stated, nothing
exceptional has happened. Exceptions are to be reserved for things like
users unplugging USB devices while we''re accessing them, or disks not
having enough space to write log or temporary files. Throwing an
exception carries overhead; while overhead isn''t something to be
eliminated, this case doesn''t even follow the exception metaphor, so
it''s purely wasted overhead.

Stating that the third is "too complicated" may be an understatement.
There are times and places when you want very, very heavyweight objects
that do things like fire events and wait for results. The only two I
can think of off the top of my head are either where the user is very
close to the object model or where the system has some ability to cope
with things like missing information and broken connections.

The first case is for things like APIs and user-programmable systems.
In these cases, you sometimes want "wrapper objects" around your core
objects. The wrappers make the API more like a UI, which is appropriate
in those circumstances. I''d have a hard time believing that this is the
best model for any API, however.

The second case is for an "intelligent" system. I''ve designed systems
that have things like defaults and base cases. If you tell them
something, they try different permutations until either something
works, or they run out of options. There are many ways to do this, but
one is to fire an event and wait for more information. For instance, if
you have a default username and password, you can fire an event, wait
for a timeout, then try the default if nothing''s been received. This is
a highly complex system model and good design specifies that you never
do this unless there''s a really good reason to do so.

Go with the simplest door number one.
Stephan

Peter wrote:

number one is the way to go.
2 is not applicable because the situation you describe is an expected one.
3. Is too complex for a beginner, and probably overkill anyway.

Best of luck.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"C# Beginner" wrote:

I''m currently creating a database class, which contains a member called
Open(). With this method users can open different databases. When a user
tries to open a database which happens to be secured with useraccounts
(username, password etc), the user should be notifed to login.

Now, in my opinion their are 3 ways to cope with situation:
1. Exit the method nicely with an errorcode (eg access denied, specify
accountinformation and try again)
2. Fire an exception
3. Fire an event (eg a LoginEvent, with cancel option) and wait until
the
user specifies his username, password
etc within an exceptionhandler. This means that the Open() must wait
until the user responses.

I''m not looking for a good solution, but I''m more interested in opions
with
good arguments.

Is there anybody out there who′s willing to share his opinion?

thnx

DD




这篇关于请你的意见的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆