School of computer science and informatics, cardiff university
Object-Oriented Programming
Download 174.27 Kb.
|
- Navigate this page:
- Eclipse
- 4. Critical Analysis of Research Material
Object-Oriented ProgrammingObject-oriented programming has become the most used methodology for software development. Many researchers [30, 31, 33] describe object-oriented as having three key concepts which characterise its methodology. The central principle is that of data abstraction, and encapsulation of data and behaviour in the form of objects, which store fields and operations, as well as controls on the access of data within. Data abstraction states that a program should not assume internal representations of objects. Objects get requested through messages, whilst the requester gets what it wants without any consideration of how a particular action occurs. This obscures the implementation details from the programmer [31]. Encapsulation describes the restriction of access to an object’s attributes without using appropriate operations, achieved through making attributes private and adding setter and getter methods to change or access values respectively [3]. This encapsulation lends itself to inheritance, by allowing classes to extend parent classes by addition or alteration of methods and variables, through incremental modification [14]. Inheritance also gives objects the potential of reuse, which Meyer [24] describes as a major benefit of OOP use due to its potential increases in productivity of developers and Sebesta [33] stated that it was an important factor in the paradigm’s popularity, as inheritance allows common operations and attributes to be accessed through the inheritance network, improving maintenance [31]. Dynamic binding, or polymorphism, links in with the notion of inheritance, making the process more flexible by allowing binds to method calls to be determined at runtime, taking place at a method call when the method is overridden and the correct version is determined [30]. The popularity of object-oriented programming is down to a number of advantages that lead from its use. The Saylor Foundation [34] attributes the paradigm’s modularity and extensibility to an improvement in productivity by developers, as well as maintainability. However, in general, object-oriented use increases the length of a program, which in turn will affect the speed at which it operates, because more instructions are generally required than a procedural approach. TIOBE Software measures programming language popularity on search engine results, and Java is currently ranked at number one [36]. In comparison, from the same index, AspectJ is not listed in the top 100 languages, although it is listed as one language being tracked by TIOBE.
JavaFirst released in 1995 by Sun Microsystems [17], Java is an object-oriented programming language, written at a high level, meaning specific details of machine operations and representation are hidden from the programmer, which promotes the language’s aim of being simple to allow for better comprehension and fluency [10]. One example of hidden operations is memory management, which is done automatically through garbage collection, which prevents the programmer from allocating or deallocating memory manually. Java is also designed to be easy to use when compiling, which is achieved by two properties. The Java language is both statically typed, with variables and expressions assigned a type known at compile time, and strongly typed, which restricts the value that can be assigned to a variable and the operations that support that variable or expression. Both of these concepts help error detection at compilation time. EclipseTo ensure that this experiment was unbiased to either paradigm, it was important to identify a development tool which was capable of compiling and editing both Java and AspectJ programs. This is achieved through the use of the AspectJ Development Tools (AJDT) plugin [6], which can be installed directly to Eclipse, an open-source multi-language development environment developed by the Eclipse Foundation. In an attempt to increase popularity, AspectJ became associated with the Eclipse platform in 2002 [20]. To aid familiarity with Java users, the AspectJ editor has similar features, such as indicating syntax errors, organising imports and supports folding, when sections of code can be collapsed when not required [7]. The editor assists the user with identifying where advice is executed through the use of icons, which also indicate the type of advice or declaration when viewing Java code. AJDT also allows for the conversion of existing Java projects into an AspectJ project, automatically importing the required reference libraries. An AspectJ project can then be exported as a runnable JAR file, at which point weaving is achieved. 4. Critical Analysis of Research MaterialTo build a picture of the aspect-oriented paradigm, as well as its current status amongst programmers, a variety of research papers, journals and textbooks were sourced. In addition, background information was required for object-oriented programming and the tools being used. This section critically analyses these sources, and their demonstration of the problems being addressed by this thesis. Discussion on the actual research process is included in the reflection section. The initial batch of research centred on establishing the key concepts and ideas behind aspect-oriented programming, and their potential uses, without forgetting critics of the approach and areas which still need research. After looking at the origins of the paradigm, particularly through reading the work of Gregor Kiczales, it was important to find a recent assessment of the approach. The most recent paper found was by Grekova [11], published in 2012, which was especially useful due to its comparisons in a theoretical way to object-oriented programming. The majority of sources cited for this thesis were concerned with AspectJ, its origins and syntax, idioms and design patterns which could be used, and its current usage. The most obvious starting point was the work of Kiczales and his team at Xerox PARC [20, 21]. Whilst these were well written for the novice, it was obvious that it was written more to promote AspectJ than to critically assess its potential benefits, mainly focussing on the strengths of AspectJ and the underlying paradigm, although some areas of further work were also discussed. A useful paper for understanding the compilation process was that written by Hilsdale and Hugunin [16], which outlined the process of bytecode generation, and its weaving technique which could be compared in terms of time and the effect it has, if any, on the final code. Several papers found, including those by Wampler [37], as well as Hanenberg’s work with both Schmidmeier [15] and Costanza [12], look at idioms and design patterns for AspectJ, some of which are inspiration from object-oriented practice. These prove that an aspect-oriented approach can achieve the same outcomes as object-oriented programs, however these are slightly abstract and do not give examples of a larger scale similar to the system being developed as part of this thesis. All of these papers are written for a new audience to the paradigm, linking integral concepts to more recognisable object-oriented ones and certainly helped understanding on my part. Whilst many of object-oriented programming’s attributes are common knowledge, it was still important to gauge advantages and disadvantages of its use, and to find areas which could be addressed through the use of AspectJ. In addition to the books from Nino & Hosch [30] and Brookshear [3] which I already owned, both of which give a good grounding on the paradigm and Java in particular, some research papers were found. The majority were quite old, such as Meyer’s work on reusability [24] which was written in 1985, but the foundations of object-oriented programming have changed very little since then. The Saylor Foundation’s paper on advantages and disadvantages [34] was well written and concise, but it was lacking in references, although some of the points made were common knowledge and so were valid arguments for this thesis. The papers read for research did outline further work in the field, some of which is addressed by this thesis. After defining rules for reuse in AspectJ, Hanenberg and Unland [14] did not discuss incremental modification of aspect-oriented programs and the effect that has on the existing code, which could be something to explore when writing AspectJ code. Whilst Millham and Dogbe [26] show migration of exception handling code, their paper fails to cover any other types of code migration, especially in the area of security. In addition, Grekova’s paper on a comparison of the two paradigms involved in this thesis only concerned itself with the theoretical differences, but not on the development side, a key issue with which this thesis is concerned. Di Lucca and his colleagues from Edmonton, Canada [5] list a series of open research questions at a conference workshop, such as modification of existing code and refractoring from object-oriented code to aspect-oriented code starting with concern identification. These are two key issues which would affect the commercial use of the aspect-oriented paradigm, and are also key to the aims of this thesis, especially refractoring. Download 174.27 Kb. Share with your friends:
|