In my example to illustrate my use case I have a parent class that is purposely database agnostic (let's say I can't change the code of it for some reasons, because the class come from a commercial assembly or the .net framework or are auto generated by entity framework):
public class Father
{
public string Field1;
public string Field2;
}
Now I'd like to store an object derived from it into MongoDB (again, it's only for the example, there a lot of other use cases and my question has nothing to do with MongoDB):
public class Child:Father
{
public ObjectId Id;
public DateTime DateCreation;
}
But I'd like to add attributes to some elements of the father, like [BsonIgnoreIfNull], without overriding (they are not marked as virtual) or having to fully reimplement the Father in my Child class.
What would be the cleanest way to do this?
Thanks!
Related
I process messages from a queue. I use data from the incoming message to determine which class to use to process the message; for example origin and type. I would use the combination of origin and type to look up a FQCN and use reflection to instantiate an object to process the message. At the moment these processing objects are all simple POJOs that implement a common interface. Hence I am using a strategy pattern.
The problem I am having is that all my external resources (mostly databases accessed via JPA) are injected (#Inject) and when I create the processing object as described above all these injected objects are null. The only way I know to populate these injected resources is to make each implementation of the interface a managed bean by adding #stateless. This alone does not solve the problem because the injected members are only populated if the class implementing the interface is itself injected (i.e. container managed) as opposed to being created by me.
Here is a made up example (sensitive details changed)
public interface MessageProcessor
{
public void processMessage(String xml);
}
#Stateless
public VisaCreateClient implements MessageProcessor
{
#Inject private DAL db;
…
}
public MasterCardCreateClient implements MessageProcessor…
In the database there is an entry "visa.createclient" = "fqcn.VisaCreateClient", so if the message origin is "Visa" and the type is "Create Client" I can look up the appropriate processing class. If I use reflection to create VisaCreateClient the db variable is always null. Even if I add the #Stateless and use reflection the db variable remains null. It's only when I inject VisaCreateClient will the db variable get populated. Like so:
#Stateless
public QueueReader
{
#Inject VisaCreateClient visaCreateClient;
#Inject MasterCardCreateClient masterCardCreateClient;
#Inject … many more times
private Map<String, MessageProcessor> processors...
private void init()
{
processors.put("visa.createclient", visaCreateClient);
processors.put("mastercard.createclient", masterCardCreateClient);
… many more times
}
}
Now I have dozens of message processors and if I have to inject each implementation then register it in the map I'll end up with dozens of injections. Also, should I add more processors I have to modify the QueueReader class to add the new injections and restart the server; with my old code I merely had to add an entry into the database and deploy the new processor on the class path - didn't even have to restart the server!
I have thought of two ways to resolve this:
Add an init(DAL db, OtherResource or, ...) method to the interface that gets called right after the message processor is created with reflection and pass the required resource. The resource itself was injected into the QueueReader.
Add an argument to the processMessage(String xml, Context context) where Context is just a map of resources that were injected into the QueueReader.
But does this approach mean that I will be using the same instance of the DAL object for every message processor? I believe it would and as long as there is no state involved I believe it is OK - any and all transactions will be started outside of the DAL class.
So my question is will my approach work? What are the risks of doing it that way? Is there a better way to use a strategy pattern to dynamically select an implementation where the implementation needs access to container managed resources?
Thanks for your time.
In a similar problem statement I used an extension to the processor interface to decide which type of data object it can handle. Then you can inject all variants of the handler via instance and simply use a loop:
public interface MessageProcessor
{
public boolean canHandle(String xml);
public void processMessage(String xml);
}
And in your queueReader:
#Inject
private Instance<MessageProcessor> allProcessors;
public void handleMessage(String xml) {
MessageProcessor processor = StreamSupport.stream(allProcessors.spliterator(), false)
.filter(proc -> proc.canHandle(xml))
.findFirst()
.orElseThrow(...);
processor.processMessage(xml);
}
This does not work on a running server, but to add a new processor simply implement and deploy.
I wanted to create an abstract base class for all of my view models, but I'm running into accessibility issues and can't seem to navigate through the errors. Here's an example of my code:
public ref class ViewModelBase {
...
}
public ref class OtherViewModel : ViewModelBase {
...
}
When I define my code as state above, I get the following error:
error C4585: 'MyNamespace::ViewModelBase' : A WinRT 'public ref class' must either be sealed or derive from an existing unsealed class
If, instead, I make ViewModelBase private, I get this error:
error C3213: base class 'MyNamespace::ViewModelBase' is less accessible than 'OtherViewModel'
This seems like it should be incredibly simple. What am I doing wrong?
What you are attempting is not strictly possible in C++/CX, as in VS 2012 C++/CX does not support public class inheritance for general-purpose scenarios. It is only supported enough to have the XAML scenarios work; the only possible public unsealed types are those found under the Windows::UI::Xaml namespace, and users are not able to author their own public unsealed types.
If you want to have a base class for all your view models, your only options to make all your classes private or to inherit from a base class from Windows::UI::Xaml (such as DependencyObject).
Each of these approaches has drawbacks:
using DependencyObject as your base makes all your viewmodels STA objects (so they can only be manipulated from the UI thread) in addition to having a lot of overhead that isn't really necessary.
Making your classes private means you cannot use the [Bindable] attribute to do databinding, so you would need to have a private databinding implementation. (Your private class would need to implement ICustomPropertyProvider and related interfaces.)
The "sealed" keyword means that the class cannot be inherited from. Your implementation should look something like this:
ref class ViewModelBase sealed
If you want to inherit from ViewModelBase then you need to have only the subclasses be ref classes like this:
class ViewModelBase
...
public ref class OtherViewModel sealed : ViewModelBase
I'm studying how Rhino.Mocks works and trying to understand how can I set manually a value in a class Property.
I have seen a sample in internet where you have only desired Property as argument of Expect.Call(), instead of using a method.
MockRepository mocks = new MockRepository();
Person p = mocks.StrictMock<Person>();
Expect.Call(p.FirstName).Return("John");
Person is a class such as:
public class Person
{
public string FirstName {get;set;}
}
I always receive the error:
Invalid call, the last call has been
used or no call has been made (make
sure that you are calling a virtual
(C#) / Overridable (VB) method).
Am I missing something? Is it possible to set manually class Properties and evaluate them to see if getters and setters are working fine?
As with any mocking framework, Rhino Mocks can only mock interfaces or classes that defines virtual methods and properties.
That's because when implementing a class, Rhino creates a derived class from the one you specify, replacing every virtual (or Overridable in VB) method with a stub implementation that uses an interceptor to handle the call.
When you specify a non virtual method, Rhino can't create a wrapper.
That is also true tor sealed (NonInheritable in VB) classes.
So for your class to work, you should implement the property as such:
public class Person
{
public virtual string FirstName { get; set; }
}
This way Rhino can override the poperty accordingly.
I'm using JAXB in a web service with some slightly complex objects. One of the objects, Sensor, has a list of other objects it can communicate with, which necessarily can include itself (behavior that cannot be changed), leading to a cyclic reference during marshalling to XML.
#XmlAccessorType(XmlAccessType.FIELD)
public class Sensor extends BaseObject {
private ArrayList<SensorCommLink> sensorCommLinks;
}
#XmlAccessorType(XmlAccessType.FIELD)
public class SensorCommLink {
#XmlIDREF
private BaseObject receiver;
#XmlIDREF
private Sensor cueingSensor;
}
#XmlAccessorType(XmlAccessType.FIELD)
public abstract class BaseObject {
#XmlElement
#XmlID
private String id;
}
As shown above I solved this using #XmlIDREF and #XmlID and it works very nicely.
The client-side code generated via wsimport marshals the objects to XML and the server is able to unmarshal them perfectly.
The problem I'm experiencing is that for some reason on the server side I am getting a cyclic reference exception when I try to marshal a Sensor object. The maddening part is that the server-side code contains the JAXB annotations that are used by wsimport to create the client-side code, which works great, yet I can't marshal server-side Sensors due to the cycle.
I tried copying all of the extra annotations JAXB adds to the client-side code onto the server-side classes thinking perhaps there was a runtime bug in JAXB that was preventing it from properly applying the #XmlIDREF annotation. No luck there.
Perhaps there's something very basic I'm missing here but this issue is driving me a little batty and I'm at a dead stop while I try to figure it out.
One thing I did notice that I'm investigating is that some of the namespaces on the generated client-side objects aren't what I expected, though the code works. I'm curious to see if somehow a namespace issue on the server is causing the IDREF marshalling to bomb.
Any chance on the server side it is processing properties (get/set) instead of fields (instance variables). You can enforce field access in the following way:
#XmlAccessorType(XmlAccessType.FIELD)
public class SensorCommLink {
#XmlIDREF
private BaseObject receiver;
#XmlIDREF
private Sensor cueingSensor;
}
Or you could annotate the get methods.
After the previous question "What are the important rules in Object Model Design", now I want to ask this:
Is there any way to have dynamic properties for class instances?
Suppose that we have this schematic object model:
So, each object could have lots of properties due to the set of implemented Interfaces, and then become relatively heavy object. Creating all the possible -and of course reasonable- object can be a way for solving this problem (i.e. Pipe_Designed v.s. Pipe_Designed_NeedInspection), but I have a large number of interfaces by now, that make it difficult.
I wonder if there is a way to have dynamic properties, something like the following dialog to allow the end user to select available functionalities for his/hers new object.
What you want is Properties pattern. Check out long and boring but clever article from Steve Yegge on this
I think maybe you're putting too many roles into the "Road" and "Pipe" classes, because your need for dynamic properties seems to derive from various states/phases of the artifacts in your model. I would consider making an explicit model using associations to different classes instead of putting everything in the "Road" or "Pipe" class using interfaces.
If you mean the number of public properties, use explicit interface implementation.
If you mean fields (and object space for sparse objects): you can always use a property bag for the property implementation.
For a C# example:
string IDesigned.ApprovedBy {
get {return GetValue<string>("ApprovedBy");}
set {SetValue("ApprovedBy", value);}
}
with a dictionary for the values:
readonly Dictionary<string, object> propValues =
new Dictionary<string, object>();
protected T GetValue<T>(string name)
{
object val;
if(!propValues.TryGetValue(name, out val)) return default(T);
return (T)val;
}
protected void SetValue<T>(string name, T value)
{
propValues[name] = value;
}
Note that SetValue would also be a good place for any notifications - for example, INotifyPropertyChanged in .NET to implement the observer pattern. Many other architectures have something similar. You can do the same with object keys (like how EventHandlerList works), but string keys are simpler to understand ;-p
This only then takes as much space as the properties that are actively being used.
A final option is to encapsulate the various facets;
class Foo {
public bool IsDesigned {get {return Design != null;}}
public IDesigned Design {get;set;}
// etc
}
Here Foo doesn't implement any of the interfaces, but provides access to them as properties.