Usar uma interface vazia é muito horrendo?

Programação Java
#21

O Serializable do java não é uma inteface vazia;
Criar uma interface vazia na minha opinião ou é erro de modelagem ou é implementação desnecessária. Como é um trabalho acadêmico, verifique a possibilidade de criar novas funcionalidades para o sistema para aí sim você representar o conceito na prática.

#22

O Serializable do java não é uma inteface vazia;
Criar uma interface vazia na minha opinião ou é erro de modelagem ou é implementação desnecessária. Como é um trabalho acadêmico, verifique a possibilidade de criar novas funcionalidades para o sistema para aí sim você representar o conceito na prática.

[/quote]

Abri ontem o fonte da Serializable, tenho o jdk 7 na minha máquina, e é uma interface vazia.

Veja:

[code]/*

  • @(#)Serializable.java 1.25 05/11/17
  • Copyright 2006 Sun Microsystems, Inc. All rights reserved.
  • SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
    */

package java.io;

/**

  • Serializability of a class is enabled by the class implementing the
  • java.io.Serializable interface. Classes that do not implement this
  • interface will not have any of their state serialized or
  • deserialized. All subtypes of a serializable class are themselves
  • serializable. The serialization interface has no methods or fields
  • and serves only to identify the semantics of being serializable.
  • To allow subtypes of non-serializable classes to be serialized, the
  • subtype may assume responsibility for saving and restoring the
  • state of the supertype’s public, protected, and (if accessible)
  • package fields. The subtype may assume this responsibility only if
  • the class it extends has an accessible no-arg constructor to
  • initialize the class’s state. It is an error to declare a class
  • Serializable if this is not the case. The error will be detected at
  • runtime.
  • During deserialization, the fields of non-serializable classes will
  • be initialized using the public or protected no-arg constructor of
  • the class. A no-arg constructor must be accessible to the subclass
  • that is serializable. The fields of serializable subclasses will
  • be restored from the stream.
  • When traversing a graph, an object may be encountered that does not
  • support the Serializable interface. In this case the
  • NotSerializableException will be thrown and will identify the class
  • of the non-serializable object.
  • Classes that require special handling during the serialization and
  • deserialization process must implement special methods with these exact
  • signatures:
  • <PRE>
  • private void writeObject(java.io.ObjectOutputStream out)
  • throws IOException
  • private void readObject(java.io.ObjectInputStream in)
  • throws IOException, ClassNotFoundException;
  • private void readObjectNoData()
  • throws ObjectStreamException;
  • </PRE>

  • The writeObject method is responsible for writing the state of the

  • object for its particular class so that the corresponding
  • readObject method can restore it. The default mechanism for saving
  • the Object’s fields can be invoked by calling
  • out.defaultWriteObject. The method does not need to concern
  • itself with the state belonging to its superclasses or subclasses.
  • State is saved by writing the individual fields to the
  • ObjectOutputStream using the writeObject method or by using the
  • methods for primitive data types supported by DataOutput.

  • The readObject method is responsible for reading from the stream and

  • restoring the classes fields. It may call in.defaultReadObject to invoke
  • the default mechanism for restoring the object’s non-static and
  • non-transient fields. The defaultReadObject method uses information in
  • the stream to assign the fields of the object saved in the stream with the
  • correspondingly named fields in the current object. This handles the case
  • when the class has evolved to add new fields. The method does not need to
  • concern itself with the state belonging to its superclasses or subclasses.
  • State is saved by writing the individual fields to the
  • ObjectOutputStream using the writeObject method or by using the
  • methods for primitive data types supported by DataOutput.

  • The readObjectNoData method is responsible for initializing the state of

  • the object for its particular class in the event that the serialization
  • stream does not list the given class as a superclass of the object being
  • deserialized. This may occur in cases where the receiving party uses a
  • different version of the deserialized instance’s class than the sending
  • party, and the receiver’s version extends classes that are not extended by
  • the sender’s version. This may also occur if the serialization stream has
  • been tampered; hence, readObjectNoData is useful for initializing
  • deserialized objects properly despite a “hostile” or incomplete source
  • stream.

  • Serializable classes that need to designate an alternative object to be

  • used when writing an object to the stream should implement this
  • special method with the exact signature:
  • <PRE>
  • ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;
  • </PRE>
  • This writeReplace method is invoked by serialization if the method
  • exists and it would be accessible from a method defined within the
  • class of the object being serialized. Thus, the method can have private,
  • protected and package-private access. Subclass access to this method
  • follows java accessibility rules.
  • Classes that need to designate a replacement when an instance of it
  • is read from the stream should implement this special method with the
  • exact signature.
  • <PRE>
  • ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;
  • </PRE>
  • This readResolve method follows the same invocation rules and
  • accessibility rules as writeReplace.
  • The serialization runtime associates with each serializable class a version
  • number, called a serialVersionUID, which is used during deserialization to
  • verify that the sender and receiver of a serialized object have loaded
  • classes for that object that are compatible with respect to serialization.
  • If the receiver has loaded a class for the object that has a different
  • serialVersionUID than that of the corresponding sender’s class, then
  • deserialization will result in an {@link InvalidClassException}. A
  • serializable class can declare its own serialVersionUID explicitly by
  • declaring a field named <code>“serialVersionUID”</code> that must be static,
  • final, and of type <code>long</code>:
  • <PRE>
  • ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
  • </PRE>
  • If a serializable class does not explicitly declare a serialVersionUID, then
  • the serialization runtime will calculate a default serialVersionUID value
  • for that class based on various aspects of the class, as described in the
  • Java™ Object Serialization Specification. However, it is <em>strongly
  • recommended</em> that all serializable classes explicitly declare
  • serialVersionUID values, since the default serialVersionUID computation is
  • highly sensitive to class details that may vary depending on compiler
  • implementations, and can thus result in unexpected
  • <code>InvalidClassException</code>s during deserialization. Therefore, to
  • guarantee a consistent serialVersionUID value across different java compiler
  • implementations, a serializable class must declare an explicit
  • serialVersionUID value. It is also strongly advised that explicit
  • serialVersionUID declarations use the <code>private</code> modifier where
  • possible, since such declarations apply only to the immediately declaring
  • class–serialVersionUID fields are not useful as inherited members. Array
  • classes cannot declare an explicit serialVersionUID, so they always have
  • the default computed value, but the requirement for matching
  • serialVersionUID values is waived for array classes.
  • @author unascribed
  • @version 1.25, 11/17/05
  • @see java.io.ObjectOutputStream
  • @see java.io.ObjectInputStream
  • @see java.io.ObjectOutput
  • @see java.io.ObjectInput
  • @see java.io.Externalizable
  • @since JDK1.1
    */
    public interface Serializable {
    }[/code]

Tem algo de errado aí?

#23

Segundo o javadoc, Serializable é sim uma interface vazia, assim como Cloneable.

#24

[quote=alcionj][quote=rodrigo.uchoa]O Serializable do java não é uma inteface vazia;[/quote]Vc viu o link que você citou pelo menos? O.o

#25