DOCSLIB.ORG

Design Patterns: Prototype, State, Composite, Memento Let’S Start by Considering the Outline for Lecture 24 Canvaseditor As We Had It at the End of the Last Class

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns: Prototype, State, Composite, Memento Let’S Start by Considering the Outline for Lecture 24 Canvaseditor As We Had It at the End of the Last Class Design Patterns: Prototype, State, Composite, Memento Let’s start by considering the Outline for Lecture 24 CanvasEditor as we had it at the end of the last class. I. The Prototype pattern II. The State pattern Recall that when a button was clicked, the III. The Composite button’s custom ActionListener was pattern invoked, and it set the current figure to the IV. The Memento pattern proper type: rectButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent ae) { canvasEditor.setCurrentFigure (new Rect(0,0, 60, 40)); } }); The setCurrentFigure message was received by the canvasEditor object. Let’s take a look at the code for it. public class CanvasEditor implements MouseListener { private Figure currentFigure; public CanvasEditor(Figure initialFigure) { this.currentFigure = initialFigure; } public void setCurrentFigure(Figure newFigure) { currentFigure = newFigure; } public void mouseClicked(MouseEvent e) { Figure newFigure = ... a new figure based on currentFigure... ; ((DrawingCanvas) e.getSource()). addFigure(newFigure); } Lecture 24 Object-Oriented Languages and Systems 1 public void mousePressed(MouseEvent e) {} public void mouseReleased(MouseEvent e) {} public void mouseEntered(MouseEvent e) {} public void mouseExited(MouseEvent e) {} } Notice that we haven’t said how to draw a new figure based on the current figure. Prototype [Skrien §8.5] How shall we draw this figure? Can we use the currentFigure object? Can we use a constructor to create it? Should we test which kind of figure that we need? if( currentFigure instanceof Ellipse ) newFigure = new Ellipse(...); else if( currentFigure instanceof Rect ) newFigure = new Rect(...); else newFigure = new Square(...); Of course not! Instead, we can just clone the current object. This makes use of Java’s Cloneable interface. By implementing Cloneable , a class allows field-by-field copies to be made of its instances. This allows the Figure referred to by currentFigure to act as a prototype for the figure to be created. Here is the code. CSC/ECE 517 Lecture Notes © 2007 Edward F. Gehringer 2 public Object clone() { try { return super.clone(); } catch (CloneNotSupportedException e) { // This should never happen e.printStackTrace(); return null; } } Why does the method call super.clone ? What class do we place this definition in? How do we use this method to create “ ... a new figure based on currentFigure... ? public void mouseClicked(MouseEvent e) { Figure newFigure = (Figure) currentFigure.clone(); newFigure.setCenter(e.getX(), e.getY()); ((DrawingCanvas) e.getSource()) addFigure(newFigure); } This is an instance of the Prototype pattern. Prototype Intent: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Problem: Customized objects must be created, but we do not know their class or any details of how to create them. Solution: Each class that might have to create an object has a prototypical object. A creation-initiating object is invoked, and it creates objects by asking one of the prototypical objects to make a copy of itself. Lecture 24 Object-Oriented Languages and Systems 3 Implementation: Each class that is going to create an object must have a prototypical object. The parent class implements the Cloneable interface. Then the creation-initiating object clones itself, producing an object of the correct class. State [Skrien §8.6] We’ve been talking about bad uses of case statements in programs. Another way in which case statements are sometimes used is to implement finite-state machines. Here’s an example. Table form of FSM: State/Input input1 input2 input3 input4 State1 (different actions for each State2 combination of state and State3 input) while (state != Final) { switch (state) { case State1: if (input == input1)action11; else if (input == input2) action12; else if (input == input3) action13; else if (input == input4) action14; break; case State2: if (input == input1)action21; else if (input == input2) action22; else if (input == input3) action23; else if (input == input4) action24; break; ... default : System.out.println(" Invalid state: " + state); } } How can we do this in a more o-o fashion? Hint: We can make State an interface! CSC/ECE 517 Lecture Notes © 2007 Edward F. Gehringer 4 public interface How should the State s be defined? How should these methods be implemented for each state? Let’s see how this approach could help our drawing program. So far, our application just creates figures and puts them at different places on the canvas. Once positioned, they stay in the same place forever. We’d like to enhance the app to allow the figures to move. This requires adding a selection tool to the menu. When the selection tool is chosen and (a) the user clicks the mouse button inside an unselected figure, then that figure becomes the only selected figure. (b) the user clicks the mouse button inside a selected figure or outside all the figures, nothing changes. (c) the user presses the mouse inside an unselected figure and drags , then that figure becomes the only selected figure and is dragged along with the mouse. (d) the user presses the mouse inside a selected figure and drags , then that figure and all other currently selected figures are dragged with the mouse. Lecture 24 Object-Oriented Languages and Systems 5 (e) the user presses the mouse outside all figures and drags the mouse, a selection area is outlined and all figures intersecting the selection area become the selected figures. This is pretty standard behavior for drawing applications. It requires a major change to our application. Until now, we were able to ignore mouse presses, drags, and releases. However, if the selection tool is chosen, they will have to be tracked and various actions will have to be implemented. We could do this with conditionals: public void mouseClicked(MouseEvent e){ if currentTool = selection { drawing.getFigureContaining( (e.getX(), e.getY()); } else { Figure newFigure = (Figure) currentFigure.clone(); newFigure.setCenter(e.getX(), e.getY()); ((DrawingCanvas) e.getSource()).addFigure (newFigure); } } But do we want to? What can we do instead? We can use the State pattern! State Intent: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Problem: A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state. Or, an application is characterized by large and numerous case statements that vector flow of control based on the state of the application. CSC/ECE 517 Lecture Notes © 2007 Edward F. Gehringer 6 Solution: Define a set of State objects. Defer the implementation of the different methods to the State objects. The client changes its state from time to time. Implementation: • Define a “context” class to present a single interface to the outside world. • Define a State abstract base class. • Represent the different “states” of the state machine as derived classes of the State base class. • Define state-specific behavior in the appropriate State derived classes. • Maintain a pointer to the current “state” in the “context” class. • To change the state of the state machine, change the current “state” pointer. With the State pattern, the object needing different behavior will maintain a reference to another object representing its state. Instead of having the mouseClicked method in the CanvasEditor , there are now multiple mouseClicked methods, located in the Tool classes. Here’s the method in CreationTool : public void mouseClicked(MouseEvent e){ Figure newFigure = (Figure) myFigure.clone(); newFigure.moveTo(e.getX() - newFigure.getBoundingRect().width / 2, e.getY() - newFigure.getBoundingRect().height / 2); DrawingCanvas canvas = (DrawingCanvas) e.getSource(); canvas.addFigure(newFigure); canvas.unselectAll(); canvas.selectFigure(newFigure); } Here’s the method in SelectionTool : Lecture 24 Object-Oriented Languages and Systems 7 public void mouseClicked(MouseEvent e) { DrawingCanvas canvas = (DrawingCanvas) e.getSource(); Figure figure = canvas.getFigureContaining (e.getX(), e.getY()); pressedInFigure = (figure != null); if (pressedInFigure && ! figure.isSelected()) canvas.unselectAll(); if (pressedInFigure) figure.setSelected(true); origin.x = e.getX(); origin.y = e.getY(); } Composite [Skrien §8.7] Next, we need to allow users to group figures together to make a “composite” figure, which can be manipulated as a single figure. Our Drawing class stores all its figures in an ArrayList named “figures ”. We could create a separate ArrayList for each group. That is, to implement the "Group" menu item action, we can just • remove all the selected figures from figures , • put those selected figures into a new ArrayList , and • add that ArrayList to figures . The problem is that the Drawing class assumes that only Figure objects are in ArrayList s. So all drawing methods will have to be rewritten similarly to this: if( figures.get(i) instanceof ArrayList) ...do the desired processing on the group... else ...do the desired processing on the figure... Things would get worse if a group contained another group. The Composite pattern solves this. It has CSC/ECE 517 Lecture Notes © 2007 Edward F. Gehringer 8 • one or more “leaf” classes, representing individual objects, and • a “composite” class, representing collections of objects. Both of these are subclasses of a component class. A client can refer to components without knowing whether they are composites or
Load more

Recommended publications
  • (GOF) Java Design Patterns Mock Exams
    Gang of Four (GOF) Java Design Patterns Mock Exams http://www.JavaChamp.com Open Certification Plattform Authors: N. Ibrahim, Y. Ibrahim Copyright (c) 2009-2010 Introducing JavaChamp.com Website JavaChamp.com is an Open Certification Platform. What does this mean? JavaChamp is the best place to learn, share, and certify your professional skills. We help you develop yourself in the field of computer science and programming Here are the most significant features offered by JavaChamp: Online Exams Start Online Certification Exams in SCJP, SCEA, EJB, JMS, JPA and more... Top quality mock exams for SCJP, SCEA, EJB, JMS, JPA. Start Express or topic-wise customized exam. * We offer you unlimited free mock exams * Exams cover subjects like SCJP, SCEA, EJB, JMS, JPA,.. * You can take as many exams as you want and at any time and for no charges * Each exam contains 20 multiple choice questions * You can save the exams taken in your exams history * Your exams history saves the exams you took, the scores you got, time took you to finish the exam, date of examination and also saves your answers to the questions for later revision * You can re-take the same exam to monitor your progress * Your exams history helps the system to offer you variant new questions every time you take a new exam, therefore we encourage you to register and maintain an exams history Network Find guidance through the maze, meet Study-Mates, Coaches or Trainees... Studying together is fun, productive and helps you in building your professional network and collecting leads Bookshelf JavaChamp Bookshelf full of PDF eBooks..
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Behavioral Patterns
    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
    [Show full text]
  • JAVA CONCURRENCY ONLINE TRAINING – Java2aspire
    JAVA CONCURRENCY, JAVA PROFILING, THREAD POOLING, JAVA 8 Features, MAVEN and DESIGN PATTERNS ONLINE TRAINING By K.Ramesh Curriculum THREAD POOLING Day 01: Executor Framework 20 min Day 01: Java Profiling 10 min Day 01: Executor 10 min Day 01: ExecutorService 10 min Day 01: Executors 15 min Day 02: ThreadPoolExecutor 20 min Day 02: BlockingQueue 10 min Day 02: Callable vs Runnable 15 min Day 02: Future 15 min JAVA CONCURRENCY Day 03: ConcurrentHashMap 30 min Day 03: Producer Consumer 30 min Day 04: CountDownLatch 20 min Day 04: CyclicBarrier 20 min Day 04: Deadlock Condition 20 min Day 05: Race Condition 30 min Day 05: Semaphore 30 min JAVA 8 FEATURES Day 06: Lambda Expressions 40 min Day 06: Functional Interfaces 10 min Day 06: Functional Programming 10 min Day 07: Method References 10 min Day 07: Default Methods 40 min Day 07: Optional 10 min Day 08: Stream API 1 hour MAVEN Day 09: Project Object Model (POM) 20 min Day 09: Project Description 10 min Day 09: Public Repository 10 min Day 09: Dependency Management 10 min Day 09: Build Configuration 10 min Day 10: Installation 15 min Day 10: Dependency Scope 15 min Day 10: Proprietary Dependencies 15 min Day 10: Project Inheritance 15 min Day 11: Maven life cycle 20 min Day 11: Maven Directory Structure 20 min Day 11: Archetypes 20 min Day 12: Applications 1 hour DESIGN PATTERNS Day 13: Factory Pattern 20 min Day 13: Abstract Factory Pattern 10 min Day 13: Single Pattern 20 min Day 13: Prototype Pattern 10 min Day 14: Composite Pattern 10 min Day 14: Facade Pattern 15 min Day 14: DAO
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Behavioral Patters
    11. Behavioral Pattern Venkat Subramaniam BDP-1 Behavioral Patters • Concerned with algorithms & assignment of responsibilities • Patterns of Communication between Objects Venkat Subramaniam BDP-2 Chain of Responsibility Pattern —Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it“ Venkat Subramaniam BDP-3 Example that would benefit from Chain Of Responsibility Pattern • Various types of Controls are used in an application. Controls handle certain events while they do not handle others. Each control may be invoked from other controls. An event not handled by a control must be passed on to its parent control. Venkat Subramaniam BDP-4 Example using Chain of Responsibility Pattern Client Event Handler handleEvent() Control1 Control2 handleEvent() handleEvent() Venkat Subramaniam BDP-5 When to use Chain Of Responsibility Pattern • More than one object may handle a request, and the handler isn‘t known ahead of time. • One of several objects may be the intended receiver • Set of objects that handle request is dynamic Venkat Subramaniam BDP-6 Consequences of using Chain Of Responsibility • Reduced Coupling • Flexibility in assigning responsibilities œ Distributes responsibilities among objects • Receipt isn‘t guaranteed Venkat Subramaniam BDP-7 Chain Of Responsibility Vs. Other Patterns • Often used with Composite œ Parent acts as Successor Venkat Subramaniam BDP-8 Iterator Pattern —Provide
    [Show full text]
  • Scala by Example (2009)
    Scala By Example DRAFT January 13, 2009 Martin Odersky PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents 1 Introduction1 2 A First Example3 3 Programming with Actors and Messages7 4 Expressions and Simple Functions 11 4.1 Expressions And Simple Functions...................... 11 4.2 Parameters.................................... 12 4.3 Conditional Expressions............................ 15 4.4 Example: Square Roots by Newton’s Method................ 15 4.5 Nested Functions................................ 16 4.6 Tail Recursion.................................. 18 5 First-Class Functions 21 5.1 Anonymous Functions............................. 22 5.2 Currying..................................... 23 5.3 Example: Finding Fixed Points of Functions................ 25 5.4 Summary..................................... 28 5.5 Language Elements Seen So Far....................... 28 6 Classes and Objects 31 7 Case Classes and Pattern Matching 43 7.1 Case Classes and Case Objects........................ 46 7.2 Pattern Matching................................ 47 8 Generic Types and Methods 51 8.1 Type Parameter Bounds............................ 53 8.2 Variance Annotations.............................. 56 iv CONTENTS 8.3 Lower Bounds.................................. 58 8.4 Least Types.................................... 58 8.5 Tuples....................................... 60 8.6 Functions.................................... 61 9 Lists 63 9.1 Using Lists.................................... 63 9.2 Definition of class List I: First Order Methods..............
    [Show full text]
  • HEDGEHOG: Automatic Verification of Design Patterns in Java
    HEDGEHOG: Automatic Verification of Design Patterns in Java Alex Blewitt I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy School of Informatics University of Edinburgh 2006 Abstract Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken. To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically. Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications. iii Acknowledgements I am indebted to Alan Bundy who has given me the freedom to work on this thesis whilst at the same time guiding me towards the final production and presentation of these results. I not would have been able to achieve this without Alan’s support through a sometimes difficult, but always busy part of my life. This project, and especially the production of this thesis, would not have been possible without the care and attention that Alan provided. Ian Stark has provided invaluable feedback on all aspects of this thesis, from the low-level technical intricacies of Java’s design patterns through to the high-level structure of the thesis as a whole.
    [Show full text]
  • A Survey of Design Pattern Based Web Applications
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2009 Vol. 8, No. 2, March-April 2009 A Survey of Design Pattern Based Web Applications Sridaran R, Campus Head, ICFAI National College, Vellore-632 006 India. Padmavathi G, Professor and Head, Department of Computer Science, Avinashilingam University for Women, Coimbatore-641 043, India. Iyakutti K, Senior Professor, School of Physics, Madurai Kamaraj University, Madurai-625 019, India. Abstract Pattern-based web applications have become popular since they promote reusability and consistency. In few cases, patterns do not produce the desired effect because of lack of experience in applying them. This situation forces one to think of a suitable re- engineering solution for such applications. The objectives of the paper are three fold. It provides a survey of different pattern-based web applications that will be useful for the application designers. It highlights some of the web applications where patterns have been inappropriately handled. A few re-engineering initiatives for such cases are also analyzed. Key Words: Patterns, Web Applications, Re-engineering, Hypermedia, Semantic web, Partitioning. 1 INTRODUCTION Web application designers need to address many challenges during development in order to comply the quality of service requirements including speed, scalability and security. In recent years numerous non-web based applications have been re-written as web based because of the ever growing business needs. These migration activities are much more complicated and time consuming than a new software development. Most of these challenges are with data handling, organizing, or structuring of the web applications.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]