Order of instantiation & Events
1 vue (au cours des 30 derniers jours)
Afficher commentaires plus anciens
Say I have a class A which has an Event "event1" which class B needs to listen for. I want class B to also be a property of class A, ie. I can instantiate obj = A(B). Ideally, in this process B would be set to listen for "event1" from A, but since Matlab builds B first, it does not know anything about A, and thus it has to be done effectively during the instantiation of A. The more complicated version is A(B(C)), where once again C needs to listen for "event1" in A, but is a property of B, which is a property of A.
In a nutshell I have an object A which is supplying the base data to a process which can involve anywhere from one to multiple filters, which is acted on and ultimately passed back to A... so the initial data needs to go to the bottom filter... the filters are defined by classes, in order to be portable and used in different situations..
The question, is there an efficient way to either define the classes or to instantiate the classes that would allow me to have the inner most nested class listen to the Event "event1" in the outer class without having to build a bunch of conditionals in the outer class instantiation function.
9 commentaires
Adam
le 6 Jan 2017
I'm not sure I get what is happening with the recursive children here. Each one has the same copy of updated data and each one will multiply it by 0.5.
But what is the expected result of all this if, for example, there are 3 nested children. As it stands you will just get the result of the top-most child, but the result of all child objects will be the same anyway as they are all acting on the same data.
I assumed the intention was for them to act upon each other's results back up the chain, but this doesn't seem to be the setup you have because the 'data' field is just the same data being passed to each child.
If the child objects are to act upon the result of the next one down the chain then the 'data' of children higher up the chain needs to be the result of obj.child.output, which will then get multiplied by 0.5.
If this is the case then the final result you want will be in the child immediately below the parent object and would be the result of effectively, e.g 0.5 * 0.5 * 0.5 * data rather than just 0.5 * data.
Réponse acceptée
Guillaume
le 6 Jan 2017
Modifié(e) : Guillaume
le 6 Jan 2017
I really don't understand the point of objects listening to their own events. Why not invoke the dataupdate method of the child directly in the feeddata method?
With the current design, the child class has two roles: - filter the data, - incomplete management of a singly linked list, with dispatch to elements. While this is a possible design, I can't help but feel that the two should be handled by separate classes. This is the design I would adopt:
classdef DataProvider < handle %your original outerclass.
properties
data;
filtermanager;
end
methods
function this = DataProvider(data, filtermanager)
this.data = data;
this.child = child;
end
function filtereddata = feedData(this)
filtereddata = this.filtermanager.filterdata(this.data);
end
end
end
classdef FilterManager < handle %container for filters. Can be implemented as singly-linked list, doubly-linked list, vector of matlab.mixin.heterogeneous, or a plain cell array
properties (SetAccess = private)
filters = {};
end
methods
function addfilter(this, filter)
assert(isa(filter, 'Filter'), 'Only object derived from Filter class can be added);
filters = [this.filters, filter];
end
%other methods to manage removals, ordering, etc. of filters
end
methods (Access = ?DataProvider)
function filtereddata = filterdata(this, data)
filtereddata = data;
for filter = this.filters
filtereddata = filter{1}.filterdata(filtereddata);
end
end
end
end
classdef Filter < abstract
methods (Abstract, Access = ?FilterManager)
function filtereddata = filterdata(data);
end
end
and an example filter:
classdef RatioFilter < Filter;
properties
ratio;
end
methods
function this = RatioFilter(ratio);
validateattributes(ratio, {'numeric'}, {'scalar'});
this.ratio = ratio;
end
end
methods (Access = ?FilterManager)
function filtereddata = filterdata(data)
filtereddata = data * this.ratio
end
end
end
2 commentaires
Guillaume
le 6 Jan 2017
I forgot to say, the advantage of decoupling the classes is that, with the above, you can at any time change which filter are applied to the data without having to tell neither the outerclass, nor the individual filters. This all handled by just one class, the FilterManager.
Plus de réponses (0)
Voir également
Catégories
En savoir plus sur Filter Analysis dans Help Center et File Exchange
Produits
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!