Character[] PlayerOne = new Character[5];
PlayerOne[1] = new BladeWarrior();
PlayerOne[2] = new FistWarrior();
PlayerOne[3] = new Archer();
PlayerOne[4] = new RedMage();
PlayerOne[5] = new BlueMage();
I know through polymorphism, a BladeWarrior can be a Character but it cant be the other way around. My problem is that when I try to access an element of an array. Player[1] for example, I cant access functions and variables from the BladeWarrior class. It's only letting me access variables and functions from the Character class which the BladeWarrior class inherits from.
I'm going to need to be able to access Bladewarrior functions/variables if Im going to want 2 characters to fight.
I was thinking I could use the "as" function to set PlayerOne[1] as the specific object . Not exactly like this:
string s = objArray[i] as string;
The line of code above is just to get an idea of which "as" Im talking about.
What is a solution to this problem?
I'm going to need to be able to access Bladewarrior functions/variables if Im going to want 2 characters to fight.
It looks like you are attempting to do a multiple dispatch: you want the call of
Fight(PlayerOne[i], PlayerOne[j]);
to call a function that knows the exact types of both characters. There are different tricks that you can use to achieve double dispatch in single dispatch languages, most notably, the visitor pattern. Starting with C#4, you could also use dynamic to implement double dispatch in a relatively clean and easy to read way:
static class FightArena {
public static void Fight(dynamic a, dynamic b) {
try {
DoFight(a, b);
} catch {
Console.Error.WriteLine("{0} and {1} cannot fight", a, b);
}
}
private static void DoFight(BladeWarrior a, Archer b) {
}
private static void DoFight(BladeWarrior a, FistWarrior b) {
}
private static void DoFight(BladeWarrior a, RedMage b) {
}
private static void DoFight(BladeWarrior a, BlueMage b) {
}
private static void DoFight(BladeWarrior a, BladeWarrior b) {
}
private static void DoFight(Archer a, Archer b) {
}
... // Enumerate all pairs that can fight
}
Now you can write something like this:
FightArena.Fight(PlayerOne[i], PlayerOne[j]);
and the call will reach the exact pair of types based on dynamic types of PlayerOne[i] and PlayerOne[j].
If you have to cast your Character's back to their concrete types for them to fight you are loosing any benefit you would get from polymorphism. If you need to cast to a Character to a Bladewarrior to fight that means you have to write different logic to each character to be able to fight each other. Then if you later add a new character type you'll have to update all of your fight code to support that type.
What you really want to be able to do is to write a generate fight algorithm that can be used to fight any two Character objects without casting them. You could add properties to the Character base class that would indicate the properties that the character has.
For example you could have add a Attacks property to the Character class which would be a list of the attacks the character has which would have a name of the attack and how much damage it does. Then each derived character class would populate its list of Attacks and your fight algorithm would process these attacks. In this way each character could have its own list of attacks, but would not have to be cast to a specific character type to access it.
The end goal here is for any external code to only know about the Character class and not any of its derived classes. That will make your external code cleaner and give you the ability to add or remove character classes in the future.
It is absolutely normal,if you want access BladeWarrior's properties you must convert your Character to BladeWarrior, and you'r right you can use as keyword for this:
BladeWarrior bw = PlayerOne[1] as BladeWarrior;
You are upcasting the instances thats why you are only able to use parent class behaviours and attributes.
I think you will have to do i individually for all instances.
BladeWarrior player1 = new BladeWarrior();
FistWarrior player2 = new FistWarrior();
Archer player3 = new Archer();
//and so on
As you said you can use "as" to cast. If the instance you are trying to cast cannot be casted to the target class you will get an null.
var currentCharacter = PlayerOne[1] as BladeWarrior;
if(currentCharacter != null)
{
....
}
The challenge here is to get a clean way to know what is the right casting.
May be you could use a structure in the array and use a flag to indicate the underliying class
switch(PlayerOne[1].Type)
{
case PlayerTypes.BladeWarrior:
currentCharacter = PlayerOne[1].Character as BladeWarrior;
}
But in general it seems you are not acomplishing the Liskov Subtitution Principle (The L in SOLID principles). You shouldnt need to access to the implementation details of the specific types of characters, Just override some methods or use a more modular(and complex) design based on the strategy pattern.
or you can use interface
public interface ICharacter {
int myValue { get; set;}
void myMethod();
}
public class BladeWarrior : ICharacter {
private int myPrivateValue;
public int myValue { get { return myPrivateValue; } set { myPrivateValue = value; } }
public void myMethod() {
//Do what you want
}
}
ICharacter[] PlayerOne = new ICharacter[5];
PlayerOne[0] = new BladeWarrior();
then you can access your interface methods
ICharacter[0].myMethod();
Related
I have a class that has a field that is being assigned a value from multiple methods.
public class Shape
{
private Point2D m_location;
public void Move()
{
m_location = ...
}
public void Rotate()
{
m_location = ...
}
public void Flip()
{
m_location = ...
}
}
I am getting a warning from NDepend that says:
Don't assign a field from many methods
https://www.ndepend.com/default-rules/Q_Don't_assign_a_field_from_many_methods.html
I am thinking of solving this problem by creating a separate method to assign the value of the field and calling this method from the other methods that currently assign a value to the field.
Here is an example of the code:
private void SetLocation(Point2D point)
{
m_location = location;
}
I want to know if this is a valid way to solve the problem and if it will just hide the code-smell that NDepend detected or actually fix the issue.
Is this a valid way to solve this problem?
No. As you suspect, this is a code smell. What NDepend is complaining about is mutable references; you have code where:
var s = new SomeObject(someInitialization);
var r = s.SomeResult();
// you now have no idea what s contains or if it is even usable any more.
The solution to this is to make SomeObject immutable and return new references instead of changing internals:
public SomeObject Something()
{
return new SomeObject(SomethingDifferentDependingOn(this.something));
}
Now instead of your first example you have:
var s = new SomeObject(someInitialization);
var r = s.Something().Result;
// s is guaranteed to be unchanged.
Yes some times you will need mutable references. In those cases; document them and explain why they have to be mutable. Then you can override NDepend rules on a case-by-case basis to prevent it showing a warning. If you have a code smell, warn people. Do not try to hide it.
The example after your edit is quite different, but the general principle still holds. If you have only a few internal fields that all change in method calls you can still return immutable references, e.g.:
public Shape Move()
{
return new Shape(m_location ...);
}
If you have many internal fields that don't all change, or you need to do something like share private fields you can't easily have immutable reference, but you can still avoid the warning by using accessors:
public Location
{
get { return m_location; }
private set { m_location = value; }
}
Then use Shape.Location exclusively in your internal methods.
I have a double problem here. I need to sort a List<> that I know contains objects of a derived class to the class that the list was declared to contain originally. AND, I need to sort by the return value from a method in that derived class, which takes a parameter. Keep in mind that I already know the List contains objects all of the derived class type.
I've created some sample code here to demonstrate the question since the real code cannot be shared publicly. Note, I have no control over the base conditions here (i.e. the fact that the List<> collection's declared contents are the parent class and that it contains objects of the derived class, which contains a method that takes an argument and returns the values that I need to sort the collection by). So, I doubt I'd be able to use any suggestion that requires changes there. What I think I need is a way to specify (cast?) what is really in the List so I can access the method defined there. But I'm open to other thoughts for sure. Otherwise I'm left with a traditional bubble sort. Thanks.
public class Component
{
public int X;
public int Y;
}
public class ComponentList : List<Component>
{
// Other members that deal with Components, generically
}
public class Fence : Component
{
public int Distance(int FromX, int FromY)
{
int returnValue = 0;
// Caluclate distance...
return returnValue;
}
}
public class Yard : Component
{
// Yada yada yada
}
public class MyCode
{
public List<Component> MyFences;
public MyCode(List<Component> Fences, int FromX, int FromY)
{
// Sort the fences by their distance from specified X,Y
Fences.Sort((A as Fence, B as Fence) => A.Distance(FromX, FromY).CompareTo(B.Distance(FromX, FromY)));
// Or
List<Fence> sortedFences = MyFences.OrderBy(A => A.Distance(FromX, FromY)).ToList();
// Or ???
}
}
Use the Enumerable.Cast<Fence> extension method to transform your IEnumerable<Component> to IEnumerable<Fence>. Then I'd use your second approach (the OrderBy approach) to sort it, but that's my preference.
List<Fence> sortedFences = MyFences.Cast<Fence>().OrderBy(A => A.Distance(FromX, FromY)).ToList();
This approach will throw if there is an object in MyFences that can't be cast to Fence. If you expect that the code should only be passed Fences, this might be what you want. If, instead, you want to skip over non-Fence members, you can use:
List<Fence> sortedFences = MyFences.OfType<Fence>().OrderBy(A => A.Distance(FromX, FromY)).ToList();
I am new to C# but seem to have noticed a limitation from what I am wanting to do with my code.
I have a class which i want to store a reference to other classes which i plan to store in a list. Something like this:
myList.Add(new Node(1,1,referenceToClassA));
myList.Add(new Node(1,2,referenceToClassB));
So my class would look like this:
public class Node : IHeapItem<Node> { //IHeapItem is for a heap i use for pathfinding
public int x;
public int y;
public ??? reference;
// constructor
public Node(int a, int b , ??? r){
x = a;
y = b;
reference = r;
}
// other unrelated stuff
}
So as you can probably guess, i have no idea what data type reference would be in my class given that it could be assigned to different classes.
I can't seem to find if there is a data type that is flexible for this in C# (i started in JavaScript so am not used to strict behavior on variable types).
What are my options here, what data type should I use, or will i have to implement this in a totally different way?
Hope you can help.
IF you only have one type of item in each list, then you could use this:
public class Node<T> : IHeapItem<Node> { //IHeapItem is for a heap i use for pathfinding
public int x;
public int y;
public T reference;
// constructor
public Node(int a, int b , T r){
x = a;
y = b;
reference = r;
}
// other unrelated stuff
}
If you don't know what you're going to get, and you will have more than one item in a list, then you're forced to use object. With a little reflection, that can work out pretty well.
It is also possible that you will have sets of different items, each set could implement the same interface, then that interface could be what you hold in the list.
If you're trying to create a generic, use T as the parameter type.
If you use T as the parameter type, you'll have to modify your class to be Node<T> as well.
Otherwise, you could use dynamic.
There is a class called Object that can reference any other class. If you want to make it just to a little group of classes, you may want to create an abstract class or an interface.
I'm trying to do something a certain way... but I'm certain there's a better way
public interface IMix
{
T Mix<T>(List<T> values) where T : IMix;
}
The problem with this is that if I want to "Mix" 5 values, then I need to do value1.Mix(others) but that is not clean. Plus, the type of T needs to be the same type as whatever class implements the interface. So, this doesn't really work.
I was thinking something like this:
public static class MixWrapper
{
public static T Mix<T>(List<T> values);
}
But that obviously won't work because I have to define the body in MixWrapper
EDIT: to clear up some misunderstanding, these are not real math averages, I could just as easily say "Fuse" or anything else. For example I could be trying to "average" a list some struct or other class.
EDIT 2:
One example could be a class like this
class Sequence : IMix
{
List<int> sequence;
double period;
double weight;
}
The "Mix" in this case would need to return a Sequence that was built this way: the resulting period is the weighted average of the periods based on the weight. The weight is the sum of the weights, and the sequence is the weighted average of the sequences after they have been timescaled down to the resulting period. Suffice to say, any complicated method that you could think of needs to be accounted for
If you want to calculate average of some list, then you can use LINQ:
var value = list.Average(x => x.SomeProperty);
Put the type T on your interface and just fill it with the same type as the class when you're implementing it:
public interface IMix<T>
{
T Mix(List<T> values);
}
public class ConcreteObjects : IMix<ConcreteObjects>
{
public ConcreteObjects Mix(List<ConcreteObjects> values)
{
// do mixing
}
}
This also leaves the door open for other classes to be able to mix ConcreteObjects if need be.
I think you're looking for an extension method.
You need to define a static method somewhere (some helper class, I suppose) like this:
public static T Average<T>(this List<T> list) where T : IAverage
{
return // average stuff
}
Now you just need to include your helper class with using and you can do something like this:
AverageClass implements IAverage
List<IAverage> list = new List<AverageClass>();
var average = list.Average();
I have a solution that works, but for educational purposes I want to understand if there is a better/cleaner/right way to do it.
Problem: In my "client" app I have a dictionary Dictionary<String, PremiseObject> where the key (String) is a immutable URL to a resource (it's actually a REST URL). PremiseObject is the base type of a whole set of derived classes; thus the Dictionary actually contains a family of classes all derived from PremiseObject.
A key requirement is I want to try to 'guarantee' that no PremiseObjects get created OUTSIDE of the dictionary.
Solution: I have the following function for getting a object out of the dictionary. It either accesses the existing instance, or if it does not exist creates it:
public PremiseObject GetOrCreateServerObject(string premiseObjectType, string location)
{
PremiseObject po = null;
if (!premiseObjects.TryGetValue(location, out po))
{
string classname;
// Create an instance of the right PremiseObject derived class:
po = // gobbly-gook that is not relevant to this question.
premiseObjects.Add(location, po);
}
else
{
Debug.WriteLine("Already exists: {0}", location);
}
return po;
}
Callers do this:
DoorSensor door =
(DoorSensor)server.GetOrCreateServerObject("DoorSensor",
"http://xyz/FrontDoor");
Works great. But I think there's a pattern or design that would elegantly allow me to encapsulate the "single-instance of each object contained in the dictionary" more.
For example, callers could do this:
DoorSensor door = null;
if (!server.ServerObjects.TryGetValue("DoorSensor",
"http://xyz/FrontDoor",
out door))
Debug.WriteLine("Something went very wrong");
I'm not really what to call this pattern. My ServerObjects are "single-instanced" by location. And my GetOrCreateServerObject is like a factory that lazy creates.
But it's possible for instances to be created that don't get put into the dictionary, which could lead to problems.
Like I said, what I have works... Cheers!
UPDATE 1/26/2011 10:13PM -
I just realized a potential problem: On the server side the object represented by a location/URL can actually be multi-inherited. It is THEORETICALLY possible for an object to be both a DoorSensor and an DigitalRelay.
I currently don't care about any of those cases (e.g. for garage doors I simplified my example above; there really is no DoorSensor I exposed, just a GarageDoorOpener which includes BOTH properties for sensing (e.g. Status) and actuation (e.g. Trigger). But this puts a wrinkle in my whole scheme if I were to care. Since this project is just for me :-) I am going to declare I don't care and document it.
I would propose the following simple idea:
PremiseObject's constructor is declared internal.
A special factory object is responsible for creating (or returning an already created) instances. The dictionary is a part of the factory.
Clients are located in another assembly.
This way PremiseObjects can be created by clients only through the factory. This way you can guarantee that only single instance of object exists for each location.
A variant of the idea would be to declare the PremiseObject's constructor private, and declare the factory a friend; but (unlike C++) C# doesn't have a friend notion.
Ok you can probably avoid a parameter and a cast (in the consumer code any way) with a generic method.
public abstract class PremiseObject
{
protected PremiseObject()
{
}
public string Location { get; set; }
public static void GetSensor<T>(string location, out T sensor)
where T : PremiseObject, new()
{
PremiseObject so;
if(_locationSingltons.TryGetValue(location, out so))
{
sensor = (T) so; // this will throw and exception if the
// wrong type has been created.
return;
}
sensor = new T();
sensor.Location = location;
_locationSingltons.Add(location, sensor);
}
private static Dictionary<string, PremiseObject> _locationSingltons
= new Dictionary<string, PremiseObject>();
}
Then the calling code looks a bit nicer:
DoorSensor frontDoor;
PremiseObject.GetSensor("http://FrontDoor/etc", out frontDoor);
So I like that calling convention - if you want to stay away from throwing an exception you can change the return type to bool and indicate failure that way. Personally I wouls say that an exception is what you want.
You may prefer the call without the out parameter - but if you do that then you have to supply the type to the method call - anyway defining the factory method would look like this:
public static T GetSensor<T>(string location) where T : PremiseObject, new()
{
PremiseObject so;
if (_locationSingltons.TryGetValue(location, out so))
{
return (T)so; // this will throw and exception if the
// wrong type has been created.
}
T result = new T();
result.Location = location;
_locationSingltons.Add(location, result);
return result;
}
Then the calling code looks like this:
var frontDoor2 = PremiseObject.GetSensor<DoorSensor>("http://FrontDoor/etc");
I like both these approaches because nothing has to be repeated. The type of the PremiseObject only gets stated once - there is no need for a string defining the type.
If you want to be really, really sure that no instances of PremiseObject get created that aren't placed in the dictionary, you could make the constructors all private, and create a static constructor (for each subclass) that took as a parameter the Dictionary object you're referring to. This static constructor would check the dictionary object to make sure that there wasn't an existing instance, and then return either the new or the existing instance as required. So something like this:
public class PremiseObject
{
public static Dictionary<string, PremiseObject> PremiseObjects { get; private set; }
static PremiseObject()
{
PremiseObjects = new Dictionary<string, PremiseObject>();
}
}
public class DerivedPremiseObject : PremiseObject
{
private DerivedPremiseObject()
{
}
public static DerivedPremiseObject GetDerivedPremiseObject(string location)
{
DerivedPremiseObject po = null;
if (!PremiseObject.PremiseObjects.TryGetValue(location, out po))
{
po = new DerivedPremiseObject();
PremiseObject.PremiseObjects.Add(location, po);
}
return po;
}
}
And there are a variety of similar strategies you could use. The key is to somehow make the constructor private and only allow access to the constructor through a static method that enforces the logic of the class construction.
Perhaps you could make PremiseObject a singleton, then you wouldn't have to worry about each object in the dictionary beign a single instance?
In the general case, setting access modifiers on your constructors should do the trick of not allowing anyone external to create the objects (barring reflection). However, these would need to be internal, so anything else in the assembly would be able to instantiate them.
I suspect many of your requirements may be met by using an off the shelf dependency injection container that supports singleton instances. It feels close, but maybe not quite the same. (possibly StrutureMap, Ninject, Castle Windsor, or Unity in no particular order)