I have a helper class that takes some object, processes it and returns back some instance of the other class or even the List of the objects.
What would be the best way: to make this helper method static or non-static?
The thing is that my app can create lots of the Car objects and I was thinking whether it could have a negative effect when each of them use the static helper?
Probably this is something that can be solved without deciding the helper object's life-cycle where you require it.
You should try to leverage dependency injection approach:
public class X
{
public X(IHelper helper)
{
Helper = helper;
}
private IHelper Helper { get; }
public void DoStuff()
{
var result = Helper.DoOtherStuff(input);
}
}
That is, X don't know whether Helper is always the same instance or if it's a transient object. This makes the code cleaner and more test-friendly, because you can mock the helper with a fake IHelper implementation to be sure that you're just testing X.
Most helper or utility classes use static methods. You should only use non-static methods if you want to create multiple instances of your helper class, but since you just need a simple input -> function -> output, I would make the methods static.
Use static class with static methods, No instance, no derivation and only static methods in the class.
public static class HelperClass
{
public static void HelperMethod()
{
// do something
}
}
Related
A Quick Note
The code in this post is built on top of a in-house built DirectX-11 engine which means it follows the strict pattern of:
Initialize
while (Running) {
Update
Render
}
However, do not let this deter you as the problem is not related to the DirectX code but instead static classes and methods.
Overview
I have a class called RenderObject which contains a method called Initialize. This method is responsible for building the object's mesh, assigning textures, shaders, and more.
public class RenderObject {
public virtual void Initialize() { }
}
I also have a few static classes that hold reusable assets such as common textures, shaders, models, and meshes. This way I don't have to reload them later. All of these static classes also contain a method called Initialize which is responsible for creating these reusable assets. For this question I will limit this to just the Textures class.
public static class Textures {
public static Texture2D Dirt { get; private set; }
public static Texture2D Grass { get; private set; }
public static void Initialize() {
Dirt = new Texture2D(...);
Grass = new Texture2D(...);
}
}
Finally, I have a class called LoadingSystem which is responsible for loading reusable assets and initializing objects. I initialize this class inside of the Initialize method of my engine, and then call the class' Update method in the Update method of the engine respectively. The LoadingSystem's Update method is responsible for loading and initializing objects using a Queue which is useful for supplying smooth visual feedback.
public class LoadingSystem {
public bool Loading { get; private set; } = true;
private Queue<RenderObject> objectsToRender;
public void AddForLoad(RenderObject obj) => objectsToRender.Enqueue(obj);
public void Update() {
if (objectsToRender.Count > 0) {
RenderObject obj = objectsToLoad.Dequeue();
obj.Initialize();
} else Loading = false;
}
}
The Problem
I would like to call the method Initialize on these static classes with the same process used for the RenderObject queue. Currently I'm forced to do:
CurrentMessage = "Loading Textures";
Render();
Present();
Textures.Initialize();
Progress = ++objectsLoaded / objectsToLoad;
CurrentMessage = "Loading Shaders";
Render();
Present();
Shaders.Initialize();
Progress = ++objectsLoaded / objectsToLoad;
CurrentMessage = "Loading Models";
Render();
Present();
Models.Initialize();
Progress = ++objectsLoaded / objectsToLoad;
I've slimmed it down to a method that handles the repetitive setting of the message, and calls to Render and Present but this is still tedious and it should go through the Update method once per object to remain consistent with the rest of the code.
My Thoughts
I understand that a static class cannot inherit from a class or implement an interface so I am wondering if there is a way to provide a static class and call its Initialize method in a similar manner; even if this means creating a separate method to accomplish it.
I have currently considered two options:
Load static classes individually.
Convert static classes to instance classes and call them with the queue.
The problem with the first option is that I have 12 static classes and would have to update progress and feedback messages, raise events, and re-render the scene for each one.
The problem with the second option is that these static classes only contain static properties and thus by definition should be static as there is no need to ever inherit from them or create an instance of them.
The Question
Is there a way to call a common method across multiple static classes?
Perhaps a way to call the method if it exists with generic types like object or T?
Perhaps the dynamic type may work (though you can't create an instance of static classes)?
I have currently considered two options:
Load static classes individually.
Convert static classes to instance classes and call them with the queue.
A third compromise approach relates to your second idea above, but uses a design pattern known as the Singleton Pattern. Like static classes, there can only be one of them in your process and everyone gets that same thing, however unlike static classes, Singletons can implement interfaces or even descend from other classes.
For this example, I will use the interface approach.
public interface IInitializable
{
void Initialize();
}
All the interface does is to enforce that its implementer has an Initialize method.
My next step is to create a Singleton class. There are a couple of rules to implement the Singleton pattern. Your class must be sealed. Its constructor must be private. It must have a static method or property to return the single instance. That method/property must be threadsafe.
I have used Lazy to do the heavy lifting for me
public sealed class Foo : IInitializable
{
public void Initialize()
{
// Initialize my foo
}
private Foo()
{
}
private static Lazy<Foo> fooLazy = new Lazy<Foo>(() => new Foo());
public static Foo Instance => fooLazy.Value;
}
There are some minor differences to what you were doing with static classes. If Foo was a static class, you would call Foo.Initialize(); As it is Singleton, you would call Foo.Instance.Initialize();
Any other methods or properties would most likely be non-static.
Pulling it all together, you could write code like this. Your queue does not need to know about the classes it holds. You don't actually care. You only want to know that it has the Initialize() method
public class YourClass
{
private Queue<IInitializable> objectsToLoad = new Queue<IInitializable>();
public void Enqueue(IInitializable obj)
{
this.objectsToLoad.Enqueue(obj);
}
public void LoadOrUpdate()
{
// Update Method
if (objectsToLoad.Count > 0)
{
IInitializable obj = objectsToLoad.Dequeue();
obj.Initialize();
}
else
{
// Loading complete.
}
}
}
This class could then be used like this
YourClass yourClass = new YourClass();
yourClass.Enqueue(Foo.Instance);
yourClass.LoadOrUpdate();
Though I hope there is a much better and more detailed answer than this; I've come up with a basic solution. I created a separate Queue<Type> where I add the static classes. I then call their Initialize method with the following:
Type t = typesToInit.Dequeue();
t.GetMethod("Initialize").Invoke(null, new object[] { 0 });
This works well and is rather clean, but I can't help but wonder if there is a better way to do this?
I have a class
public class Foo{
public Foo{...}
private void someFunction(){...}
...
private Acessor{
new Acessor
}
}
with some private functionality (someFunction). However, sometimes, I want to allow another class to call Foo.SomeFunction, so I have an inner class access Foo and pass out that:
public class Foo{
public Foo{...}
private void someFunction(){...}
...
public Acessor{
Foo _myFoo;
new Acessor(Foo foo){_myFoo = foo;}
public void someFunction(){
_myFoo.someFunction();
}
}
}
With this code, if I want a Foo to give someone else pemission to call someFunction, Foo can pass out a new Foo.Accessor(this).
Unfortunately, this code allows anyone to create a Foo.Accessor initiated with a Foo, and they can access someFunction! We don't want that. However, if we make Foo.Accessor private, then we can't pass it out of Foo.
My solution right now is to make Acessor a private class and let it implement a public interface IFooAccessor; then, I pass out the Foo.Accessor as an IFooAccessor. This works, but it means that I have to declaration every method that Foo.Accessor uses an extra time in IFooAccessor. Therefore, if I want to refactor the signature of this method (for example, by having someFunction take a parameter), I would need to introduce changes in three places. I've had to do this several times, and it is starting to really bother me. Is there a better way?
If someFunction has to be accessible for classes in the same assembly, use internal instead of private modifier.
http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.71).aspx
If it has to be accessible for classes which are not in the same assemble then, it should be public. But, if it will be used by just a few classes in other assemblies, you probably should think better how you are organizing you code.
It's difficult to answer this question, since it's not clear (to me at least) what exactly you want to achieve. (You write make it difficult for someone to inadverdantly use this code in a comment).
Maybe, if the method is to be used in a special context only, then explicitly implementing an interface might be what you want:
public interface ISomeContract {
void someFunction();
}
public class Foo : ISomeContract {
public Foo() {...}
void ISomeContract.someFunction() {...}
}
This would mean, that a client of that class would have to cast it to ISomeContract to call someFunction():
var foo = new Foo();
var x = foo as ISomeContract;
x.someFunction();
I had a similar problem. A class that was simple, elegant and easy to understand, except for one ugly method that had to be called in one layer, that was not supposed to be called further down the food chain. Especially not by the consumers of this class.
What I ended up doing was to create an extension on my base class in a separate namespace that the normal callers of my classes would not be using. As my method needed private access this was combined with explicit interface implementation shown by M4N.
namespace MyProject.Whatever
{
internal interface IHidden
{
void Manipulate();
}
internal class MyClass : IHidden
{
private string privateMember = "World!";
public void SayHello()
{
Console.WriteLine("Hello " + privateMember);
}
void IHidden.Manipulate()
{
privateMember = "Universe!";
}
}
}
namespace MyProject.Whatever.Manipulatable
{
static class MyClassExtension
{
public static void Manipulate(this MyClass instance)
{
((IHidden)instance).Manipulate();
}
}
}
I want to write a static utility class which only has a set of properties, which expose functionality to the user
For example I could call:
Utils.String.GetHexString("Hello World");
or
Utils.Stream.CopyBytes(instream, outstream);
The closest thing I could liken this to is System.Text.Encoding where there are properties like UTF8, ASCII etc, so yo can call things like:
Encoding.UTF8.GetBytes("Hello World");
or
Encoding.ASCII.GetBytes("Hello World");
The problem is that in Encoding, this calls the equivalent objects (UTF8Encoder, ASCIIEncoder) which are publicly available to the user. What I want is to expose the objects ONLY via Utils, without visibilty of the objects that relate to the properties, for example
I could call:
Utils.Stream.CopyStream(instream, outstream);
but I could not call:
StreamUtils.CopyStream(instr, outstr) //This class is only accessible via the Utils class!
Is this possible, and if it is, is it going to be good or bad practice to do so?
Here's an idea:
public interface IStreamUtil
{
void CopyStream(Stream int, Stream out);
}
internal class StreamUtil : IStreamUtil
{
// Implementation
}
public static class Util
{
private static IStreamUtil stream = new StreamUtil();
public static IStreamUtil Stream
{
get { return stream; }
}
}
To me, however, this is somewhat of a strange practice. Personally I prefer extension methods for utility functionality:
inStream.CopyStreamTo(outStream);
myString.GetHexString();
which can also be considered bad, especially taking into account extension method discovery and resolution algorithms. Good ol' StreamUtil.Copy() is just fine for most cases.
It is not possible to prevent any user from creating a variable of your StreamUtils type and e.g. assigning the value retrieved from your Utils.Stream property.
However, there are two solutions:
You can prevent users from creating instances of your StreamUtils class themselves by making the constructor internal. Like that, only your Utils class (to which you can grant internal access, be it by placing it in the same assembly or by using the InternalsVisibleTo attribute) can instantiate your StreamUtils class, while users of your library can only use the functions of your instance, but cannot create their own instance.
Another approach is using public nested static classes. Within your Utils class, you could declare a nested public static class Stream that offers the methods you need as static methods. Like this, users could not instantiate their own Stream instance (as it's static), and at least in C#, you would even force users to always write Utils.Stream to access your methods, if that is what you really want. Note, however, that this approach does not seem as clean as the first one and will cause breaking changes (at least on the binary level), should you ever decide to exchange the static classes with property getters or anything else.
What you want is possible, but you shouldn't see Utils as a class itself, but as a namespace that contains some static utility classes:
namespace Utils
{
public static class String
{
public static string GetHexString(string input)
{
...
}
}
public static class Stream
{
public static void CopyBytes(System.IO.Stream instream, System.IO.Stream outstream)
{
...
}
}
}
Whether this is a recommended practice or not, is a completely different issue. The problem with too many static utility classes, is that you can't have loose coupling by using dependency injection. This can make it harder to write good unit tests.
Looking at what you are trying to achieve, I suggest, try and develop extention methods.
Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type.
Read more on the hyperlink provided here.
Ok, basically it's no possible (in C# at least) to achieve exactly what I want. The class must be visible for the functionality to be visible through the Util class.
My solution was to turn the classes (e.g. StreamUtils, StringUtils) into singletons. They cannot be constructed because their constructors are internal. their methods are public but can never be seen because the object cannot be instantiated outside of my assembly. The Utils class exposes the functionality to the user via the singleton instance.
Consider the following:
class StreamUtils
{
static StreamUtils instance;
internal static StreamUtils Instance
{
get
{
if(instance == null)
{
instance = new StreamUtils();
}
return instance;
}
}
internal StreamUtils()
{
}
public void CopyStream(Stream input, Stream output)
{
}
}
static class Utils
{
public StreamUtils Stream
{
get
{
return StreamUtils.Instance;
}
}
}
I created a class with 6 private static methods and a private constructor. The private constructor runs all of the static methods. I want to call the class's private constructor in another class, but I'm not able to. All I want is to run this class once without creating an instance of anything. The class populates a small database and I have no need for it other than calling it once.
I could put it into a method, but I don't want to put unrelated code into my main class. I want everything more separated. I could just do it with a public constructor and create an instance of the class, but I don't see why I would have to do it that way when an instance isn't needed.
Is there a good way to accomplish what I'm trying to do?
Why not replace your private constructor with a public static method?
Your original code:
public class DatabaseInitializer
{
private DatabaseInitializer()
{
init1();
init2();
...
}
private static void init1() { ... }
private static void init2() { ... }
...
}
Your new code
public class DatabaseInitializer
{
public static void Init()
{
init1();
init2();
...
}
private static void init1() { ... }
private static void init2() { ... }
...
}
Than you call it:
Main()
{
DatabaseInitializer.Init();
}
Singleton would make exact one Instance. If you don't want an Instance, just make one static method public. If you want to make sure this is called only once make a static counter or a bool in your class which stop the method from being called a second time
call constructor without an instance is impossible, even if it was public
I want to call the class's private constructor in another class
--
All I want is to run this class once without creating an instance of anything
If you do not want to create an instance of your class, then do not use the constructor. I think you just want to use a class to "separate" some code? Use a static method for that.
Or if this code should run once and call some static methods. You can use a static ctor
class B
{
static B() {
//this stuff called when you create this class or when a static member is referenced
}
IMHO, this is not an unrelated code for main class. It's dependent on these methods.
You could just have one public method in the class. Dependent classes can then call that method which in turn calls all the private methods doing processing.
If you want to call it or its members from another class, you will need to make a public method.
If you don't want any instances of this class around, then you should make a public static method that can be called.
The public static method should have a static boolean. When called, it checks that value, and if not set, switches the static boolean value (so it knows it has been called before) and then calls all the private static methods that need to be run once and only once.
If you only need this initialization done once ever to the database, rather than once per effort, then you should have your static code run out and check the database to see if it has already been initialized. You could make this particularly easy by having a one row table that holds a boolean in it that you can test. Just update the initialization code to set that value when the DB is initialized, and have your start up code test for that value to determine its value and what actions to take based upon that value.
When should I prefer either a static or a normal class? Or: what is the difference between them?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace staticmethodlar
{
class Program
{
static void Main(string[] args)
{
SinifA.method1();
}
}
static class SinifA
{
public static void method1()
{
Console.WriteLine("Deneme1");
}
}
public static class SinifB
{
public static void method2()
{
Console.WriteLine("Deneme2");
}
}
public class sinifC
{
public void method3()
{
Console.WriteLine("Deneme3");
}
}
public class sinifD : sinifC
{
void method4()
{
Console.WriteLine("Deneme4");
}
sinifC sinifc = new sinifC(); // I need to use it :)
}
}
Static classes contain static objects that can't be instantiated multiple times. Usually what I use static classes for are to house static methods that provide calculations, general processing patterns, string output formats, etc. Static classes are light weight and don't need instantiation.
For instance System.IO.File is a static class with static a method Exists(). You don't create a File object to call it. You invoke it like this
System.IO.File.Exists(filePath)
Rather than doing this
System.IO.File myFile = new System.IO.File(filePath);
if(myFile.Exists())
{ /* do work */ }
If you require several objects in software, then you use dynamic classes. For instance if you have an inventory system you may have several Product objects and in that case you would use a dynamic class such as this
public class Product
{
public int ProductID { get; private set; }
public string ProductName { get; private set; }
public int Qty { get; set; }
public Product( int productID, string productName, int total )
{
this.ProductID = productID;
this.ProductName = productName;
this.Qty = total;
}
}
static classes cannot be instantiated or inherited.
static classes are marked as sealed and abstract by compiler in the output MSIL.
all members of static classes must be static as well.
only static classes can host extension methods.
static classes cannot be used as generic type arguments.
You can create instances of "normal" classes via the class constructor.
var normal = new Normal();
You cannot create instances of static classes. They can only have static methods.
Also worth noting is that you must declare extension methods in static classes.
From the MSDN documentation on static classes:
A class can be declared static, indicating that it contains only static members. It is not possible to create instances of a static class using the new keyword. Static classes are loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.
In simple terms:
A static class cannot be instantiated using the new keyword.
All methods in a static class must be static and can be called directly without instantiation.
A "normal" class MUST be instantiated however any static methods in a "normal" class can be called without instantiation.
Non static methods in a "normal" class cannot be called without first instantiating the containing class.
Static members can be called without using an instance of the class. For example, a static Math class with an Area method call be called by Math.Area without instantiating the Math class first.
A normal class is one which you can instantiate and can use with objects.
A static class is one which can not be instansiated and can't be extended.
That means a static class is sealed and abstract by default, you may look at the
MSIL of a static class compiler puts sealed and abstract in front of a static class.
So, because a static class can't be instantiated, you can't have instance methods defined
on static classes, so all methods must be static and public ofcourse as you would want to
use them.
A static class is singleton by default.
Static classes are used for defining extension methods because you don't want to
instansiate them.
Static classes are like global provider of unique services.
I hope that make sense to you and will help you to understand the static classes.
It might help to think of "static" and "instance" in terms of memory addressing.
An object that is static exists in one and only one location in memory; you can't create instances of it because by definition it has been stated that it will be found in one particular location. It is "static" and unchanging. The creation of the object is implicit rather than explicit.
var result = Math.Pow(3, 3); // static - Math class can't be instanced
An object that isn't static can be instanced one or more times; you're saying, "Create for me an object of this type" and the object is given a memory address. You can create multiple instances that all exist in different memory addresses. The creation of the object is explicit using the new keyword.
var Ted = new Employee(); // instance - creates a new object at a new address
This is where people get into trouble in ASP .NET web programming; static classes are created once per Application Domain and their constructors are therefore only called once.
A static class is one that cannot be instantiated. Therefore, it cannot be used as a 'template" for multiple instances of some object that conforms to the class definition as a normal class can. In a normal class, the data members defined are created for each "instance" of the class, and each "instance" has it's own set of these data members, so these instances represent individual "entities" or complex in-memory data structures for some object (which you coded the class to represent).
When you define (code) a static class, all of it's data fields must also be static, meaning that they cannot be instantiated once for each instance of the class, (you can't create instances of a static class ). Static classes are useful only when you just need a container to hold methods that do not depend on the state of some object or data structure being managed by the application (like an add function, or a string formatter, etc.)