waarbij ik dus indien het een interface is
een object van het gewenste type aanmaak (IBedrijf heeft altijd een Bedrijf als class).
Dream on. Dan zou de compiler voorspellende gaven hebben.. want een interface declaratie zegt niks over de objecten die aan de property gehangen worden.. dus als je ziet staan,
Code:
Interface IModelObject
{
public int PayAmount;
}
class Pipo: IModelObject { // ..
}
class Mameloe: IModelObject { // ..
}
class Klukkluk: IModelObject { // ..
}
public class PayRollDetail
{
public IModelObject Acteur { get; set; }
}
.. leuke getsetter, panklaar.. maar helaas, we weten niet WELK "Model" het is. Dus welke class zou je willen serialiseren ? Het is een public, dus in de code kan er een object van het type Pipo, Klukkluk en Mameloe ingeprikt zijn.. Reflection vereist runtime ook een instance (dacht ik), wat een I'tje wel is, maar niet alleen van de interface. Dus Reflection, zou die er zijn, levert te weinig informatie op.
Interfaces.. ingewikkeld gedoe, ik vind data in interfaces eigenlijk sowieso verkeerd.. interfaces alleen met methods zie je ook veel vaker. Soms MOET je er een implementeren, omdat de library het vereist (bijv voor een ISerializable).. voor mijn eigen spaghetti vind ik superclassen makkelijker
ik vind het alleen raar dat ik nergens invloed heb om een eigen serializer in dit proces te implementeren.
Ok is dit oplosbaar.. ja.. als je die velden die alleen als I'tje bestaan overslaat. Ik heb het niet getest, maar probeer deze modifier, om foutmeldingen te vermijden (dit is een zwaktebod)
Code:
public class Example
{
// etc
[NonSerialized]
public IModelObject Acteur { get; set; }
}
Bookmarks