Sorry for the unlearned nature of this question. If there's a simple answer, just a link to an explanation will make me more than happy.
After 6 months programming I find static classes to be somewhat useful for storing routines that apply to many different classes. Here's a simplified example of how I use static classes, it's a class for parsing text into various things
public static class TextProcessor
{
public static string[] GetWords(string sentence)
{
return sentence.Split(' ');
}
public static int CountLetters(string sentence)
{
return sentence.Length;
}
public static int CountWords(string sentence)
{
return GetWords(sentence).Length;
}
}
And I use this in obvious ways like
class Program
{
static void Main(string[] args)
{
string mysentence = "hello there stackoverflow.";
Console.WriteLine("mysentence has {0} words in it, fascinating huh??", TextProcessor.CountWords(mysentence));
Console.ReadLine();
}
}
My question is: Why is it necessary to wrap these static methods in a static class?
It seems to serve no purpose. Is there a way I can have these methods on their own not wrapped in a class? I know encapsulation is beneficial but I don't see the use for static methods wrapped in static class. Is there something I am missing stylistically or otherwise? Am I completely barking up a silly tree? Am I thinking too much?
In C#, any method has to be declared inside a class. That's just how the language is specified.
A static class is actually more akin to a module than a class, so I too think you should be able to either:
define a function outside a class or;
import a module the same way you import a namespace (with using)
VB.NET, F# and Nemerle actually allow you to declare modules and import them; what allows you to use their methods unqualified.
This is valid Nemerle:
using System.Console; // import static methods in the Console class
class Hello {
static Main() : void {
WriteLine("Hello, world!"); // unqualified access!
}
}
Also, take a look at extension methods, they might allow you to "solve" this in a different way. The methods in your TextProcessor are begging to be string extension methods.
This post by eric lippert gives a pretty detailed explanation. I'm not sure if this guy "eric" knows what he's talking about or not though ;-)
It would be somewhat awkward to have methods just dangling around in a random namespace.
I suspect the answer is to provide "scope". Just because a method is static, doesn't mean it doesn't have a scope. It can still access other static private methods or member variables - and the class provides a "home" for these things to live in.
Static classes can also have static constructors that get called the first time a static method is used, so this provides the ability to set stuff up as needed.
It's more of an organizational design than anything to due with technical limitations.
A static method is a method called in a single instance of a class that is created at run-time.
Related
It's extremely lazy, but I'm wondering if it's possible to have two names point to the same static class in essence.
I have a long and descriptive static class name BusinessLogicServiceUtility (as example) and it's looking rather long-winded in code.
I'd love to use BLSU as an alternative, so I tried extending the long class with my short class name:
public static class BLSU : BusinessLogicServiceUtility
{
}
Which probably looks noob but as it turns out, it doesn't work.
It looks as though I could wrap each method in the long class with a method inside the short class, but there's a lot of methods, which makes maintaining it a pain and circumvents the whole laziness goal.
Is there a way of assigning two names to one static class, or some other method simply "extending" a static class?
You can create an alias for a type:
using BLSU = Your.Namespace.BusinessLogicServiceUtility;
Accessing members of type:
BLSU.SomeStaticMethod();
With C# 6 you can even go further - access static members of a type without having to qualify type name at all:
using static Your.Namespace.BusinessLogicServiceUtility;
Accessing members of type:
SomeStaticMethod();
Further reading: using Directive (C# Reference)
In addition, you can use using static that will allow you to use the methods without prefixing them with the class at all:
at the top of the file :
using static BusinessLogicServiceUtility;
and say you have a method public static DoLogicThings() in your static class, you can access it directly now:
public void SomeMethod()
{
DoLogicThings();
}
this was added in C#6.
I am pretty new to C# programming, and I am still learning. I was wondering if there is any particular reason to not use the static modifier when creating a method, for me it just seem much simpler. I tried looking at MSDN but that isn't much help if I don't know what half the words mean.
For example this:
using System;
namespace StaticModifier
{
class Program
{
static void Main(string[] args)
{
SayHi();
}
static void SayHi()
{
Console.WriteLine("Hi");
}
}
}
Seems much simpler than this:
using System;
namespace StaticModifier
{
class Program
{
static void Main(string[] args)
{
Program p = new Program();
p.SayHi();
}
void SayHi()
{
Console.WriteLine("Hi");
}
}
}
So would anyone be willing to explain? Keep in mind that I am pretty new so please keep it simple :)
A non-static method of the class Program provides the current instance of the class Program..
Since Program doesn't contain any variables or properties that are used, you don't need to molest your CPU with unnecessary objects.
And Program p = new Program(); is not the way you would instantiate your "Program". The Main() method is static and is usually contained within a static class with static methods. You can't call dynamic methods from a static method, since there is no instance of the object.
TL;DR
If you want to pass this (the current object) to the method and your method utilizes its properties, then don't use static. Otherwise there is absolutely no reason not to use static!
You wouldn't use the static modifier if you had a class that would require more than 1 instance of itself. For example if you have a class named car that included the static keyword you would only ever be access the members of that class via the static reference of that class. So you could never have 2 instances of a car object.
Which depending on what your program is trying to do maybe appropriate. However you may look to use the static keyword if you had a class names player score. As this would only ever exist once, and unless you have more that one player you would want 1 instance of the player score. Which means you could either consider a singleton instance or just have a static class.
There are many many reasons why you either would or wouldn't make use of the static modifier. However to some up when you should use it is impossible and depends on the specific scenario of the application you are creating.
I am developing C# and asp.net web application.
I have general class called utilities, I have lot of public and static variables in this public utilities class.
Since this number is gradually increasing, I want to know is it good practice to store utilities methods and variable as public static.
Example of my code
public class utilities
{
public static string utilVariable1 = "Myvalue";
public static string utilVariable2 = "Myvalue";
public static string utilVariable3 = "Myvalue";
:
public static string utilVariableN = "Myvalue";
public static string UtilMethod1()
{
//do something
}
public static string UtilMethod2()
{
//do something
}
public static string UtilMethodN()
{
//do something
}
}
There's nothing inherently wrong with static classes, although they should typically not have state (fields). Your use of public static fields indicates that this is not the case, so it seems like you are using abusing the static keyword slightly. If your class needs to have state, then it should be a normal, non-static class, and you should create instances of it. Otherwise, the only public fields visible on the class should be const (consider the Math class, with constants such as Math.PI - a good use of static methods and fields).
Another consideration is cohesion. Methods typically exist grouped in one class because they are closely related in one way or another. Again, the Math class is a good example; everything in there has to do with maths. At some point, you would want to split your global utility class into multiple smaller, more focussed ones. See Wikipedia for some examples on cohesion, it sounds like your usage falls under "Coincidental cohesion (worst)".
There's nothing wrong with this approach for methods, but variables should really be const if they're going to be static and public. If they are subject to change then you should look at a different structure for variables that are being manipulated by more than one component.
Personally, I'm a fan of the Singleton pattern.
static is not a bad thing per se. Methods that don't need to access any member variables or methods should always be declared static. That way the reader of the code sees immediately that a method won't change member variables or methods.
For variables the situation is different, you should avoid static variables unless you make them const. Public static variables are globally accessible and can easily raise issues if multiple threads access the same variable without proper synchronization.
It is hard to tell for your case if it's a good or a bad idea to use statics, because you didn't provide any context information.
Creating one class to do it all is not a good practice, and it's recommended to structure your project, and keep stuff that belongs to each other separated from the randomness.
A great example of this was a project I took over from a co-worker. There was 1 class, called Methods. It contained over 10K lines of methods.
I then categorized them into approx. 20 files, and the structure was restored.
Most of the methods from that project were validating user input, which can easily be moved into a static class Validation.
One awful thing I notice is the mutable public and static variables. This is bad for several reasons:
Incorrect behavior, because if some method changes this, while it isn't supposed to do that, it causes other methods to behave improperly, and it's really hard to track down/debug.
Concurrency, how are we going to ensure thread safety? Do we let it over to all methods that work with that? Say if it's a value type, what will we let them lock on? What if some method forgets to make it thread safe?
Expand-ability (I hope you understand what I mean with that), if you have for example a static class data that stores all these public static variables, that you shouldn't have. It can store that once, if for example you might change your application structure a bit, and say want to make it possible to load two projects in the same screen, then it's very difficult to make that possible, because you can't create two instances of a static class. There is only one class, and it'll remain like that.
For number 3 a cleaner solution would be to store either a list of instances of a data class, or to store a reference to the default and/or active data class.
Static member, and private static members (or protected) are a good practice, as long as you don't make huge classes, and the methods are related.
Public and static variables are okay if they're not really variable.
The two ways to do this is by marking them constant (const modifier) or readonly (readonly modifier).
Example:
public class UtilitiesClass
{
internal UtilitiesClass() { }
public void UtilityMethod1()
{
// Do something
}
}
// Method 1 (readonly):
public static readonly UtilitiesClass Utilities = new UtilitiesClass();
// Method 2 (property):
private static UtilitiesClass _utilities = new UtilitiesClass();
public static UtilitiesClass Utilities
{
get { return _utilities; }
private set { _utilities = value; }
}
The advantage of method 1 is that you don't have to worry about thread-safety at all, the value can't change.
Method 2 is not thread-safe (though it's not difficult to make it that), but it has the advantage of allowing the static class itself to change the reference to the utilities class.
No, it is not a good practice for large applications, especially not if your static variables are mutable, as they are then effectively global variables, a code smell which Object Oriented Programming was supposed to "solve".
At the very least start by grouping your methods into smaller classes with associated functionality - the Util name indicates nothing about the purpose of your methods and smells of an incoherent class in itself.
Second, you should always consider if a method is better implemented as a (non-static) method on the same object where the data that is passed as argument(s) to the method lives.
Finally, if your application is quite large and/or complex, you can consider solutions such as an Inversion of Control container, which can reduce the dependency on global state. However, ASP.Net webforms is notoriously hard to integrate into such an environment, as the framework is very tightly coupled in itself.
This might be a little subjective, but I'd like to get your input on my current situation. I have a class that will be used to serialize/deserialize an object.
public class MyClass
{
public static string ToXmlString( MyClass c ) { /*...*/ }
public static MyClass FromXmlString( string xml ) { /*...*/ }
}
I only like this approach because it keeps the two functions at the same level. However, my goal is to avoid using static methods (when feasable). It also feels like I might be vilolating SRP, but the main goal of this object is that it can be seriliazed/deserialized from an xml string.
Any thoughts on the use of static methods in this situation? Should I just make the ToXmlString non-static, but leave the FromXmlString static? Should I create a new class that will only handle serilization of MyClass?
EDIT:
The class that I'm discussion here is a simple transfer object. It is used to save/restore values from a thrid party tool.
Thanks!
FWIW I think that serialization is a problematic that should be separated from the rest of your class, above all if your class is a business type.
The general rule when developing a component is to ensure that it only addresses a few concerns and to separate business concerns from technical ones.
What if later you need to manage serialization from a database or a binary format ?
You might end with more and more technical methods (SaveToDB, LoadFromDB, ToBinaryStream, FromBinaryStream...) that would clutter your class and make it more and more difficult to maintain, hiding its primary purposes (business for example).
The convention in the standard libs for both C# and Java is that To__ methods are instance methods and From__ methods are static (by necessity). For example: ToString() is an instance method.
Elaborating on Benoit's answer, here's an example where the class that is being serialized defines the serializing behavior (I did not write this):
// : c12:SerialCtl.java
// Controlling serialization by adding your own
// writeObject() and readObject() methods.
// From 'Thinking in Java, 3rd ed.' (c) Bruce Eckel 2002
// www.BruceEckel.com. See copyright notice in CopyRight.txt.
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
public class SerialCtl implements Serializable {
private String a;
private transient String b;
public SerialCtl(String aa, String bb) {
a = "Not Transient: " + aa;
b = "Transient: " + bb;
}
public String toString() {
return a + "\n" + b;
}
private void writeObject(ObjectOutputStream stream) throws IOException {
stream.defaultWriteObject();
stream.writeObject(b);
}
private void readObject(ObjectInputStream stream) throws IOException,
ClassNotFoundException {
stream.defaultReadObject();
b = (String) stream.readObject();
}
public static void main(String[] args) throws IOException,
ClassNotFoundException {
SerialCtl sc = new SerialCtl("Test1", "Test2");
System.out.println("Before:\n" + sc);
ByteArrayOutputStream buf = new ByteArrayOutputStream();
ObjectOutputStream o = new ObjectOutputStream(buf);
o.writeObject(sc);
// Now get it back:
ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(
buf.toByteArray()));
SerialCtl sc2 = (SerialCtl) in.readObject();
System.out.println("After:\n" + sc2);
}
}
Note the use of transient to describes fields that will not be serialized.
If you want a standard serialization (XML or not), both serialize/deserialize methods should not be static.
In MyClass, you should redefine "writeObject" and "readObject" to replace the default serialization methods by yours. Here is a Sun tutorial about theses methods.
If you don't want a "standard serialization", using static methods looks fine for me. Static util methods are not an heresy.
PS : it is not the question, but if you want WML serialization, you can use the XStream API.
You could define a constructor that takes an XMLReader (or a string if you really insist). The main advantage of this is that it allows you to have stronger invariants in your class, and to be explicit about any immutable members through the use of readonly.
I don't think it's too terrible for complementary methods to be separated with regard to static vs. instance, since the Framework does this occasionally (String.Split / Join, for example).
But having said that, I think the goal of minimizing the use of static methods is not a good idea. The thing to avoid is static mutable state, not static methods. A static method that only operates on its parameters, rather than static variables, is pure awesomeness.
A pure static function can be more maintainable than an instance method, since the instance method does not communicate in an obvious way which instance fields it can mutate. By following the rule that no static state whatsoever is maintained, a static method can be relied upon to only operate on its parameters, and thus the method's role in the application can be better predicted. This is especially important when multi-threading.
Since the ToXmlString method is being applied to an instance of the class in which it is defined, some of these considerations don't apply. It could easily change the state of the object that is being passed to it in underhanded ways, since it can access all the private members of the instance. But I just mean to say that as a general rule static methods are not a problem.
I found myself having to remove the first line of a string quite often while working on a text parser in C#. I put together a simple function to do that for me, but coming from a PHP background, I have no idea where to put it since I can't define a function outside a class. What's a customary way of doing that in .NET? Do I create a static class to store my function?
I generally make a Helper or Utility static class and then put corresponding helper functions in there.
Additionally, I try to keep the Helper and Utility classes grouped logically - putting the text parsing functions alongside the object conversion functions is nonsensical. The confusion is cleared up with a TextUtils class and a ConversionUtils class.
Yes, static helper classes are usually the way to do this.
Also, in C# 3 you can declare the method like this:
public static string RemoveFirstLine(this string s) {
...
}
to make it an extension method. Then you can call it on any string as if the method was declared on the string type itself.
Be careful!
Generic utility functions which are cross cutting should live in a higher utility namespace. String parsing, File manipulation, etc.
Extension objects should live in their own namespace.
Utility functions that apply to a specify set of business objects or methods should live within the namespace of those objects. Often with a Helper suffix, ie BusinessObjectHelper. Naming is important here. Are you creating a container for miscellaneous methods, or would it make more sense to group them into specialized objects, ie a parser?
I don't think there's a standard for this. I tend to make a static class called BlahUtil. For your example, I'd make it a static method on StringUtil. This helps me group related methods into sensible units, making it easier to discover them and share them across teams.
You can also then choose which of these methods are exposed as extension methods (since c# 3.0):
public static class StringUtil
{
public static string RemoveFirstLine(this string multiLineString)
{
// ...
}
}
If you are using C# 3.0, you might want to consider using an extension method!
public static class StringExtensions
{
public static string RemoveFirstLine(this string myString)
{
return myString.Remove("line..!");
}
}
Then in code you can do this:
string myString = "Hello World etc";
string removedLineString = myString.RemoveFirstLine();
Usually I create a Utilities class and define static helper methods.
I've done the static "helper" classes but after some analysis; this type of helper function always ends up as a distinct class implementation. In your case you'd have a "basic text parser" class and a derived class that overrides the "parse" method.
I'd create a static worker class for such functions. Maybe not the nicest way, but the one which keeps things simple... ;)
K
Use an extension method for a string. That's what they are for.
You can use a class with static methods. Something like ParserUtils.RemoveFirstLine(). On .NET 3.5 and above you can sometimes use extension methods when your utility functions are related to a class you cannot modify, like the String class. Intellisense will show the extension method on any string object in the project.
Extensions are the way to go in those case. It literally add your function to the occurence. Only thing is that it's not possible to do static method in 2008.