Serializable - waarom niet alles?

[PdeBie]

Gewoon even een vraag puur uit interesse.

Waarom zou je al je klassen die je maakt niet serializable maken? Het komt altijd van pas en vaak komt het voor dat je er later pas achter komt dat de klasse serializable had moeten zijn.

Dus waarom zou je dit niet altijd doen?

Is het uberhaupt mogelijk? En wat zijn de voors- en tegens?

[Standeman]

Omdat het vaak nergens op zal slaan om ze serializable te maken. Waarom zouden bijv. DAO's of services serializable moeten zijn? Veel classes hebben geen state en is het dus ook onzinnig om ze te serializen. Verder kan het ook tot problemen leiden wanneer info realtime berekend worden. Als je dat serialiseerd heb je er niets aan, maar erger, als je deserialiseerd zit je met oude data (Daarom hebben ze ook de transient modifier uitgevonden).

[.oisyn]

Veel classes hebben geen state en is het dus ook onzinnig om ze te serializen

Sowieso classes die resources managen, of ze dat nou stateful doen of niet. Je hebt er natuurlijk niets aan om een filestream of een socket oid te serializen.

[RobIII]

if all you have is a hammer, everything looks like a nail

[MSalters]

Een top-level app object serializable maken lijkt me ook wat overkill.

En ik kan me voorstellen dat een drag-&-drop class ook niet zinnig te serializen is; die drag&drop operatie is al lang afgelopen als je het object weer deserialized.

[Xiphalon]

MSalters schreef op donderdag 04 augustus 2011 @ 16:16:
Een top-level object serializable maken lijkt me ook wat overkill.

que?:

C#:

[SerializableAttribute]
[ClassInterfaceAttribute(ClassInterfaceType.AutoDual)]
[ComVisibleAttribute(true)]
public class Object

Edit: En ja, je kan practisch alles casten naar object, serializen, deserializen en het originele type is er dan nog

[ Voor 15% gewijzigd door Xiphalon op 04-08-2011 16:38 ]

[RedRose]

darkmage schreef op donderdag 04 augustus 2011 @ 16:37:
[...]

que?:

C#:

[SerializableAttribute]
[ClassInterfaceAttribute(ClassInterfaceType.AutoDual)]
[ComVisibleAttribute(true)]
public class Object

Edit: En ja, je kan practisch alles casten naar object, serializen, deserializen en het originele type is er dan nog

Ja, maar waarom zou je het doen? Een object ComVisible maken is toch niet het zelfde als het serializable maken? Of bedoelde je dat niet?

[chime]

Ik zie het nut er niet direct van in. Je steekt namenlijk tijd in iets dat niet direct nodig is.

Komt erbij dat het vaak niet wordt afgetest.
Want ik zie wel eens klassen die de Serializable interface implementeren maar die toch niet serializeerbaar zijn.
(Klassen die een inputstream/outputstream bevatten bijvoorbeeld)

Ook moet je je communicatie kanaliseren: je moet nadenken en weten wat naar buiten mag en wat niet.
Zomaar alles serializeerbaar maken is op dat vlak ook al een risico. Zeker als iemand later even snel, snel iets nodig heeft en ziet ... wauw ik kan deze top klasse doorsturen en daar staat hetgeen in wat ik wil.

Kom je er op een bepaald moment achter dat een klasse serializeerbaar moet zijn: geen probleem.
Dan pas je de klasse gewoon aan (je ontwikkelt dus alleen wat op dat moment echt nodig is), natuurlijk sta je er wel even bij stil of het wel goed is om deze klasse serializeerbaar te maken.

[YopY]

Kort antwoord: YAGNI (Ya Ain't Gonna Need It)

Iets langer: Dingen die je niet direct nodig hebt kun je beter niet doen. Een serialize() maken voor elke class die je bouwt kost gewoon tijd, en als je het niet direct nodig hebt (bijvoorbeeld als je het opslaan van een objectstructuur aan het implementeren bent), moet je het ook niet maken 'om het maar te hebben'.

Het komt altijd van pas

Altijd?

[...]en vaak komt het voor dat je er later pas achter komt dat de klasse serializable had moeten zijn.

Future proofing heet dat, met een gedachte van 'Ja maar, misschien hebben we het ooit nog eens nodig' of 'Ja maar over drie weken ga ik mijn objecten op schijf opslaan en dan heb ik het nodig'. Als je het niet gelijk nodig hebt, niet doen.

(het future proofing kan ook subtieler zijn overigens. Wie heeft bijvoorbeeld niet eens een (tweede / derde) constructor geschreven omdat het wel handig zou kunnen zijn?)

[MSalters]

darkmage schreef op donderdag 04 augustus 2011 @ 16:37:
[...]

que?:

Slechte quote. Een top level app object is een object wat je applicatie als geheel representeert. Het "document" deel ervan is waarschijnlijk wel serializeerbaar, maar je input state is dat typisch niet.

[Verwijderd]

SerializableAttribute is gewoon syntactische sugar, je kunt alles ook serializen (kijk naar db4o / eloquera). Het geeft aan dat je de intentie hebt om een bepaald type te serializen.

[RobIII]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 01:41:
je kunt alles ook serializen

Onzin, hoe serialize jij een DB connectie of socket dan bijvoorbeeld? (Zie de andere voorbeelden in dit topic)

[ Voor 11% gewijzigd door RobIII op 26-08-2011 08:15 ]

[Verwijderd]

RobIII schreef op vrijdag 26 augustus 2011 @ 08:14:
[...]

Onzin, hoe serialize jij een DB connectie of socket dan bijvoorbeeld? (Zie de andere voorbeelden in dit topic)

Je kunt deze objecten serializen, of ze dan nog bruikbaar zijn na het deserializen is de vraag. Het is een feit dat je ieder object, een sequentie van bytes, gewoon kan opslaan. Zoals ik al zei, kijk maar naar Eloquera of db4o.

[ Voor 5% gewijzigd door Verwijderd op 26-08-2011 09:18 ]

[RobIII]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 09:16:
of ze dan nog bruikbaar zijn na het deserializen is de vraag.

Of 't dan überhaupt zinnig is ze te serializen is dan de werkelijke vraag

[Voutloos]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 09:16:
[...]
Je kunt deze objecten serializen, of ze dan nog bruikbaar zijn na het deserializen is de vraag.

1. Dingen doen zonder zeker te weten dat het bruikbaar is...
2. Als de staat niet te serializen is, is het object dus niet triviaal te serializen.

[whoami]

MSalters schreef op donderdag 04 augustus 2011 @ 16:16:
Een top-level app object serializable maken lijkt me ook wat overkill.

Kan je een subclass serializen (serializable maken) als de base class niet serializable is ?

[Verwijderd]

whoami schreef op vrijdag 26 augustus 2011 @ 10:51:
[...]

Kan je een subclass serializen (serializable maken) als de base class niet serializable is ?

Ja

[Verwijderd]

Voutloos schreef op vrijdag 26 augustus 2011 @ 10:47:
[...]
1. Dingen doen zonder zeker te weten dat het bruikbaar is...
2. Als de staat niet te serializen is, is het object dus niet triviaal te serializen.

De (lokale) staat is _altijd_ te serializen. Zo simpel is het. Ik wil alleen zeggen dan SerializableAttribute alleen sugar is om aan te geven dat het wellicht nuttig kan zijn om een bepaald object van dat type te serializen. Ik weet niet wat je met "triviaal" bedoelt, maar voor mij is een deel van het geheugen persisteren triviaal (dus ieder object).

[Voutloos]

Met triviaal bedoel ik dat het out-of-the-box goed gaat, en dat gaat het niet.

En het is dan ook geen syntactic sugar of enkel syntax. Er is zeker wel een semantische waarde: Er wordt bewust de eigenschap aangehangen dat het te serializen is.

[Janoz]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 11:10:
[...]


De (lokale) staat is _altijd_ te serializen. Zo simpel is het. Ik wil alleen zeggen dan SerializableAttribute alleen sugar is om aan te geven dat het wellicht nuttig kan zijn om een bepaald object van dat type te serializen. Ik weet niet wat je met "triviaal" bedoelt, maar voor mij is een deel van het geheugen persisteren triviaal (dus ieder object).

Maar je gaat hier voorbij aan het feit dat een object niet enkel in het geheugen opgeslagen data is. Persoonlijk ben ik van mening dat je een resource identifier niet kunt serializeren omdat niet de data, maar de resource hetgeen is dat voor dat object van belang is. Door enkel de referentie op te slaan heb je niet ineens de resource (database/ssh/ftp verbinding of file handle oid) ook weer terug bij het deserializeren.

[Verwijderd]

Janoz schreef op vrijdag 26 augustus 2011 @ 13:18:
[...]

Maar je gaat hier voorbij aan het feit dat een object niet enkel in het geheugen opgeslagen data is. Persoonlijk ben ik van mening dat je een resource identifier niet kunt serializeren omdat niet de data, maar de resource hetgeen is dat voor dat object van belang is. Door enkel de referentie op te slaan heb je niet ineens de resource (database/ssh/ftp verbinding of file handle oid) ook weer terug bij het deserializeren.

Dat heb ik ook niet gezegd.

[RobIII]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 14:34:
[...]


Dat heb ik ook niet gezegd.

Dan is het dus niet zinnig om alles te serializen. Net waar het hele topic over gaat. Punt.

[whoami]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 11:08:
[...]


Ja

Neen, dat is niet mogelijk.

code:

       public class Base
        {
            private readonly int _a;

            public Base( int a )
            {
                _a = a;
            }

            public virtual void WriteMe()
            {
                Console.WriteLine ("_a = " + _a);
            }
        }

        [Serializable]
        public class Derived : Base
        {
            private readonly string _b;

            public Derived( string b, int a )
                : base (a)
            {
                _b = b;
            }

            public override void WriteMe()
            {
                base.WriteMe ();
                Console.WriteLine ("_b = " + _b);
            }
        }

        static void Main( string[] args )
        {
            var d = new Derived ("serializetest", 17);
            d.WriteMe ();

            using( var fs = new FileStream (@"c:\tmp\test.zzz", FileMode.Create) )
            {
                var f = new BinaryFormatter ();
                f.Serialize (fs, d);
            }


            using( var fs = new FileStream (@"c:\tmp\test.zzz", FileMode.Open) )
            {
                var f  = new BinaryFormatter ();
                var result = (Derived)f.Deserialize (fs);
                result.WriteMe ();
            }

            Console.ReadLine ();
        }

Resulteert in een [c]SerializationException[/c] bij het serializeren:

{"Type 'SerializeTest.Program+Base' in Assembly 'SerializeTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable."}

Vandaar natuurlijk dat de Object class serializable is.

Verwijderd schreef op vrijdag 26 augustus 2011 @ 01:41:
SerializableAttribute is gewoon syntactische sugar, je kunt alles ook serializen (kijk naar db4o / eloquera). Het geeft aan dat je de intentie hebt om een bepaald type te serializen.

Dikke zever. Het SerializableAttribute is helemaal geen syntactical sugar. Het is de snelste manier om ervoor te zorgen dat je een object makkelijk kunt serializen/deserializen.
Zelfs als je zelf wilt bepalen hoe de serializatie moet gebeuren, en je dus de ISerializable interface gaat gaan implementeren, heb je dat Serializable attribuut dus nog nodig.

[ Voor 16% gewijzigd door whoami op 26-08-2011 14:51 ]

[Janoz]

Dat is ook niet vreemd. Wanneer de superclass niet aangeeft dat hij serializable is, dan kun je nooit een valide state van de superclass garanderen voor de subclass wanneer je die deserializeert.

[Verwijderd]

Vooruit dan:

code:

    class Program
    {
        static void Main(string[] args)
        {
            var container = Db4oFactory.OpenFile("store");
            container.Store(new A() {Prop1 = "Test", Prop2 = 6});
            container.Commit();
            container.Close();

            container = Db4oFactory.OpenFile("store");
            var obj = container.Query<A>(a => a.Prop1 == "Test");


            Console.Write(obj.Prop2); //6
        }
    }

    class A
    {
        public string Prop1 { get; set; }
        [NonSerialized]
        public int Prop2 { get; set; }
    }

Dit geldt volgens wikipedia als seralization.

[RobIII]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 15:53:
Vooruit dan:
...
Dit geldt volgens wikipedia als seralization.

En nu met een resource

[whoami]

Janoz schreef op vrijdag 26 augustus 2011 @ 15:30:
Dat is ook niet vreemd. Wanneer de superclass niet aangeeft dat hij serializable is, dan kun je nooit een valide state van de superclass garanderen voor de subclass wanneer je die deserializeert.

Inderdaad, vandaar ook mijn retorische vraag van een tijdje geleden, eerder in dit topic.

[whoami]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 15:53:
Vooruit dan:

code:

    class Program
    {
        static void Main(string[] args)
        {
            var container = Db4oFactory.OpenFile("store");
            container.Store(new A() {Prop1 = "Test", Prop2 = 6});
            container.Commit();
            container.Close();

            container = Db4oFactory.OpenFile("store");
            var obj = container.Query<A>(a => a.Prop1 == "Test");


            Console.Write(obj.Prop2); //6
        }
    }

    class A
    {
        public string Prop1 { get; set; }
        [NonSerialized]
        public int Prop2 { get; set; }
    }

Dit geldt volgens wikipedia als seralization.

Tja, dit gaat over serializeren in een externe store, zoals eender welke DB, maar dat was volgens mij niet de insteek van de topicstarter.

[.oisyn]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 11:10:
[...]


De (lokale) staat is _altijd_ te serializen.

Als je "lokale staat" definieert als louter dat stukje geheugen in het object, dan wel ja. Maar dan klopt je definitie gewoonweg niet, simple as that.

En who cares wat er daar in het geheugen staat, dat is waar je als gebruiker van dat object totaal niet in geïnteresseerd bent. Het gaat erom wat dat object representeert, en het is die representatie die je wilt serializen (daar heb je het ook over als je het hebt over het serialiseren van objecten).

[ Voor 33% gewijzigd door .oisyn op 26-08-2011 20:49 ]