This seems to be a problem that comes up a lot. I've been coming up with the same solution nearly every time but was curious if people have a better method of accomplishing this.
I have one class that is a list of instances of another class. The state of the parent class is dependent upon state of ALL the children
As an example. Say I have the following classes
class Box
{
int _objectId= <insert_unique_id>;
int _itemCount = 0;
public void AddItem()
{
_itemCount = Max(_itemCount + 1, 5);
}
public int GetId()
{
return _objectId;
}
public bool IsFull()
{
return _itemCount == 5
}
}
class BiggerBox
{
Map<int, Box> _boxes;
public void AddToBox(int id)
{
_boxes[id].AddItem();
}
public bool IsFull()
{
foreach(var box in _boxes.Values)
if(!box.IsFull())
return false;
return true;
}
}
All additions to a "Box" are done via the BiggerBox.AddToBox call. What I would like to do is be able to determine box.IsFull() without iterating over every single item every time we add an element.
Typically i accomplish this by keeping a SET or a separate collection of what items are full.
Curious, has anyone come up to an ingenious solution to this or is the simple answer that there is no other way?
There are two things you need to do in order to accomplish what you want:
Be able to control every entrypoint to your collection
React to changes to the objects in the collection
For instance, if the objects in the collection are mutable (meaning, they can change after being added to your collection) you need your main object to react to that change.
As you say, you could create a separate set of the objects that are full, but if the objects can change afterwards, when they change you either need to take them out of that set, or add them to it.
This means that in order for you to optimize this, you need some way to observe the changes to the underlying objects, for instance if they implement INotifyPropertyChanged or similar.
If the objects cannot change after being added to your main object, or you don't really care if they do, you just need to control every entrypoint, meaning that you basically need to add the necessary checks to your AddItem method.
For your particular types I would implement an event on the Box class so that when it is full, it fires the event. Your BiggerBox class would then hook into this event in order to observe when an underlying box becomes full.
You can upkeep the number of complete (or non-complete) boxes in BiggerBox class, and update it in all the functions.
E.g., in AddToBox it could be:
bool wasFull = _boxes[id].IsFull;
_boxes[id].AddItem();
if (!wasFull && _boxes[id].IsFull) // After this update box has become full.
completeBoxes += 1;
It is also possible to implement this upkeep procedure in other hypothetical functions (like RemoveFromBox, AddBox, RemoveBox, etc.)
Related
I've created a test plugin as a science project to try and determine if 2 of the same event are called at the same time, which will be executed first.
public class TestPlugin extends JavaPlugin implements Listener {
public void onEnable() {
Bukkit.getPluginManager().registerEvents(this, this);
}
#EventHandler(priority = EventPriority.HIGHEST)
public void event1(PlayerInteractEvent e) {
System.out.println("event 1");
}
#EventHandler(priority = EventPriority.HIGHEST)
public void event2(PlayerInteractEvent e) {
System.out.println("event 2");
}
}
the output that the plugin produced are
[17:01:51 INFO]: event 2
[17:01:51 INFO]: event 1
if event1 is listed first in the class file, why is it that event2 is fired first?
This is very hard to determine. Since registerEvents leads to the function createRegisteredListeners of https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/plugin/java/JavaPluginLoader.java
In there they use a HashSet to store the Methods of your Listener-class. So it is the pseudo random hash they give each method to store it that determines which event gets registered first.
I'm not sure but I guess that each and every time you register the events it's kind of random which gets registered first. This is why you should use different eventPriorities in order to determine which is called first.
If you really want to get deeper you have to tear apart the function createRegisteredListeners of the github-link I posted earlier in this reply. But I guess it woll never be totally certain because of the HashSet used in line 235 of the JavaPluginLoader.java:
methods = new HashSet<Method>(publicMethods.length, Float.MAX_VALUE);
As Methods are added to the set it never is certain in which position in the RAM they end up.
I hope I could help you with this post even though it doesn't really answer your original question.
I've read https://aspnetboilerplate.com/Pages/Documents/EventBus-Domain-Events and also ABP's implementation of Entity event handlers https://github.com/aspnetboilerplate/aspnetboilerplate/tree/f10fa5205c780bcc27adfe38aaae631f412eb7df/src/Abp/Events/Bus/Entities
I have spent 8 hours at work trying to find a solution to my issue, but I failed to succeed.
I have certain entities that point to a single entity called DatumStatus, which records certain actions that generate different states, such as: approved, modified, reviewed, archived, etc.
I am trying to generate a generic EventHandler capable of modifying its status based on these actions.
An example based on a algorithm:
EventBus.Trigger(new ApproveEventData{
Repository = _certainRepository,
Ids = [1, 4, 5]
});
The handler itself would, in turn, handle this state transition
public void HandleEvent(ApproveEventData eventData)
{
eventData.Repository.Where(p => p.Id.IsIn(eventData.Ids)).ForEach(p => {
p.Approved = true;
p.ApprovalDate = DateTime.Now()
});
}
The problem is, I need to write a generic ApproveEventData and handler capable of firing the same HandleEvent for every single entities.
The "closest" I got is:
EventBus.Trigger(typeof(ApproveEventData<int>), (IEventData) new ApproveEventData<int> {
Repository = (IRepository<EntityWithStatus<int>, int>) _entityRepository,
Ids = selectedIds
});
[Serializable]
public class ApproveEventData<TPrimaryKey> : EventData
{
public IRepository<EntityWithStatus<TPrimaryKey>, TPrimaryKey> Repository;
public TPrimaryKey[] Ids;
}
The implementation above failes when casting the repository.
Could someone shed some light? Thanks!
I see two possible approaches.
Rely on covariance and contravariance. You can make the cast succeed by making an interface for EntityWithStatus an interface and making both IEntityWithStatus and IRepository covariant (add out to the generic type definition).
Rely on dynamic and leverage generic type inference. Basically have the Repository be dynamic.
I'd recommend number 1.
I am trying to analyze what problem i might be having with unsafe threading in my code.
In my mvc3 webapplication i try to the following:
// Caching code
public static class CacheExtensions
{
public static T GetOrStore<T>(this Cache cache, string key, Func<T> generator)
{
var result = cache[key];
if(result == null)
{
result = generator();
lock(sync) {
cache[key] = result;
}
}
return (T)result;
}
}
Using the caching like this:
// Using the cached stuff
public class SectionViewData
{
public IEnumerable<Product> Products {get;set;}
public IEnumerable<SomethingElse> SomethingElse {get;set;}
}
private void Testing()
{
var cachedSection = HttpContext.Current.Cache.GetOrStore("Some Key", 0 => GetSectionViewData());
// Threading problem?
foreach(var product in cachedSection.Products)
{
DosomestuffwithProduct...
}
}
private SectionViewData GetSectionViewData()
{
SectionViewData viewData = new SectionViewData();
viewData.Products = CreateProductList();
viewData.SomethingElse = CreateSomethingElse();
return viewData;
}
Could i run inte problem with the IEnumerable? I dont have much experience with threading problems. The cachedSection would not get touched if some other thread adds a new value to cache right? To me this would work!
Should i cache Products and SomethingElse indivually? Would that be better than caching the whole SectionViewData??
Threading is hard;
In your GetOrStore method, the get/generator sequence is entirely unsynchronized, so any nymber of threads can get null from the cache and run the generator function at the same time. This may - or may not - be a problem.
Your lock statement only locks the setter of cache[string], which is already thread safe and doesn't need to be "extra locked".
The variation of double-checked locking in the cache is suspect, I'd try to get rid of it. Since the thread that never enters the lock() section can get result without a memory barrier, result may not be entirely constructed by the time the thread gets it.
Enumerating the cached IEnumrators is safe as long as nothing modifies them at the same time. If GetSectionViewData() returns an object with immutable (as in non changing) collections, you're safe.
Your code is missing parts like how would Products be populated? Only in GetSectionViewData?
If so, then I don't see a major problem with your code.
There is however a chance that two threads generate the same data(CachedSection) for the same key, it shouldn't create a threading problem except that you are doing the work twice, so if this was an expensive operation I would change the code so it only generates it once per key. If it is not expensive, it works fine as is.
IEnumerable for Products is not touched (assuming you create it separately per thread, but the enumerator on the cache is modified for each insert operation, hence it is not thread safe. So if you are using this I would be careful about that.
I'm using Linq and having trouble doing something that I believe should be trivial. I want to return data from one layer so it can be used independently of linq in another layer.
Suppose I have a Data Access Layer. It knows about the entity framework and how to interact with it. But, it doesn't care who accesses it. The one interesting requirement I have is that the queries in the entity framework return projected data that is not part of the Entity Model itself. Please don't ask me to change this part of the requirement and make POCOs for each return type, as it is not the best design given the problem I am trying to solve. Below is an example.
public class ChartData
{
public function <<returnType??>> GetData()
{
MyEntities context = new MyEntities();
var results = from context.vManyColumnsOfData as v
where v.CompanyName = "acme"
select new {Year = v.SalesYear, Income = v.Income};
return ??;
}
}
Then, I would like to have an ASP.Net UI layer be able to call into the Data Access Layer to get the data in order to bind it to a control. The UI layer should have no notion of where the data came from. It should only know that it has the data it needs to bind. Below is an example.
protected void chart_Load(object sender, EventArgs e)
{
// set some chart properties
chart.Skin = "Default";
...
// Set the data source
ChartData dataMgr = new ChartData();
<<returnType?>> data = dataMgr.GetData();
chart.DataSource = data;
chart.DataBind();
}
What is the best way to send linq projected data back to another layer?
If you don't need to use the projected type statically, just return IEnumerable<object>.
Please don't ask me to change this part of the requirement and make
POCOs for each return type, as it is not the best design given the
problem I am trying to solve.
I feel like I should rightly ignore this, as the best thing to do is to return a defined type. Anonymous types are useful when they are wholly contained within the method that creates them. Once you start passing them around, it is time to go ahead and give them the proper class treatment.
However, to live within your imposed limitations, you can return IEnumerable<object> from the method and use that or var at the callsite and rely upon the dynamic binding of the control to get at the data. It's not going to help you if you need to deal with the object programmatically, but it will serve fine for databinding.
You can not return an anonymous type, so basically for this you will need POCO's even though you don't want them.
"not the best design given the problem I am trying to solve"
Could you explain what you are trying to achieve a little more? It might be possible to return some type of list containing a dictionary of items (ie rows and columns). Think something like an untyped dataset (yuck)
Your GetData method can use IEnumerable (the "old" non-generic interface) as its return type.
Any dynamic resolution (e.g. ASP.NET or XAML bindings) should work as expected, which seems to be what you want to do.
However, if you want to use the results in your code, you will probably have to resort to .NET 4's dynamic keyword.
The following example can be run in LINQPad (in "C# Program" mode) and illustrates this:
void Main()
{
var v = GetData();
foreach (dynamic element in v)
{
((string)element.Name).Dump();
}
}
public IEnumerable GetData()
{
return from i in Enumerable.Range(1, 10)
select new
{
Name = "Item " + i,
Value = i
};
}
Keep in mind that, design-wise, coding like this will make most people frown and can affect performance.
OK so my question is self explanatory, here is some code so you can understand a little more.
public Dictionary<string,VcardWindow> VcardWindowManager
= new Dictionary<string,VcardWindow>();'
And access like so:
public void ShowVcardWindow(string VcardOwner)
{
VcardWindow Window;
if(VcardWindowManager.ContainsKey(VcardOwner))
{
Window = VcardWindowManager[VcardOwner];
}
else
{
Window = new VcardWindow(VcardOwner);
//Startup Code
VcardWindowManager.Add(VcardOwner,Window);
}
//Invoker here
}
Is by storing windows in a dictionary OK? Are there other means that are faster and safer?
An instance of a Form is an object like any other, and so you can store its reference in a Dictionary. Using a Dictionary in this case is the correct way to store a collection of objects that need to be accessed according to a key, in a single-threaded scenario.