单例作为c#中的参数 [英] Singleton as parameter in c#

查看:59
本文介绍了单例作为c#中的参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嗨专家



为什么Singleton不是静止的?

有些问题困扰我。

1)任何我们在C#中传递singleton作为参数的场景?有什么用?

2)Singleton在什么时候提供Interface的继承?有什么用?



在面试中被问到?





谢谢

Dinesh Sharma

Hi Experts

Why Singleton not static?
Some Question confused me.
1)Any Scenario when we pass singleton as parameter in C#?What is the use of that?
2)Singleton provide inheritance from Interface when?What is the use of that?

Asked in interview?


Thanks
Dinesh Sharma

推荐答案

看起来你的问题只是面试官的幻想;它们不是基于任何众所周知的陈述;很难遵循他们的逻辑。很自然地会建议很多人测试他们在练习中遇到的情况,这种体验可能会......不同。



  • 第一个面试问题(我现在正在跳过你自己的问题,将在下面提到)。为什么有人应该建议现有设计模式的场景?这会适得其反。这些问题并没有教导正确的思考,因此不对其进行测试。正确的思考是对某种情况的问题的回应,然后一些解决方案可能涉及某种模式,或者不是。发布模式是为了帮助解决问题,而不是破坏场景以使模式适合。但提出的问题是,如何回答呢?我会说,将单例对象作为参数传递没有问题。没问题 - 对象是一个对象,任何东西都可以传递。但那我们为什么需要单身?需要参数作为抽象设备。也就是说,根据其目的,作为参数传递的实际对象通常应该是不同的。具有参数的方法的主体仍然不可知关于该对象是什么并且准备好对所传递的任何内容起作用。但是单个对象被设计为始终相同。通过它为什么?



    不过,有些情况下通过单身人士会有意义。例如,您可以在应用程序体系结构中使用不同的层,并且只有一个层使用单例作为单例,另一个层不知道有关单例的任何内容,但适用于其类型。换句话说,它有一些方法参数;并且该方法一如既往地与其参数无关。在一些电话中,它可能是单身,而在另一些电话中则不是;该方法的功能不依赖于它(这将是非常好的)。而另一层总是通过单身。这样的事情。
  • 我在第二次面试问题中没有任何意义。该图案可以有许多不同的设计;一些使用接口,一些不使用。两种设计,无论是接口还是没有接口,都可以是好的或坏的。换句话说,在单一设计中具有接口不是该设计模式的特征。同样,这个问题可能反映了面试官的经历。我想,无论是狭隘的经验,还是未经过适当的分析或概括。
  • 最后,我将尝试回答你自己关于静态单身人士的问题。在某种程度上,它比两个面试问题都更有趣,但并不完全正确。 静态 - 什么?表示单例功能的静态类?在单例类中使用静态成员?一个静态对象立即暴露给单身用户?什么?



    无论是什么,通常都会涉及静态物体。因为,最终单身对象应始终相同。另一方面,将静态对象直接暴露给用户会很糟糕。有关更多详细信息,请参阅下面引用的代码示例。



    另一方面,实际上并不需要对单例实现使用任何静态代码。为什么?因为它的主要特征是永远是一个,所以始终是同一个对象具有其范围。通常,这是单个应用程序的应用程序域。但是,它可能是其他东西,例如,单个人在同一台计算机(或同一会话)上的所有应用程序中维护其身份。或者,甚至更广泛,在与同一在线服务通信的许多计算机上。



    但是让我们回到最常见的单例,即应用程序域范围内的单例。想象一下,在程序的入口点方法( Main )中,只能以正常方式创建一个对象。然后将此唯一对象传递给所有其他方法(包括构造函数)。对象仍然只有一个。顺便说一句,这是第一个面试问题的另一个答案。



    即使这个例子中的对象是单一的,有些人可能也不同意称它为单身 ,但这只是一个非必要的术语问题。
It looks like both your questions are just the fantasy of interviewers; they are not based on any well-known statements; it's hard to follow their logic. It would be natural to suggest that many people tests cases which they face in their practice, and that experience could be… will, different.

  • Take the first interview question (I'm skipping your own question for now, will come to it below). Why anyone should ever suggest scenarios to existing design patterns? This would be counter-productive. Such questions don't teach right thinking and hence don't test it. Right thinking would be a response to a problem of some scenario, and then some solution could involve some pattern, or not. Patterns are published in hope to help solving problems, not to mangle "scenarios" to make a pattern fit. But the question is posed, how to answer it? I would say, there is no a problem of passing a singleton object as a parameter. No problem at all — object is an object, anything can be passed. But then why would we need a singleton? A parameters is needed as an abstraction device. That is, according to its purpose, the actual object passed as a parameter should generally be different. The body of the method with a parameter remains agnostic about what that object is and is ready to work to whatever is passed. But a singleton object is designed to be the same all the time. Why passing it?

    Still, there are cases when passing a singleton would make sense. For example, you can have different layer in your application architecture, and only one layer uses the singleton as a singleton, another layer "does not know" anything about the singleton, but works with its type. In other word, it has some method parameter; and the method is, as always, agnostic to its parameters. In some calls, it could be singleton, in others, it is not; the functionality of the method does not rely on that (and this would be very good). And another layer always passes a singleton. Something like that.
  • I don't see any sense in the second interview question. The pattern can have many different designs; some using an interface, some not. Both kinds of designs, with interface or without interface, can be good or bad. In other words, having an interface in a singleton design is not characteristic to this design pattern. Again, the question probably reflects the experience of the interviewer. I would guess, either narrow experience, not not properly analyzed or generalized.
  • And finally, I'll try to answer your own question about "static singleton". In a way, it's more interesting than both interview question, but is not quite correct. "Static" — what? Static class representing singleton functionality? The use of static member in a singleton class? A static object immediately exposed to the singleton user? What?

    Whatever it is, a static object is usually involved. Because, ultimately the singleton object should always be the same. From the other hand, it would be bad to directly expose a static object to the user. For further detail, please see the code sample I referenced below.

    From the other hand, it's not really required to use anything static for singleton implementation. Why? Because it's main characteristic "always one", "always the same object" has its scope. Most usually, this is the application domain of a single application. But it could be something else, say, a singleton maintaining its identity across all of the applications on the same computer (or the same session). Or, even wider, across many computers communicating with the same online service.

    But let's back to the most usual singleton, the one in the scope of the application domain. Imagine that you create some object in a normal way, only once, in your program's entry point method ("Main"). And then pass this only object to all other methods (including constructors). The object is still only one. By the way, this is another answer to the first interview question.

    Even though the object in this example is single, some may not agree to call it "singleton", but this is just a non-essential matter of terminology.


单例不是静态的,因为a静态对象在应用程序加载时在堆栈上分配,其中在首次使用时在堆上分配单例。

因为单例是一个普通对象实例,它提供了基于类的方法,它可以实现接口,而静态类则不能。它也可以作为普通对象传递,而不需要任何装箱或取消装箱。

假设您的单件类派生自Stream,并提供对特定硬件的访问。任何接受流的方法都可以作为参数传递给你的单例类实例,而不需要知道它是特殊的。你不能用静态类做到这一点,因为它无法实例化。

继承形式接口在你需要实现接口时非常有用!例如,您的单例可以实现IEnumerable,然后可以在 foreach 循环中使用它的实例。
A singleton isn't static because a static object is allocated on the stack at application load time, where a singleton is allocated on the heap when it is first used.
Because a singleton is a "normal" object instance, it provides class - based methods, and it can implement Interfaces, which static classes can't. It can also be passed around as a normal object without any boxing or unboxed being required.
Suppose your singleton class is derived from a Stream, and provides access to a specific piece of hardware. Any method which accepts a stream can be passed your singleton class instance as a parameter, and doesn't need to know it's "special". You can't do that with a static class because it can't be instantiated.
The inheritance form Interfaces is useful when you need to implement an interface! For example, your singleton could implement IEnumerable and it's instance can then be used in a foreach loop.


这篇关于单例作为c#中的参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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