READ-ONLY OBJECT IN OBJECT-ORIENTED PROGRAMMING

Transcription

1 READ-ONLY OBJECT IN OBJECT-ORIENTED PROGRAMMING Hong Zhou, PhD University of Saint Joseph, West Hartford, CT, USA Abstract Object-oriented programming (OOP) has become the dominant programming paradigm by its promise of easy code maintenance, code reuse, and code evolution. The central dogma in OOP is to model a concept as an object that has its own internal state and behavior. How to limit the access to the internal state of an object is always a tricky question to new OOP programmers. Though OOP languages have various ways of limiting the access to an object s internal state, a call for read-only objects emerges as the protection of data authenticity in information flow becomes more and more critical. Since the existing approaches to achieve read-only concept in programming languages cannot dynamically create read-only objects, this article presents the definition of the keyword readonly and demonstrates how to use it to dynamically generate read-only objects via two case studies. Keywords: Read only, OOP, object, Java Introduction There are primarily two types of programming paradigms: procedural (or structural) and object-oriented. The early programming method is procedural, which means that a program is made of multiple procedures. A procedure can operate on data, but does not store data. Such separation of procedure/code from data causes serious reuse and maintenance problems in cases when the data is changed or the data format is altered. Object-oriented programming (OOP) centers on object creation. An object is a software entity that has its own procedures (which are also called methods or functions) and data, and depending on the data, such an entity has its state. OOP has multiple avenues of advantages over the procedural programming. That is why OOP has become the dominant programming paradigm today. In OOP, a concept is modelled as an object, and therefore each object is designed to accomplish one or more specific tasks or functions. Once an object is created successfully, it can be reused as a 41

2 functional component. This significantly enhances the code reusability in software development. Another advantage of OOP is the inheritance. Through inheritance, a new object can be constructed from an existing object, while this new object can possess all the functions and properties of the existing object. This feature makes the code evolution possible and easy to achieve. Since both the methods and data are stored together in an object, data hiding, i.e., protecting the data of an object, becomes a critical practice in OOP. Data hiding refers to the ability of an object to hide its internal data from being accessed by outside objects. This is usually achieved by defining the internal data of a specific object to be private, thus only the methods inside the object can access the internal data. For some years, it seems that almost every challenge concerning data accessibility in objects has been successfully solved by OOP. However, as data is becoming the center of software development, data access/exchange in the form of objects requires greater attention to protect the data authenticity. For example, when object A gets an array of integers from object B, how do we protect the integrity of this array of integers? In such a case, a call for read-only objects arises. As Java is the most popular OOP language (Hendrickson, 2012), let s use Java as the example to discuss this read-only concept. In this paper, using Java as the example, we analyzed the existing approaches to obtain read-only objects, and presented the keyword readonly to directly and dynamically make an object read-only. Read Only in Java: A read-only object is an object whose data fields can be viewed but cannot be modified. This concept is distinct from data hiding. In data hiding, certain data fields of an object are hidden from direct access but are accessible only through predefined methods; and once accessed or obtained, these data fields may or may not be modified by outside callers. Constants The most common way to achieve the concept of read-only in different OOP languages is to define constants. In Java, the keyword final seems to represent read-only for primitive data types. For example, the statement public final int x = 5; makes the variable x viewable by other outside objects but non-modifiable. Once the variable x is set to a value, it cannot be modified again. A deeper analysis on such constants reveals that such a constant is not bona fide read-only because it only guarantees that the variable cannot be re-assigned. It does not have any restriction on the value itself. Since primitive data is always a literal value which is by default constant, it seems that in this case both the variable and its value are constant 42

3 and therefore read-only. However, if the keyword final is used upon a reference data type, such as in the following statement: private final TestObject tt = new TestObject(); Given TestObject is a class predefined, such a statement only prevents the variable tt from being re-assigned. However, it does not have any restriction on the actions or modifications on the object referenced by tt. If the TestObject has accessible methods to modify its contents, then the content of the TestObject referenced by tt can still be modified by outside callers. Therefore, defining constants does not create real read-only objects. Immutable Objects In Java, there are a few types of objects that are truly read-only. One example is String. String objects are said to be immutable, which means a String object cannot be modified once it is created (Arnold, Gosling, & Holmes, 2000) (Gaddis, 2011). Instead, any changes on a String object will generate a new copy. Such immutable objects are achieved by carefully designing the class template. Therefore, whether an object is immutable or not depends on its class template. The immutability is predefined. The following two statements demonstrate this understanding. 1) String s = new String( Hello World ); 2) s = s.tolowercase(); Statement 1) defines s as a String variable and assigns it the value Hello World. Once created, the value Hello World is constant and cannot be modified. Though statement 2) converts it into lowercase, what really happened is that a new String is generated as hello world and this new value is assigned to variable s. This example illustrates that the variable s can be re-assigned while the String object it references cannot be modified. This example also shows that a variable and its referencing object are treated separately in Java. Though it has been suggested that if possible, classes are better to be designed as immutable (Bloch, 2008), there are not many predefined immutable classes in Java. In Java, another frequently used immutable object is Integer. Both Integer and String are carefully designed so that any changes made upon an object of them will generate a copy, thus leaving the original object unchanged. Certainly, the creation of immutable objects depends on the class design process. To have immutable objects, the class templates must be predefined or predesigned as immutable. Clearly, using predefined classes cannot offer dynamic read-only objects. Wrapper Classes A typical case calling for read-only objects is when a method returns an array of numbers that requires to be read-only. In the current 43

4 programming environment, once the caller obtains the array, it obtains the reference to this array and therefore it can modify the content of the array at will. How to make such an array of numbers read-only? Though a solution to this case is to return a copy of the array leaving the original array intact, such a solution may result in memory shortage when the array is of large size and such copies keep accumulating. An alternate solution to this case is to use a wrapper class. For an array of numbers or of any other primitive data types, it is easy to design a wrapper class such that no direct access to the array data is allowed. Instead, the caller can only obtain one item of the array at a time. The following example demonstrates this solution in which the class IntegerArray is a wrapper class to render read-only arrays of integers. public class IntegerArray{ private int[] a; public IntegerArray(int[] v){ a = v; //deep copy is a better practice here public int getlength(){ return a.length; public int getinteger(int index){ return a[index]; The above solution works well for primitive data types, though its disadvantage is to require additional programming for predefined wrapper classes. However, if the returned data is an array of objects, i.e. an array of reference data type, the above solution cannot guarantee that each object inside the array is read-only. When each single element of the array is a referenced object, once the caller obtains an element, the caller can still modify the content of this object element if the object provides such modification accessibility. To ensure that the read-only is fully achieved, the objects in the array must be designed in such a way that modification is prohibited. The complexity of rendering read-only objects via using wrapper classes can become too expensive to seriously impact the software development process. Besides making the programming process less intuitive but more complicated, using wrapper classes still cannot create read-only objects dynamically because all the wrapper classes must be predefined. Therefore, strictly speaking, Java does not offer read-only objects that can be defined and created dynamically. 44

5 The Proposed Read Only: As it seems that currently there is no good way to generate read-only objects on the fly, the keyword readonly is then proposed in this paper. This keyword exists in the programming language c#. Though the keyword readonly of c# is slightly different from the traditional constant as defined by the keyword const, it still places restriction on the variable only, i.e. once the variable is assigned a value, the variable cannot be reassigned, while the referenced object can be modified independently. In this sense, the keyword readonly of programming language c# is not truly read-only. The central idea of this paper is that the keyword readonly makes an object read-only. It does not define an object to be read-only, it makes an object to be read-only. In addition, it makes both the variable and the object referenced by the variable read-only. To understand the keyword readonly proposed in this paper, let s elucidate the rules governing the proposed readonly concept. a) The keyword readonly can apply to variables of both primitive and reference data types. b) Once a variable and its referencing object are made read-only, they stay read-only. c) Once a variable is made read-only, it cannot be assigned a value again, and the object referenced by the read-only variable cannot be modified. d) A method returning a read-only object must be a read-only method marked by the keyword readonly. A read-only object can only be returned by a read-only method. For example: public static readonly TestObject findtheobject() e) The read-only property of a read-only object is remained in the process of serialization and deserialization of this object. f) Before an object is made read-only, all of its composed fields should be read-only. If a field is of reference data type and is not read-only, this field will be assigned null automatically. Rule a) dictates that the readonly keyword can be applied to both primitive and reference data types. When applied to a primitive data type, it functions like the keyword final. Nevertheless, it is not recommended to use keyword readonly when the keyword final is supposed to be used on primitive data types. Rule b) dictates that the read-only-making process is irreversible. Once a variable or object is made read-only, it stays read-only. Rule c) dictates that once a variable is made read-only, i.e. once the keyword readonly is used upon a variable, both the variable and its referencing object become read-only. Thus, right from this moment, this 45

6 variable cannot be assigned a value again, and the object referenced by this variable cannot be modified any more either. Rule d) is to help clearly specify the expectation from a method. If a method or function is returning a read-only object without clearly stating it, the caller may not be aware of what it is getting. Rule e) dictates that the read-only property of a read-only object is to be kept even when it is serialized and de-serialized. This rule guarantees that such a read-only property of an object can be saved into a binary file and can also be transported across network. Rule f) dictates that in the case of object aggregation or composition, before the hosting object is made read-only, the contained objects or data fields should better be read-only for good programming practice. However, if a contained field is not read-only at that time, it will be forced to become read-only. In the case when the field is of a primitive data type, the variable is forced to become read-only. In the case where the field is of reference data type, the variable is assigned null to leave the referenced object intact. This rule is critical because it guarantees that nothing obtained from a read-only object can be further modified, thus ensures the full read-only. However, this rule may create dangling objects when some reference variables are assigned null leaving the referenced objects dangling. Therefore, as a rule of good programming practice, it is necessary to make sure that all the fields are read-only before making the hosting object read-only. The following two case studies help illustrate the use of the keyword readonly. Case Study 1 public readonly int[] compute(int i){ int[] data = new int[10]; for(int t=0; t<data.length; t++){ data[t] = t + t * i; readonly data; return data; In the above codes, an integer array was first generated. Before the keyword readonly was applied on the variable data, both the variable data and its referenced integer array are modifiable. The statement readonly data, however, makes both the variable data and its referencing integer array read-only. Any attempts to modify the content of the variable data is now prohibited. Because data is now read-only and will be returned, the method is marked as readonly. 46

7 Case Study 2 public class MyCode{ private int code; private String name; public MyData(int c, String s){ code = c; name = s; public int getcode(){ return code; public void setcode(int c){ code = c; public class CheckCode{ public static void main(string args[]){ MyCode me = new MyCode(100, USA ); readonly me; In the above case study, the class MyCode has two fields and one field is of type String, which is a reference data type. So, in the class CheckCode, the statement readonly me will make the field name of the object me to be null automatically. Nevertheless, once an object of MyCode is made read-only, its internal state cannot be modified any more, i.e. the use of the method setcode() is prohibited. However, the method getcode() is still functional. Discussion and Conclusion Due to the increasing data manipulation and exchange occurring in computer software systems, the protection of data genuineness becomes critical. One way to protect data is to have read-only objects. Though programming languages such as Java has ways to achieve read-only to a certain degree, there is still no dedicated method to dynamically create readonly objects. Meanwhile, though the programming language c# has the keyword readonly, it only prohibits the read-only variable from being reassigned while it does not protect the referenced object from being modified; and it cannot dynamically make an object read-only either. The 47

8 proposed keyword readonly proposed in this article is a step forward in offering read-only objects with dynamism. The keyword readonly introduced in this paper is more like an operator in that it changes the nature of an object. An object can be modifiable initially. When it is ready to make it read-only, the keyword readonly is applied upon the variable referencing this object. This application has two impacts. It makes both the variable and the referenced object readonly. The real challenge lies in the case when an object is composed of other objects and this hosting object is to be made read-only. What should happen to the fields of this hosting object? This paper proposed a reasonable approach in which all the contained fields are forced to become read-only, though this approach has its drawback in that it can generate dangling objects. Thus, it is important to follow good programming practice in the use of the keyword readonly. Abusing the keyword readonly can make it notorious, like the keyword goto which was once very popular but later was considered harmful (Dijkstra, 1968). The proper uses of constants in all programming languages are examined by the compiler. Any attempts to reassign the variable that is defined to be a constant will result in a compilation error. The use of the proposed keyword readonly, however, can make an object read-only dynamically. An object can be modifiable initially, but later is made to be read-only. Enforcing the complete check of proper uses of the keyword/operator readonly requires an intelligent compiler. Nevertheless, run-time errors may occur when the keyword readonly is not properly used. To completely avoid run-time errors, detailed specification about the use of this keyword readonly becomes necessary when implementing this keyword in a programming language. In Java, the operator instanceof tests if an object referenced by a variable is of a certain type. With this keyword/operator readonly, it is reasonable to have another operator to test if a variable and its referencing object are read-only. Having such a testing operator can certainly help ease the programming with read-only objects. The keyword readonly has already appeared in the programming language c#, which testifies the need for read-only objects. True read-only objects that can be created dynamically may be coming soon in other objectoriented programming languages. References: Arnold, K., Gosling, J., & Holmes, D. (2000). The Java Programming Language (third edition). Addison-Wesley. Bloch, J. (2008). Effective Java. Addison-Wesley. 48

9 Dijkstra,, E. W. (1968). Go To Statement Considered Harmful. Communications of the ACM, Gaddis, T. (2011). Starting out with Java Early Objects (4th edition). Boston: Addison Wesley. Hendrickson, M. (2012, April 06). A deep look at the market for books on programming languages. Retrieved from O'Reilly Radar: 49