defensive-copy

Regarding an Immutable class defensive copying

半腔热情 提交于 2020-01-02 07:11:15
问题 I have a query regarding creating a Immutable class. Following are the points which I take in consideration: Make the class final Make all members final, set them explicitly, in a static block, or in the constructor Make all members private No Methods that modify state Be extremely careful to limit access to mutable member components(remember the field may be final but the object can still be mutable. ie private final Date imStillMutable) - See defensive copying or its cousin copy

Create a Defensive Copy in the Constructor

拟墨画扇 提交于 2019-12-24 01:53:35
问题 The following is just example code to explain the problem I have trouble understanding: Lets say I have the following Professor class, note the public getters and setters: public class Professor { public string id {get; set; } public string firstName{get; set;} public string lastName {get; set;} public Professor(string ID, string firstName, string lastname) { this.id = ID; this.firstName = firstName; this.lastName = lastname; } } and Course: public class Course { string courseCode {get;

Create a Defensive Copy in the Constructor

谁说我不能喝 提交于 2019-12-24 01:52:40
问题 The following is just example code to explain the problem I have trouble understanding: Lets say I have the following Professor class, note the public getters and setters: public class Professor { public string id {get; set; } public string firstName{get; set;} public string lastName {get; set;} public Professor(string ID, string firstName, string lastname) { this.id = ID; this.firstName = firstName; this.lastName = lastname; } } and Course: public class Course { string courseCode {get;

Inefficiency of defensive copy in Java [closed]

青春壹個敷衍的年華 提交于 2019-12-13 13:27:55
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 6 years ago . I'm a longtime C/C++ programmer who's learning Java. I've read about the problem of breaking encapsulation by having an accessor method that returns a reference to a private field. The standard Java solution seems to be defensive copying - calling the copy constructor or

How do I make defensive copy of an object?

偶尔善良 提交于 2019-12-04 01:46:56
问题 How do I make defensive copies of a Mutable Object which contains a mutable field in an Immutable Object? class ImmutableObject { private final MutableObject immutable_field; ImmutableObject(MutableObject y) { this.immutable_field = y; } } class MutableObject { public int mutable_field; } The MutableObject does not have a constructor that lets me set the field. The MutableObject's current state should be captured in the Immutable Object and never changed. 回答1: What you need to do is in

How do I make defensive copy of an object?

北战南征 提交于 2019-12-01 09:09:09
How do I make defensive copies of a Mutable Object which contains a mutable field in an Immutable Object? class ImmutableObject { private final MutableObject immutable_field; ImmutableObject(MutableObject y) { this.immutable_field = y; } } class MutableObject { public int mutable_field; } The MutableObject does not have a constructor that lets me set the field. The MutableObject's current state should be captured in the Immutable Object and never changed. What you need to do is in MutableObject return_immutable_field() { return immutable_field; } Change to: MutableObject return_immutable_field

Defensive copy of Calendar

心已入冬 提交于 2019-11-30 00:52:21
问题 Been trying to find the best way to implement a method that makes a defensive copy of a Calendar object. eg: public void setDate(Calendar date) { // What to do.... } I am particularly concerned about interleaving of threads when checking for null input and making the copy or am I missing something very apparent? 回答1: (Aimed at a slightly different audience now, I guess...) I would use clone() if I absolutely had to use Calendar at all (instead of Joda Time). You argue in comments that you're