I need to make alternative to List<> class where I will have 4 methods... Two for adding int items, one from front, other from behind and two for deleting, one from front and other from behind as well. My class should not inherit anything.
Something like this...
public class MyList
{
public void AddItemsFront(int pItem)
{
}
public void AddItemsBehind(int pItem)
{
}
public void DeleteItemsFront(int pItem)
{
}
public void DeleteItemsBehind(int pItem)
{
}
}
You could hold an instance of a List<T> in a field, List<T> has already these methods:
public class MyList<T>
{
private List<T> _TheList;
public MyList()
{
_TheList = new List<T>();
}
public List<T> TheList { get { return _TheList; } set { _TheList = value; } }
public void AddItemFront(T pItem)
{
TheList.Insert(0, pItem);
}
public void AddItemBehind(T pItem)
{
TheList.Add(pItem);
}
public void DeleteItemFront()
{
TheList.RemoveAt(0);
}
public void DeleteItemBehind()
{
TheList.RemoveAt(TheList.Count - 1);
}
}
Since it's a generic class you could also use it for different types than int.
var myList = new MyList<int>();
myList.AddItemFront(1);
Create a class that's got a data member of the correct List<> type, and implement your methods by calling the appropriate methods on the List<> data member. You will want your delete operations to return the object they removed from the list.
This is often referred to as the Adapter pattern. Wikipedia has a page on it.
Related
The follow code does not compile:
public class Test
{
public void Run()
{
List<MyClass<dynamic>> listOfMyClasses = new List<MyClass<dynamic>>();
MyClass<dynamic> myClass = new MyClass<int>(); // Error here
listOfMyClasses.Add(myClass);
}
public class MyClass<T>
{
public void DoSomething() { }
public void DoSomethingSpecial<T>(T t) { }
}
}
However, I believe it makes sense logically (please let me know if I'm mistaken). Presumably it is useful, for I can call DoSomething without knowing the type parameter. How can I accomplish the addition of myClass to the list?
Instead of using a list of MyClass<dynamic> just use a List of dynamic:
public void Run()
{
List<dynamic> listOfMyClasses = new List<dynamic>();
dynamic myClass = new MyClass<int>();
listOfMyClasses.Add(myClass);
}
public class MyClass<T>
{
public void DoSomething() { }
}
I have an abstract class used for caching that implements as follows (simplified)
public abstract class DataCacheMember<T> : List<T>
{
private List<T> _data;
public List<T> Data
{
get
{
if (_data == null || _data.Count() < 1)
_data = GetData();
return _data;
}
}
private string ApiEndPoint {get; set;}
private Timer timer;
private List<T> GetData()
{
//call api and get data
}
private void RefreshData()
{
_data = GetData();
}
protected DataCacheMember(string apiEndPoint)
{
ApiEndPoint = apiEndPoint;
timer = new System.Threading.Timer(
e => RefreshData(),
null,
TimeSpan.Zero,
TimeSpan.FromMinutes(10));
}
}
It allows for rapid creation of cached objects with a simple string for the api endpoint:
public class StateMap<Properties> : DataCacheMember<Properties>
{
public StateMap(string apiEndPoint = "Property/GetProperties")
: base(apiEndPoint)
{}
}
The whole reason for inheriting from List<T> was to remove the need for the fields.
However, if I try to modify the constructor and refresh to:
private void RefreshData()
{
this = GetData() as DataCacheMember<T>;
}
protected DataCacheMember(string apiEndPoint)
{
this = GetData() as DataCacheMember<T>;
}
I get an error of Cannot assign to <this> because it is Read Only.
What's the proper way to resolve this? Do I just need to use Clear() and AddRange() to manage the object?
If I do that, I see that the first call to the object will return empty, because the object can return before the constructor finishes it's call.
To answer the question you cannot assign this in a constructor or any other method. You could add the items returned from GetData():
private void RefreshData()
{
this.Clear();
this.AddRange(GetData());
}
protected DataCacheMember(string apiEndPoint)
{
this.Clear();
this.AddRange(GetData());
}
But inheriting form List<T> probably isn't the right design here.
According to Using this() in C# Constructors
private void RefreshData()
{
this = GetData() as DataCacheMember<T>;
}
protected DataCacheMember(string apiEndPoint)
{
this = GetData() as DataCacheMember<T>;
}
These would only work in a struct and doesn't really do anything useful and is bad design.
I am working on some code whereby I have an abstract class that has a few core properties and a Run(int index) method. I then create new types that inherit this. These new types can have multiple methods that can be called according to the index passed in.
public abstract class BaseClass
{
public abstract void Run(int index);
}
public class Class1 : BaseClass
{
public override void Run(int index)
{
if (index == 0)
{
MethodA();
}
else if (index == 1)
{
MethodB();
}
}
private void MethodA()
{
//do stuff
}
private void MethodB()
{
//do stuff
}
}
I'm just wondering is there a better way to do this. These types and methods would be called from a UI, - a menu click for example. So I might have a class1 and a class2. Class1 might have 3 methods so I could call run(0) ... run(2) on it. Class2 might just have one internal method so I would just call run(0). Maybe I would need to keep a collection of ints with each class I guess as a map to methods. Might also have to add a string to this collection to hold a friendly name for menu items etc..
Can you think of a way to implement this type of mapping while maintaining as much abstraction as possible? Is there a better way to go about this that my current idea?
One way:
You could use an interface instead:
public interface IRunnableSomething {
void Run();
}
public class MyRunnableA :IRunnableSomething
{
public void Run() {
// do stuff
}
}
public class MyRunnableB :IRunnableSomething
{
public void Run() {
// do stuff
}
}
Then in your main class...
public override void Run(IRunnable runnable)
{
runnable.Run();
}
Example of calling it:
myInstanceOfMainClass.Run(new MyRunnableA());
This seems fitting, since you already know what index you were passing in with your original version. This just moves it from int based to interface based (less code too in the end).
Let me explain a bit further so. Here's a slightly more verbose version of what I am trying to do. You can see here that my abstract class has the list of indexes for pointing at the right method in derived classes, and you can see where I am loading types and creating menu items in a UI. I am using this ItemPointer list and passing around ItemPointers to tag properties etc. It all feels a bit wrong somehow.
I wish for the whole thing to be extensible. I might want to add a Class2, Class3 etc all inheriting BaseClass. I might also want to create plugins using BaseClass. Any derived class will have at least one but runable method but will likely have many. So Class1 here is just an example. Does this help explain myself? please go easy on me, I'm learning and that's why I am asking here.
Is what I'm doing here awful? or is it ok? or is there a better way? I guess that's my question. If there is a better way, I'd really appreciate an example. Many thanks to all for the help. It is much appreciated.
public abstract class BaseClass
{
public List<ItemPointer> ItemPointers = new List<ItemPointer>();
public abstract void Run(int index);
}
public class ItemPointer
{
public int Index { get; set; }
public string ClassType { get; set; }
public string UIDescription { get; set; }
}
public class Class1 : BaseClass
{
public Class1()
{
ItemPointers.Add(new ItemPointer { Index = 0, ClassType = this.GetType().Name, UIDescription = "MethodA Description" });
ItemPointers.Add(new ItemPointer { Index = 1, ClassType = this.GetType().Name, UIDescription = "MethodB Description" });
}
public override void Run(int index)
{
if (index == 0)
{
MethodA();
}
else if (index == 1)
{
MethodB();
}
}
private void MethodA()
{
//do stuff
}
private void MethodB()
{
//do stuff
}
}
public class UIForm
{
private List<BaseClass> _baseClasses;
//Formload events load all baseclass types (including plugins via reflection during form init etc. Then call loadUIitems
private void LoadUIItems()
{
foreach (BaseClass bc in _baseClasses)
{
foreach (var p in bc.ItemPointers)
{
ToolStripMenuItem t = new ToolStripMenuItem(p.UIDescription);
t.Click += new EventHandler(WorkerMenu_Click);
t.Tag = p;
actionsToolStripMenuItem.DropDownItems.Add(t);
}
}
}
void WorkerMenu_Click(object sender, EventArgs e)
{
ToolStripMenuItem t = (ToolStripMenuItem)sender;
ItemPointer p = (ItemPointer)t.Tag;
foreach (BaseClass bc in _baseClasses)
{
if (bc.GetType().Name == p.ClassType)
{
bc.Run(p.Index);
}
}
}
}
In your position I might be inclined to try do something like this:
void Main()
{
var a = new Class1();
var b = new Class2();
try
{
a.Run("Foo");
b.Run("Bar", "Yoda");
b.Run("Bat"); // throws exception
}
catch (Exception ex)
{
Console.WriteLine (ex.Message);
}
}
class Base
{
public void Run(string commandName, params object[] args)
{
var method = this.GetType().GetMethod(commandName);
if(method != null)
method.Invoke(this, args);
else
throw new Exception("the command " + commandName + " does not exist on " + this.GetType().Name);
}
}
class Class1 : Base
{
public void Foo()
{
Console.WriteLine ("I am foo");
}
}
class Class2 : Base
{
public void Bar(string str)
{
Console.WriteLine ("I am {0}", str);
}
}
Output:
I am foo
I am Yoda
the command Bat does not exist on Class2
I have a list of List<object>. How can I limit that only Class1 and Class2 should be used there is list?
Class1 and Class2 are basically different. I would guess what there is basic class for both this classes and restrict List to only work with it, but really don't know.
Make an interface that both classes implement
public interface MyInterface
{
}
public class Class1 : MyInterface
{
}
public class Class2 : MyInterface
{
}
List<MyInterface> myList = new List<MyInterface>();
The only instances of classes that can be referenced in the list are those that implement the MyInterface interface. In this case only Class1 and Class2.
I'm convinced that Bazz's answer is the correct way to handle such requirement.
There's however, another approach, that you can try :
public class MyCustomList : ArrayList
{
public override void Add(object item){
if(item is Class1 || item is Class2) {
base.Add(item);
}
else {
throw BadaboomException();
}
}
}
Or you can ensure signatures by wrapping the collection completely
public class MyCustomList : ICollection
{
private readonly ArrayList m_InnerList = new ArrayList();
public virtual void Add(Class1 item) {
this.m_InnerList.Add(item);
}
public virtual void Add(Class2 item) {
this.m_InnerList.Add(item);
}
public void CopyTo(Array array, int index) {
m_InnerList.CopyTo(array, index);
}
public int Count { get { return m_InnerList.Count; } }
public bool IsSynchronized { get{ return m_InnerList.IsSynchronized; } }
public object SyncRoot { get{ return m_InnerList.SyncRoot; } }
public IEnumerator GetEnumerator(){
return m_InnerList.GetEnumerator();
}
}
I'm trying to apply the Decorator Design Pattern to the following situation:
I've 3 different kind of forms: Green, Yellow, Red.
Now, each of those forms can have different set of attributes. They can have a minimize box disabled, a maximized box disabled and they can be always on top.
I tried to model this the following way:
Form <---------------------------------------FormDecorator
/\ /\
|---------|-----------| |----------------------|-----------------|
GreenForm YellowForm RedForm MinimizeButtonDisabled MaximizedButtonDisabled AlwaysOnTop
Here is my GreenForm code:
public class GreenForm : Form {
public GreenForm() {
this.BackColor = Color.GreenYellow;
}
public override sealed Color BackColor {
get { return base.BackColor; }
set { base.BackColor = value; }
}
}
FormDecorator:
public abstract class FormDecorator : Form {
private Form _decoratorForm;
protected FormDecorator(Form decoratorForm) {
this._decoratorForm = decoratorForm;
}
}
and finally NoMaximizeDecorator:
public class NoMaximizeDecorator : FormDecorator
{
public NoMaximizeDecorator(Form decoratorForm) : base(decoratorForm) {
this.MaximizeBox = false;
}
}
So here is the running code:
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateForm());
}
static Form CreateForm() {
Form form = new GreenForm();
form = new NoMaximizeDecorator(form);
form = new NoMinimizeDecorator(form);
return form;
}
The problem is that I get a form that isn't green and that still allows me to maximize it. It is only taking in consideration the NoMinimizeDecorator form. I do comprehend why this happens but I'm having trouble understanding how to make this work with this Pattern.
I know probably there are better ways of achieving what I want. I made this example as an attempt to apply the Decorator Pattern to something. Maybe this wasn't the best pattern I could have used(if one, at all) to this kind of scenario. Is there any other pattern more suitable than the Decorator to accomplish this? Am I doing something wrong when trying to implement the Decorator Pattern?
The problem here is that you're not actually implementing the decorator pattern. For a proper implementation of the pattern, you need to subclass Form to create your decorator, and then intercept all operations taken on your decorator and forward them to your private Form instance. You sort of do that, except that aside from assigning a reference in the FormDecorator constructor, you never again use that private Form instance. The net result is that you create a GreenForm, then wrap it in a NoMaximizeDecorator, and then you wrap that in a NoMinimizeDecorator. But because you never forward operations taken against the NoMinimizeDecorator to the wrapped Form instance, only the NoMinimizeDecorator instance actually applies any behavior to the instance that's used. This fits with what you observe when you run your code: a standard window with a disabled Minimize button.
Form is a really bad example for creating decorators in C#, because most of its properties and methods are non-virtual, meaning if you're accessing the decorated form via a Form reference, you have no way to intercept the base class's properties - you can't effectively "wrap" Form.
EDIT
It occurs to me that the statement "Form is a really bad example for creating decorators in C#" really begs the question of what is a good example. Typically, you'll use the decorator pattern to provide a custom interface implementation without implementing the entire implementation from scratch. A very common example is generic collections. Most everything that wants list functionality doesn't depend on, e.g., List<String>, but rather on IList<String>. So, if you for example want a custom collection that won't accept strings shorter than 5 characters, you would use something like the following:
public class MinLengthList : IList<String>
{
private IList<string> _list;
private int _minLength;
public MinLengthList(int min_length, IList<String> inner_list)
{
_list = inner_list;
_minLength = min_length;
}
protected virtual void ValidateLength(String item)
{
if (item.Length < _minLength)
throw new ArgumentException("Item is too short");
}
#region IList<string> Members
public int IndexOf(string item)
{
return _list.IndexOf(item);
}
public void Insert(int index, string item)
{
ValidateLength(item);
_list.Insert(index, item);
}
public void RemoveAt(int index)
{
_list.RemoveAt(index);
}
public string this[int index]
{
get
{
return _list[index];
}
set
{
ValidateLength(value);
_list[index] = value;
}
}
#endregion
#region ICollection<string> Members
public void Add(string item)
{
ValidateLength(item);
_list.Add(item);
}
public void Clear()
{
_list.Clear();
}
public bool Contains(string item)
{
return _list.Contains(item);
}
public void CopyTo(string[] array, int arrayIndex)
{
_list.CopyTo(array, arrayIndex);
}
public int Count
{
get { return _list.Count; }
}
public bool IsReadOnly
{
get { return _list.IsReadOnly; }
}
public bool Remove(string item)
{
return _list.Remove(item);
}
#endregion
#region IEnumerable<string> Members
public IEnumerator<string> GetEnumerator()
{
return _list.GetEnumerator();
}
#endregion
#region IEnumerable Members
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return ((IEnumerable)_list).GetEnumerator();
}
#endregion
}
public class Program
{
static void Main()
{
IList<String> custom_list = new MinLengthList(5, new List<String>());
custom_list.Add("hi");
}
}
This is a misapplication of the decorator pattern. The decorator pattern is concerned with the behavior of objects. You're constructing objects which falls under the creational umbrella. While you might be able to wrap your head around "not having a maximize button" being a behavior it sounds a little off kilter.
I don't think there's a real way to fix your design though. The decorator pattern just doesn't fit. Any attempt to fix this up is just going to be incredibly crufty when you could just use a Builder.
What I could see doing is decorating the Builder of a form to perform these actions while building. It would look something like this...
public interface IFormBuilder {
public Form BuildForm();
}
public class FormBuilder : IFormBuilder {
public Form BuildForm(){
return new Form();
}
}
public class NoMaximizeFormBuilder : IFormBuilder {
private IFormBuilder _builder;
public NoMaximizeFormBuilder (IFormBuilder builder){
_builder = builder;
}
public Form BuildForm(){
f = _builder.BuildForm();
f.MaximizeBox = false;
return f;
}
}
And you could use it like this...
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateForm());
}
static Form CreateForm() {
var b = new FormBuilder();
var b = new NoMaximizeFormBuilder(b);
return b.Build();
}
But even that is a little ugly. You might be able to transform this into a fluent interface for building forms.
try to make your pattern to apply the decorator properties to the same object, not creating new Forms:
public abstract class FormDecorator {
protected Form _decoratorForm;
protected FormDecorator(Form decoratorForm) {
this._decoratorForm = decoratorForm;
}
public abstract void Decorate();
}
public class NoMaximizeDecorator : FormDecorator
{
public NoMaximizeDecorator(Form decoratorForm) : base(decoratorForm) {
Decorate();
}
public override void Decorate() {
_decoratorForm.MaximizeBox = false;
}
}
And in your Main:
static Form CreateForm() {
Form form = new GreenForm();
new NoMaximizeDecorator(form);
new NoMinimizeDecorator(form);
return form;
}