We have a large class that contains a bunch of css selectors stored as static strings. Example:
public class Constants
}
public static string Selector1 = "#someID";
public static string Selector2 = ".some.classes a";
// and so on...
}
We now need to test a different version of our web app which requires a few different selectors. So we need to find a clean scalable way to override these selectors based on some configuration.
My solution to the problem is this: I'm trying to create a BaseConstants class which will have the current set of selectors. Then I create another class called UpdatedConstants which will subclass the BaseConstants class. This class will then contian all the selectors and just override the ones that need changing with the new keyword. Example:
public class UpdatedConstants : BaseConstants
{
// Overrides the base class's Selector1 string
public new static string Selector1 = "#someOtherID";
}
This works well for overriding the strings however I'm stumped as to how the project will decide which static class to use when it is compiled. All our existing code uses the Constants class like this:
var element = driver.GetElement(Constants.SomeSelector);
Is there a way to dynamically decide which class is the final Constants class? Perhaps by some meta-programming magic?
Let me know if anyone has questions or needs a better explanation of the problem. Thanks
Make your constants classes non-static and use a singleton. This also lets you use virtual properties, since you want to use a base Constants class.
public static class Constants
{
static Constants()
{
#if FOO
Current = new ConstantsFoo();
#elif BAR
Current = new ConstantsBar();
#endif
}
public static ConstantsBase Current { get; private set; }
}
//...snip
var element = driver.GetElement(Constants.Current.SomeSelector);
If you don't want to change all occurences Constants.SomeSelector, the only way to have different behavoirs is using pre-processor directives in the Constants class:
public class Constants
}
#if OLD
public static string Selector1 = "#someID";
#elif NEW
public static string Selector1 = "#someNewID";
#endif
public static string Selector2 = ".some.classes a";
// and so on...
}
Else you can use the approach from Ed Plunketts answer.
Okay, probably not what you're looking for, but... You might want to consider not doing it like this.
Put it this way - if you travel down the road, what will your code look like in 5 years? You'll have a base class that contains your original settings, a subclass for how they were modified the first time (when you asked this question), a subclass inheriting from that subclass on how they were modified the next time, and so on. I could easily imagine 10 subclasses in a giant chain - and if you wanted to trace the current value for any setting, you'd have to travel up that chain until you found where it was most recently set/overriden. It sounds like a maintenance nightmare, to be honest.
If I were in your shoes, this is what the new code would look like:
public static class Constants
{
public static string Selector1 { get { return ReadFromSettings("Selector1"); } }
public static string Selector2 { get { return ReadFromSettings("Selector2"); } }
//etc
// then, code for ReadFromSettings()
}
... and then migrate those settings into an actual settings file. Nobody needs to change any code on the calling end (they still reference Constants.Selector1) - except, instead of having this all hard-coded in a series of derived classes, you just have a file with your values.
Related
How do I declare a variable so that every class (*.cs) can access its content, without an instance reference?
In C# you cannot define true global variables (in the sense that they don't belong to any class).
This being said, the simplest approach that I know to mimic this feature consists in using a static class, as follows:
public static class Globals
{
public const Int32 BUFFER_SIZE = 512; // Unmodifiable
public static String FILE_NAME = "Output.txt"; // Modifiable
public static readonly String CODE_PREFIX = "US-"; // Unmodifiable
}
You can then retrieve the defined values anywhere in your code (provided it's part of the same namespace):
String code = Globals.CODE_PREFIX + value.ToString();
In order to deal with different namespaces, you can either:
declare the Globals class without including it into a specific namespace (so that it will be placed in the global application namespace);
insert the proper using directive for retrieving the variables from another namespace.
You can have static members if you want:
public static class MyStaticValues
{
public static bool MyStaticBool {get;set;}
}
First examine if you really need a global variable instead using it blatantly without consideration to your software architecture.
Let's assuming it passes the test. Depending on usage, Globals can be hard to debug with race conditions and many other "bad things", it's best to approach them from an angle where you're prepared to handle such bad things. So,
Wrap all such Global variables into a single static class (for manageability).
Have Properties instead of fields(='variables'). This way you have some mechanisms to address any issues with concurrent writes to Globals in the future.
The basic outline for such a class would be:
public class Globals
{
private static bool _expired;
public static bool Expired
{
get
{
// Reads are usually simple
return _expired;
}
set
{
// You can add logic here for race conditions,
// or other measurements
_expired = value;
}
}
// Perhaps extend this to have Read-Modify-Write static methods
// for data integrity during concurrency? Situational.
}
Usage from other classes (within same namespace)
// Read
bool areWeAlive = Globals.Expired;
// Write
// past deadline
Globals.Expired = true;
A useful feature for this is using static
As others have said, you have to create a class for your globals:
public static class Globals {
public const float PI = 3.14;
}
But you can import it like this in order to no longer write the class name in front of its static properties:
using static Globals;
[...]
Console.WriteLine("Pi is " + PI);
I'm writing a DLL that will expose a method like this:
public static void Convert(string inputFile, string outputFile, FileType fileType)
At the moment, FileType is an enum that is exposed like this:
public enum FileType
{
ConvertClassOne,
ConvertClassTwo,
ConvertClassThree
}
This will represent each class that can convert a given type of file. I'll have several different classes based on an interface, each of which can process a particular type of file.
Instead of having an enum like I have above, where I have to change it manually each time I add a class so that the calling program can tell me which file type they're giving me, I'd like to expose an enum that automatically changes itself based on the classes in my project that have a given attribute.
So if I add a class with a given attribute:
[SomeAttribute]
public class NewClassAdded()
{
}
the FileType enum will pick this up and the calling program will be able to see
FileType.NewClassAdded
without me having to change anything else by hand. I'm pretty sure that Reflection will allow me to write a method that returns the name of each class with the given attribute, but I'm not sure exactly how, nor do I know how I would then expose these names as an enum.
Thanks,
Andrew
This may not be the answer you are looking for, but have you considered using generics? It would solve the problem that you can add new functionality. You could use an interface that represents your enum. For each enum value, there would be a class that implements that interface. Whenever you want to add a new option, just add a new class implementing the interface. You can put additional functionality in these classes, or you could just use them as substitutes for enum values (variant 1 and 2 in the code below). Example:
class Program
{
static void Main(string[] args)
{
Converter.Convert("input", "output", new FormatA());
Converter.Convert("input", "output", new FormatB());
}
}
class Converter
{
public static void Convert<T>(string inputFile, string outputFile, T formatter) where T : IConvertFormat
{
// First variant: Keep the functionality in the formatter object
formatter.DoSomething(inputFile, outputFile);
// Second variant: check for the actual type
if (formatter is FormatA)
{
// ... do format A
}
else if (formatter is FormatB)
{
// ... do format B
}
}
}
interface IConvertFormat
{
// Method not required for variant 2
void DoSomething(string inputFile, string outputFile);
}
class FormatA : IConvertFormat
{
public void DoSomething(string inputFile, string outputFile)
{
// .. do it like Format A (not required for variant 2)
}
}
class FormatB : IConvertFormat
{
public void DoSomething(string inputFile, string outputFile)
{
// do it like Format B (not required for variant 2)
}
}
PS. I think that is basically what #Jauch is proposing.
Based on the discussions, I'll give you the following idea, #Starfleet.
First, create an interface with a "conversion" function and a "description" property.
interface IFileConversion
{
bool Convert (string inputFile, string outputFile);
string Description { get; }
}
Put this interfaces on a dll, and any class that wants to implement it can reference it.
Then, you can implement this interface on any "FileType" class you have.
In your library you can create a function to return all classes that implement IFileConversion (through reflection is pretty easy).
Something like:
static class Info
{
public static List<IFileConversion> AvailableConversions ()
{
//Code to retrieve the available classes that implement IFileConversion
}
}
This way, if you want to "enumerate" the available classes in your library (and show them to a user through some kind of visual interface), just call Info.AvailableConversions.
And them show to the user the available conversions using the "description" property.
But, if this is not the case and what you want is simply to other developers to know what are the available conversion classes, the better is through documentation. If you use the "///" you can give information and description that usually shows up on code completion in most UIDev. In this case, you can create a particular namespace, like:
namespace FileConversion
{
//Put all conversion classes under this namespace
}
And it's easy to see the available just typing "FileConversion." and iterating through the list that will appear (with the extra information you gave).
The advantage of using the IFileConversion interface is that your partners (other developers) do not have to worry about known anything about the class. They just chose the one they want (through the description or documentation) and call the Conversion routine.
In any case those two solutions are better and much more descriptive than just the enumeration descriptor.
I am pretty new to OOP and looking into things in a bit more depth, but I have a bit of confusion between these 3 methods in C# and which one is best and what the differences are between 2 of them.
Example 1
So lets start with this one, which (so I understand) is the wrong way to do it:
public class MyClass
{
public string myAttribute;
}
and in this way I can set the attribute directly using:
myObject.myAttribute = "something";
Example 2
The next way I have seen and that seems to be recomended is this:
public class MyClass
{
public string myAttribute { get; set;}
}
With getters and setters, this where I dont understand the difference between the first 2 as the variable can still be set directly on the object?
Example 3
The third way, and the way that I understand the theory behind, is creating a set function
public class MyClass
{
string myAttribute;
public void setAttribute(string newSetting)
{
myAttribute = newSetting;
//obviously you can apply some logic in here to remove unwanted characters or validate etc.
}
}
So, what are the differences between the three? I assume example 1 is a big no-no so which is best out of 2 and 3, and why use one over the other?
Thanks
The second
public class MyClass
{
public string MyAttribute { get; set;}
}
is basically shorthand for:
public class MyClass
{
private string myPrivateAttribute;
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
}
That is an auto-implemented property, which is exactly the same as any regular property, you just do not have to implement it, when the compiler can do that for you.
So, what is a property? It's nothing more than a couple of methods, coupled with a name. I could do:
public class MyClass
{
private string myPrivateAttribute;
public string GetMyAttribute()
{
return myPrivateAttribute;
}
public void SetMyAttribute(string value)
{
myPrivateAttribute = value;
}
}
but then instead of writing
myClass.MyAttribute = "something";
string variable = myClass.MyAttribute;
I would have to use the more verbose, but not necessarily clearer form:
myClass.SetMyAttribute("something");
string variable = myClass.GetMyAttribute();
Note that nothing constraints the contents of the get and set methods (accessors in C# terminology), they are methods, just like any other. You can add as much or as little logic as you need inside them. I.e. it is useful to make a prototype with auto-implemented properties, and later to add any necessary logic (e.g. log property access, or add lazy initalization) with an explicit implementation.
What your asking here has to do with encapsulation in OOP languages.
The difference between them is in the way you can access the propriety of an object after you created an object from your class.
In the fist example you can access it directly new MyClass().MyAttribute whether you get or set it's value.
In the second example you declare 2 basic functions for accessing it:
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
In the third example you declare your own method for setting the value. This is useful if you want to customize the setter. For example you don't want to set the value passed, but the value multiplied by 2 or something else...
I recommend some reading. You can find something here and here.
Property is a syntactic sugar over private attribute with get and set methods and it's realy helpful and fast to type;
You may treat automatic property with { get; set;} as a public attribute. It has no additional logic but you may add it later without uset ever notice it.
Just exchange
public string MyLine { get; set;}
to
string myLine;
public string MyLine
{
get { return myLine; }
set { myLine = value + Environment.NewLine; }
}
for example if you need so.
You can also easily create read only property as { get; private set }.
So use Properties instead of public attributes every time just because its easier and faster to write and it's provides better encapsulation because user should not be used get and set methods if you decide to use it in new version of yours programm.
One of the main principles of OOP is encapsulation, and this is essentially the difference between the first example and the other 2.
The first example you have a private field which is exposed directly from the object - this is bad because you are allowing mutation of internal data from outside the object and therefore have no control over it.
The other 2 examples are syntactically equivalent, the second being recommended simply because it's less code to write. However, more importantly they both restrict access & control mutation of the internal data so give you complete control over how the data should be managed - this is ecapsulation.
How do I declare a variable so that every class (*.cs) can access its content, without an instance reference?
In C# you cannot define true global variables (in the sense that they don't belong to any class).
This being said, the simplest approach that I know to mimic this feature consists in using a static class, as follows:
public static class Globals
{
public const Int32 BUFFER_SIZE = 512; // Unmodifiable
public static String FILE_NAME = "Output.txt"; // Modifiable
public static readonly String CODE_PREFIX = "US-"; // Unmodifiable
}
You can then retrieve the defined values anywhere in your code (provided it's part of the same namespace):
String code = Globals.CODE_PREFIX + value.ToString();
In order to deal with different namespaces, you can either:
declare the Globals class without including it into a specific namespace (so that it will be placed in the global application namespace);
insert the proper using directive for retrieving the variables from another namespace.
You can have static members if you want:
public static class MyStaticValues
{
public static bool MyStaticBool {get;set;}
}
First examine if you really need a global variable instead using it blatantly without consideration to your software architecture.
Let's assuming it passes the test. Depending on usage, Globals can be hard to debug with race conditions and many other "bad things", it's best to approach them from an angle where you're prepared to handle such bad things. So,
Wrap all such Global variables into a single static class (for manageability).
Have Properties instead of fields(='variables'). This way you have some mechanisms to address any issues with concurrent writes to Globals in the future.
The basic outline for such a class would be:
public class Globals
{
private static bool _expired;
public static bool Expired
{
get
{
// Reads are usually simple
return _expired;
}
set
{
// You can add logic here for race conditions,
// or other measurements
_expired = value;
}
}
// Perhaps extend this to have Read-Modify-Write static methods
// for data integrity during concurrency? Situational.
}
Usage from other classes (within same namespace)
// Read
bool areWeAlive = Globals.Expired;
// Write
// past deadline
Globals.Expired = true;
A useful feature for this is using static
As others have said, you have to create a class for your globals:
public static class Globals {
public const float PI = 3.14;
}
But you can import it like this in order to no longer write the class name in front of its static properties:
using static Globals;
[...]
Console.WriteLine("Pi is " + PI);
I'm working on this project and I have a large number of "services" to execute. I need to have this service codes so I can verifiy and make decisions according to selected services by it's code.
I'm tring to define this enum and get its values from the web.config so I can change them easily.
public enum ServiceCodes
{
Transfer= Convert.ToInt32(ConfigurationManager.AppSettings["servTransfer"]),
ChangePlate= Convert.ToInt32(ConfigurationManager.AppSettings["servChangePlate"])
}
But I get this error: The expression must be constant. (because of the Conversion)
What can I do? (Or you can suggest me totally different approaches.)
Just go ahead and define a static class like this:
public static class ServiceCodes
{
readonly static int Transfer = Convert.ToInt32(ConfigurationManager.AppSettings["servTransfer"])
//...
}
The documentation states that enum values are constant. An alternative approach is to declare a class with static readonly members.
If you still need the type safety provided by an enum, you could use a slightly complex approach:
public class ServiceCodes {
public static readonly ServiceCodes Transfer = new ServiceCodes(Convert.ToInt32(ConfigurationManager.AppSettings["servTransfer"]));
public static readonly ServiceCodes ChangePlate = new ServiceCodes(Convert.ToInt32(ConfigurationManager.AppSettings["servChangePlate"]));
internal int Code {get; private set;}
private ServiceCodes(int code) {
Code = code;
}
}
Then, a method like:
public void SomeAction(ServiceCodes serviceCode) {
//....
}
could be called like this:
SomeAction(ServiceCodes.Transfer);
But, given the complexity (compared with the gain), I would go with the first approach.