More or less the same as this question but for DataContractSerializer rather than Serializable.
I explicitly do not want to be serializing parent references.
Also I would really rather the object's parent be bound before the children are constructed.
BTW: I'm using XML if that makes any difference
If you know the universe of child types, you can implement a surrogate to special-case the non-child types and essentially 'skip' the parent (i.e., non-child) types during serialization. As an example, see the http://msdn.microsoft.com/en-us/library/ms751540.aspx [Data Contract Surrogate] sample. Another option -- if you're using WCF 4 now -- is to use a DataContractResolver for type resolution and redirection. Again, see http://msdn.microsoft.com/en-us/library/dd807504.aspx [Data Contract Resolve Sample] for a reference!
Cheers.
Related
I have a class "Vertex" with 4 attributes and a class "Vertex_" with one attribute. The one attribute in Vertex_ is also in Vertex. Is it a good design to keep the two classes or is it better to program just the class Vertex, although there will be 3 variables, which are not used, when I instantiate an object which needs just the one attribute?
Class Vertex_ is actually somewhat a duplicate of Class Vertex.
I would suggest using inheritance and having Class Vertex inherit the attribute from the parent Class Vertex_ while having the 3 other attributes Class Vertex_ does not have.
TL;DR
This is a question that deserves a very long answer.There are two reasons for inheritance and the reason for doing it can depend on the language being used. One reason is for code reuse. Without knowing anything else about your situation, it would seem you are inheriting simply to reuse an attribute (but I suspect there could be more you will be reusing). But, there are other ways of getting code reuse without inheritance, for example containment, which is often a better way.
A powerful feature of object-oriented programming is the ability to substitute one type of object for another. When a message is sent to that object, the correct method implementation is invoked according the actual type of object receiving the message. This is one type of polymorphism. But in some languages the ability to substitute one object for another is constrained. In Java I can only substitute an instance of class B for an instance of class A if B is a descendant of A. So inheritance becomes important in Java to support polymorphism.
But what does it mean to be able to substitute a B instance for an A instance? Will it work? Class A has established a contract stating what each of its methods requires before you can successfully call it and at the same time states what each method promises to deliver. Will the methods of class B live up to that contract? If not, you really cannot substitute a B for an A and expect the program to run correctly. B may be a subclass of A but it is not a subtype of A (see Liskov substitution principle]).
In a language such as Python, inheritance is not required for polymorphism and coders are more apt to use it as code-reuse mechanism. Nevertheless, some people feel that subclassing should only be used to express subtyping. So, if Vertex_ is only using one of the four attributes it has inherited, I am doubtful that an instance of Vertex_ could be safely substituted for an instance of Vertex. I would not do the inheritance unless the language were C++ and then I would use private inheritance.
Is the following format wrong if I add a pointer to an object of a class, as data attribute of class in Class diagram in UML?
could not find anything about using objects in class diagram, is
underlining the object correct within the class attributes?
I think you may be mis-understanding classes, objects and attributes. Apologies if it's me doing the mis-understanding. So. Here's the short answer:
it's absolutely fine and normal for the type of an attribute to be a Class. In other words, you're not restricted to using primitive types like int, long, char etc.
The consequence is, as you say, that the values of those attributes at run time will themselves be objects. Specifically, instances of the classes Ability, Move and See.
More specifically, each instance of Agent (i.e. each Agent object) will hold references - or more precisely pointers - to 3 other objects: one instance each of Ability, Move and See.
So, assuming that's right, what you have is correct - except for the underlining.
Underlining an attribute or operation says it sits at the class level - not the instance level. It's the equivalent of static in java. Think of declaring constants in class scope, or constructors.
If I understand your model that's not what you want. You want each instance of Agent to hold (a pointer to) its own instances of Ability, Move and See. You don't want all the Agent objects to share the same 3 instances. Assuming so, you don't need the underline.
Hope I understood and that helps.
I have use the type dynamic, a new type in .NET 4.0.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
In my case, I am using self tracking entities in entity framework 4.0, and I know that all the entities has the methods markedXXX (to set the state of the entity).
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not definied the method.
I would like to know how to access to this methods. Is it possible?
Because I have a function that can access to the original values and set this values to the current one, but I need to set the entity as Unchenged.
Thanks.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
That suggests you should create an interface with those common methods, and make all the relevant types implement the interface.
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not defined the method.
It's possible that this is due to explicit interface implementation. If the types have those methods declared as public methods in the normal way, it should be fine.
If you really want to use dynamic typing with these types, is there some base interface which declares the MarkedAsXXX methods, which you could cast the objects to before calling those methods? (I'm not familiar with the entity framework, so I don't know the details of those methods.)
Basically, I would try to avoid dynamic typing unless you really need it, partly because of edge cases like this - but if explicit interface implementation is the cause, then casting to that interface should be fine.
If you define an interface to the dynamically generated classes you can call the methods without the hassle of reflection calling.
As we know, Scala generates getters and setters automatically for any public field and make the actual field variable private. Why is it better than just making the field public ?
For one this allows swapping a public var/val with a (couple of) def(s) and still maintain binary compatibility. Secondly it allows overriding a var/val in derived classes.
First, keeping the field public allows a client to read and write the field. Since it's beneficial to have immutable objects, I'd recommend to make the field read only (which you can achieve in Scala by declaring it as "val" rather than "var").
Now back to your actual question. Scala allows you to define your own setters and getters if you need more than the trivial versions. This is useful to maintain invariants. For setters you might want to check the value the field is set to. If you keep the field itself public, you have no chance to do so.
This is also useful for fields declared as "val". Assume you have a field of type Array[X] to represent the internal state of your class. A client could now get a reference to this array and modify it--again you have no chance to ensure the invariant is maintained. But since you can define your own getter you can return a copy of the actual array.
The same argument applies when you make a field of a reference type "final public" in Java--clients can't reset the reference but still modify the object the reference points to.
On a related note: accessing a field via getters in Scala looks like accessing the field directly. The nice thing about this is that it allows to make accessing a field and calling a method without parameters on the object look like the same thing. So if you decide you don't want to store a value in a field anymore but calculate it on the fly, the client does not have to care because it looks like the same thing to him--this is known as the Uniform Access Principle
In short: the Uniform Access Principle.
You can use a val to implement an abstract method from a superclass. Imagine the following definition from some imaginary graphics package:
abstract class circle {
def bounds: Rectangle
def centre: Point
def radius: Double
}
There are two possible subclasses, one where the circle is defined in terms of a bounding box, and one where it's defined in terms of the centre and radius. Thanks to the UAP, details of the implementation can be completely abstracted away, and easily changed.
There's also a third possibility: lazy vals. These would be very useful to avoid recalculating the bounds of our circle again and again, but it's hard to imagine how lazy vals could be implemented without the uniform access principle.
possible duplicate:
Cannot serialize parameter of type ‘System.Linq.Enumerable… ’ when using WCF, LINQ, JSON
Hi,
If my method signiature looks like this, it works fine.
[WebGet]
MyClass[] WebMethod()
If the signiature looks like this
[WebGet]
IEnumerable<T> WebMethod()
I get the following error:
Cannot serialize parameter of type 'X.Y.Z.T+<WebMethod>d__2c' (for operation 'WebMethod', contract 'IService') because it is not the exact type 'System.Collections.Generic.IEnumerable`1[X.Y.Z.T]' in the method signature and is not in the known types collection. In order to serialize the parameter, add the type to the known types collection for the operation using ServiceKnownTypeAttribute.
I have tried adding.
ServiceKnownType(typeof(IEnumerable))
Same error.
Is this a bug in 2010 beta 2, or is this likely to be correct going forward?
Thanks
The iterator types generated by the C# compiler are not serializable and never will be.
If you read this page, you'll see that it wouldn't make sense to serialize the iterator.
You need to return an array.
EDIT: The simplest way to do that is to move your iterator to a seperate method, and change WebMethod to
[WebGet]
MyClass[] WebMethod() { return OtherMethod().ToArray(); }
I've run into the same issue, and in my case it's simply not possible to change my entire object graph from iterator-based IEnumerable to concrete types. I simply cannot afford the memory to convert over to concrete types like List or Array. Additionally, what about the case where I return an IEnumerable of some object that has an IEnumerable property. It is unacceptable that I have to recurse my entire object graph converting all IEnumerables.
I don't see any good reason why the DataContractSerializer can't iterate any IEnumerable type and render its elements to XML in the same manner as any other collection type, even if the IEnumerable doesn't have a concrete backing type.
This is a bug which should be fixed.