Чому Java потрібен інтерфейс, що підтримується?

Ми активно працюємо з серіалізацією, і необхідність вказувати тег Serializable на кожному об'єкті, який ми використовуємо, є певним тягарем. Особливо, коли це третій клас, який ми не можемо змінити.

Питання: оскільки Serializable - це порожній інтерфейс, і Java забезпечує надійну серіалізацію, коли ви додасте implements Serializable- чому вони не зробили все серіалізаційним і це все?

Що я пропускаю?

Серіалізація загрожує підводними каменями. Підтримка автоматичної серіалізації цієї форми робить внутрішні класи класів частиною загальнодоступного API (саме тому javadoc надає вам збережені форми класів ).

Для тривалої наполегливості клас повинен бути в змозі розшифрувати цю форму, що обмежує зміни, які ви можете внести до дизайну класу. Це порушує інкапсуляцію.

Серіалізація також може призвести до проблем із безпекою. Завдяки можливості серіалізувати будь-який об'єкт, на який він має посилання, клас може отримати доступ до даних, до яких зазвичай не зможе (розбираючи отримані дані байтів).

Є й інші питання, такі як серіалізована форма внутрішніх класів недостатньо чітко визначена.

Зростання серіалізму всіх класів посилить ці проблеми. Ознайомтеся з Ефективною версією Java другого видання , зокрема Пункт 74: Розумно реалізуйте Serializable .

Я думаю, що і Java, і .Net люди помилилися цього разу, було б краще зробити все серіалізаційним за замовчуванням і потрібно лише позначити ті класи, які не можна безпечно серіалізувати замість цього.

Наприклад, у Smalltalk (мовою, створеній у 70-х роках), кожен об'єкт за замовчуванням є серіалізаційним. Я не маю поняття, чому це не так у Java, враховуючи той факт, що переважна більшість об'єктів безпечна для серіалізації і лише деякі з них - ні.

Позначення об'єкта як серіалізабельний (з інтерфейсом) не робить магічний серіалізабельний об'єкт, він був серіалізаційним протягом усього часу , це просто те, що ви зараз висловили щось, що система могла б знайти самостійно, тому я не бачу справжньої вагомої причини для серіалізація - така, яка є зараз.

Я думаю, що це було або погане рішення дизайнерів, або серіалізація була задумливою, або платформа ніколи не була готова зробити серіалізацію за замовчуванням для всіх об'єктів безпечно та послідовно.

Не все справді серіалізується. Наприклад, візьміть підключення до мережевої розетки. Ви можете серіалізувати дані / стан об’єкта сокета, але суть активного з'єднання буде втрачена.

Основна роль Serializable в Java полягає в тому, щоб фактично зробити всі інші об'єкти несеріалізаційними. Серіалізація - це дуже небезпечний механізм, особливо при його замовчуванні. Отже, як і дружба в C ++, вона за замовчуванням вимикається, навіть якщо це коштує трохи, щоб зробити речі серійними.

Серіалізація додає обмежень та потенційних проблем, оскільки сумісність структури не застрахована. Добре, що воно вимкнено за замовчуванням.

Я мушу визнати, що я бачив дуже мало нетривіальних класів, де стандартна серіалізація робить те, що я цього хочу. Особливо у випадку складних структур даних. Таким чином, зусилля, які ви витратили на створення класу серіалізму, належним чином зменшують витрати на додавання інтерфейсу.

Для деяких класів, особливо тих, які представляють щось більш фізичне, наприклад з'єднання Файл, Сокет, Нитка або БД, серіалізувати екземпляри абсолютно не має сенсу. Для багатьох інших серіалізація може бути проблематичною, оскільки вона руйнує унікальні обмеження або просто змушує вас мати справу з екземплярами різних версій класу, чого ви, можливо, не хочете.

Можливо, було б краще зробити все Serializable за замовчуванням і зробити класи не серіалізаційними через ключове слово або інтерфейс маркера, але тоді, ті, хто повинен використовувати цю опцію, напевно, не думали б про це. Таким чином, якщо вам потрібно реалізувати Serializable, вам це скажуть винятком.

Я думаю, що все-таки потрібно було переконатись, що ти, як програміст, знаєш, що твій об’єкт мій буде серіалізований.

Мабуть, все було серіалізаційним у деяких попередніх проектах, але через безпеку та коректність стосується остаточного проекту, як ми всі знаємо.

Джерело: Чому класи повинні реалізовувати Serializable для запису до ObjectOutputStream? .

Потрібно чітко заявити, що екземпляри певного класу є серіалізаційними, мова змушує вас задуматися, якщо ви повинні дозволити це. Для простих об'єктів цінності серіалізація є тривіальною, але в більш складних випадках вам потрібно по-справжньому продумати.

Просто покладаючись на стандартну підтримку серіалізації JVM, ви піддаєте себе всіляким неприємним проблемам версій.

Унікальність, посилання на «реальні» ресурси, таймери та багато інших видів артефактів НЕ є кандидатами на серіалізацію.

Прочитайте це, щоб зрозуміти інтерфейс Serializable і чому ми повинні зробити лише кілька класів Serializable, а також ми будемо дбати про те, де використовувати перехідне ключове слово, якщо ми хочемо видалити кілька полів із процедури зберігання.

http://www.codingeek.com/java/io/object-streams-serialization-deserialization-java-example-serializable-interface/

Ну, моя відповідь - це недарма причини. І з ваших коментарів я бачу, що ви вже це дізналися. Інші мови із задоволенням намагаються серіалізувати все, що не перескакує на дереві після того, як ви порахували до 10. Об'єкт повинен за замовчуванням бути серіалізаційним.

Отже, що вам в основному потрібно зробити, це прочитати всі властивості вашого стороннього класу самостійно. Або, якщо для вас це варіант: декомпілюйте, поставте туди прокляте ключове слово та перекомпілюйте.

У Java є деякі речі, які просто неможливо серіалізувати, оскільки вони є специфічними для виконання. Такі речі, як потоки, потоки, час виконання тощо, і навіть деякі класи GUI (які підключені до базової ОС) не можуть бути серіалізовані.

Хоча я згоден з пунктами, наведеними в інших відповідях тут, справжня проблема полягає в десериалізації: Якщо визначення класу зміниться, то існує реальний ризик, десеріалізація не буде працювати. Ніколи не змінюючи існуючі поля - це досить велике зобов’язання для автора бібліотеки! Підтримка сумісності API достатня робота, як є.

Клас, який потрібно зберігати до файлу чи іншого носія, повинен реалізувати інтерфейс Serializable, щоб JVM дозволяв серіалізувати об'єкт класу. Чому клас Object не серіалізується, тоді жодному з класів не потрібно реалізовувати інтерфейс, адже JVM серіалізує клас лише тоді, коли я використовую ObjectOutputStream, а це означає, що управління все ще в моїх руках, щоб дозволити JVM серіалізувати.

Причина, по якій клас Object не є серіалізаційним за замовчуванням у тому, що версія класу є основною проблемою. Тому кожен клас, який зацікавлений у серіалізації, повинен бути позначений як Serializable явно та надати номер версії serialVersionUID.

Якщо serialVersionUID не надається, ми отримуємо несподівані результати під час десеріалізації об'єкта, тому JVM викидає InvalidClassException, якщо serialVersionUID не відповідає. Тому кожен клас повинен реалізувати інтерфейс Serializable і надати serialVersionUID, щоб переконатися, що клас, представлений на обох кінцях, однаковий.