defensive copying

最新推荐文章于 2019-04-04 15:29:23 发布

转载最新推荐文章于 2019-04-04 15:29:23 发布 · 521 阅读

文章标签：

#immutable #date #string #class #object #thread

本文介绍了防御性复制的概念及其重要性，特别强调了在处理可变对象时如何避免意外修改，确保API的安全性和稳定性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Defensive Copying
19 comments, 0 freshness points, 270 goodness points
Submission of type Article by YoGee Jun 6, 2007 5:35:33 AM | Tags: Copying Defensive Immutable Mutable good safety thread

An introduction to defensive copying.

Content

Programming defensively is an essential skill to learn if you want to produce a robust API. By implementing defensive copying you can avoid unwanted and unexpected behaviour that can compromise security and confuse your API clients.

The key to understanding defensive copying is understanding the difference between a mutable and an immutable class.

An immutable class is a class whose instances cannot be modified, for example the java.lang.String class.

A mutable class is a class whose instances can be modified, for example the java.util.Date class.

Whilst immutable objects are inherently thread safe, mutable objects are not, and this is when we need to consider making defensive copies.

Take the following example:

public final class Person {

private final String name;

private final Date dateOfBirth;

public Person(final String name, final Date dateOfBirth)

{ this.dateOfBirth = dateOfBirth; this.name = name; }

public String getName() { return name; }

public Date getDateOfBirth() { return dateOfBirth; }

}

This class is immutable, right? Wrong.

Whilst it appears we cannot change the internal state of a Person Object after it has been instantiated this is actually not the case since dateOfBirth is a mutable parameter.

final Date dob = new Date(455531800421l);

final Person p = new Person("John Smith", dob);

System.out.println(p.getName() + " dob: " + p.getDateOfBirth());

dob.setTime(555531800421l); // could also get dob via p.getDateOfBirth(); here System.out.println(p.getName() + " dob: " + p.getDateOfBirth());

Result:

John Smith dob: Fri Jun 08 09:36:40 BST 1984 John Smith dob: Sun Aug 09 19:23:20 BST 1987

We have changed John Smith's DOB.

To avoid this we can defensively copy dateOfBirth: (notice we do this when we set dateOfBirth and when we expose it)

public final class Person {

private final String name;

private final Date dateOfBirth;

public Person(final String name, final Date dateOfBirth)

{ this.dateOfBirth = new Date(dateOfBirth.getTime()); this.name = name; }

public String getName() { return name; }

public Date getDateOfBirth() { return (Date) dateOfBirth.clone(); }

}

Now it is not possible to modify the internal state of a Person Object after it has been instantiated and it is truly immutable (assuming we have an appropriate SecurityManager in place).

Defensive copying isn't just for immutable classes, whenever you are dealing with a client provided Object consider if that Object is mutable and what the side effects could be if the client modifies that Object.