Bringing OOP Best Practices to the World of Functional Programming

Total Page:16

File Type:pdf, Size:1020Kb

Bringing OOP Best Practices to the World of Functional Programming Bringing OOP Best Practices to the World of Functional Programming Elana Hashman Rackspace Managed Security Lambda Ladies DC – October 20!" #ehashdn DESIGN PATTERNS $unctional programming% Ob&ect-oriented programming% Programming Paradigms What is O !ect-Oriented Programming #OOP$% – (rogram logic is organized around objects, +hich store data as properties and algorithms ,or the data as methods – Objects are described by classes, +hich can inherit from one another – Common recipes/best practices are codified as design patterns Examples – C/+, 0a1a, C#, (ython Programming Paradigms What is Functional Programming (FP$% – Logic is codified and e1aluated as pure functions* a1oiding the mutation of state – Commonly characteri)ed by the use o, first-order functions* which can be passed around as arguments* and higher-order functions* which take functions as arguments E.amples – Lisp 3with 1arious dialects* such as Clo&ure4* Haskell, OCaml, $2 The fateful interview (Programming Tropes* + a.k.a. DESIGN PATTERNS 5hat is 6good code%7 68 can't tell you what bad code looks like, but I know it when I see it:7 " Anon.mous Programmer Don't Repeat Yourself (DR;4 Ya Ain't Gonna Need It 3;<=>84 eep It Simple, Senator 3?8SS4 (defn common-logic [data case-specific-logic] (case-specific-logic data) ...) (defn data1-specific-logic [args] ...) (defn data2-specific-logic [args] ...) (for [[data fn] data-and-fns] (common-logic data fn)) I. Di,,erent programming paradigms are not as di,,erent as you might think. II, Di,,erent programming paradigms do ha1e di,,erent design philosophies. 68t is better to ha1e ! functions operate on one data structure than 10 ,unctions on 10 data structures.7 " Alan /. Perlis III. >o paradigm is ob&ecti1ely 6better*” but each has ad1antages in certain situations: A common critique o, the 6Gang o, $our” !AAB Design Patterns book +as that many o, the patterns ser1ed as +orkarounds ,or language limitations o, C++. 8n !AAC, Peter >or1ig claims that !C o, the 23 patterns in the Gang of $our book are invisible or simplified in Lisp! <bstract $actory* Fly+eight* Factory Method* State* (roxy* Chain o, Responsibility → first"class t.)es Command* Strategy* Femplate* Visitor → first-class functions 8nterpreter* Iterator → macros Mediator* Observer → method combination Huilder → multimethods $açade → modules $unctional programming language ,eatures can reduce the need to use ,ully-implemented class-based design patterns. Some Notable FP 0anguage Features Immutabilit. What is it% – Data cannot change state a,ter its creation – $unctions cannot ha1e 6side e,,ects7 8mpro1es ability to reason about code Simpli,ies unit testing Discourages the use o, global mutable state, i.e. Singleton pattern First-1lass Functions What are the.% – $unctions can be passed as arguments – Lexical scoping allo+s ,or local bindings o, 1alues $urr%ing gi1es us ,unction $actories ((fn [a] (fn [b] (does-stuff a b))) “yo”) => (fn [b] (does-stuff “yo” b)) ; a := “yo” Freating ,unctions like +e treat data gi1es us programmable po+er o1er them 2acros and Pattern 2atching What are the.% – MacrosJ +e can write code to generate code – (attern Matching: match data according to patterns! Enables writing new grammar and e1aluating it +ith ease* i.e. Interpreter pattern Hre1ity means de1s can write more with less time, and the resulting code needs less maintenance (attern match e.ample.:: 2acros and Pattern 2atching (defn message-origin [message] (matc" [message] [#!parsed #!metadata #!customer-id-string $%%%] !type1 [#!parsed #!id $ !type $ !critical $ !message $%%] !type2 [#!parsed $%] !&son !else !syslog)) Some Examples of Design Patterns The Façade and Adapter Patterns What are the.% – Hide an e.isting A(8 by providing a new one on top The Façade and Adapter Patterns When to use them% – (ro1ide a unified or simplified inter,ace ,or other code – &echnical debt wrangling' standardize an inter,ace so you can re,actor the original code behind it When not to use them% – Foo many layers o, indirection from the original <PI can be ,ragile 5o' to use them with FP% – 0ust like you +ould in the OOP +orldE – 5rite modules +ith public ,unctions instead o, classes (defn yucky-API [hot dog other-infos] ...) (defn consumes-yucky-A)I [] (yucky-API true true #!"ot true :dog true :sundaes “???”%)) (defn nice-API “helpful docstring!” [other-infos] (let [{:keys [hot dog]} other-infos] (yuc'y-()* hot dog other-infos))) The Template Pattern What is it% – Defines the ma&ority o, an algorithm in an operation* de,erring some steps to subclasses The Template Pattern When to use it% – >early identical data and data operations – >eed to stub out a small amount of ,unctionality When not to use it% – Kse abstract base classes or similar very sparingly – 8n OOP land: pre,er composition o1er inheritance 5o' to use it with FP? – (ass in stub functions as arguments to common logic instead of implementing stubs on subclasses (defn common-logic [data case-specific-logic] (case-specific-logic data) ...) (defn data1-specific-logic [args] ...) (defn data2-specific-logic [args] ...) (for [[data fn] data-and-fns] (common-logic data fn)) The Strategy Pattern What is it% – Conditionally switch algorithms in a gi1en conte.t The Strategy Pattern When to use it% – Encapsulates dispatching many variants of a similar algorithm – $eature'flagged functionality When not to use it% – 5hen strategies fundamentally di,,er 3e:g: return type4 – <dds comple.ity and code branching 5o' to use it with FP? – (ass in algorithm 1ariants as first-order functions (defn strategy1 [args] ...) (defn strategy2 [args] ...) (apply-strategy-a [strategy1 strategy2]) (apply-strategy-b (fn [cond] (if cond strategy1 strategy2)) Summary 5e co1ered some Structural design patterns from – <dapter all three categoriesE – $aIade 1reational Beha&ioural – $actory – 8nterpreter – Singleton – Strategy – Femplate 1on!ecture: ;ou can use functional programming languages to write enterprise soft+are: Next time: Monads L Design patterns ,or statically typed languages% Thank you7 Fhanks to: Nik Black* Fatema Bo.+ala, Shane Wilton, Red Hat &alk links" references" and resources can be found at httpsJ--hashman.ca/osb'20!C- #ehashdn Talk References Erich Gamma* Richard Helm, Ralph Johnson, and 0ohn Vlissides* Design Patterns: Elements of Reusable Object-Oriented Software 3!AAB4 – Re,erred to as the “Gang o, Four7 (eter Norvig* “Design Patterns in Dynamic Languages7 (!AAC4 Image Licenses Pu lic Domain – Meta-KML Diagram – <dapter (attern KML Diagram – Strategy (attern KML Diagram 1reati&e 1ommons Share Alike 8,9 :n)orted 0icense – KML diagram of composition o1er inheritance – Femplate Method: KML Class Diagram – $acade Design (attern in KML .
Recommended publications
  • Ece351 Lab Manual
    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
    [Show full text]
  • JCP at Javapolis 2007
    Javapolis News ❙ 14 December 2007 ❙ Nr 5 ❙ Published by Minoc Business Press 54 www.nonillion.com Parleys Want to become a NONILLIONAIRE ? mail us at : [email protected] Building Rich Internet Applications with Flex and JavaFX “There’s a well thought out com- an online environment using Adobe AIR. “Even when you ponent model for Flex”, he said. are offl ine, you still can update data. When the connec- “And there’s a thriving market tion comes back on, the system synchronizes automati- for components out there, both cally.” Open Source and commercial. So there are literally hundreds JavaPolis founder Stephan Janssen was next to explain of components available to how he decided to have Parleys.com rewritten using Flex. use in Flex.” And no, Flex isn’t Parleys.com offers a massive amount of Java talks – from there for fun and games only. JavaPolis, JavaOne and other Java events from all over “There are already a great the world – combining video images with the actual pres- number of business applica- entation slides of the speakers. Janssen programmed the tions running today, all built application for fun at fi rst, but with over 10 TB of streamed with Flex.” Eckel backed up video in just under a year, it’s clear Parleys.com sort of his statement with an ex- started to lead its own life. “The decision to write a new ample of an interface for an version was made six months ago”, he said. “It was still intranet sales application. too early to use JavaFX. And Silverlight? No thanks.” “Some people think Flex Flex allowed him to leverage the Java code of the earlier isn’t the right choice to version of Parleys.com and to resolve the Web 2.0 and make for business applica- AJAX issues he had en- countered while programming tions, because the render- the fi rst version.
    [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]
  • Reversible Programming with Negative and Fractional Types
    9 A Computational Interpretation of Compact Closed Categories: Reversible Programming with Negative and Fractional Types CHAO-HONG CHEN, Indiana University, USA AMR SABRY, Indiana University, USA Compact closed categories include objects representing higher-order functions and are well-established as models of linear logic, concurrency, and quantum computing. We show that it is possible to construct such compact closed categories for conventional sum and product types by defining a dual to sum types, a negative type, and a dual to product types, a fractional type. Inspired by the categorical semantics, we define a sound operational semantics for negative and fractional types in which a negative type represents a computational effect that “reverses execution flow” and a fractional type represents a computational effect that“garbage collects” particular values or throws exceptions. Specifically, we extend a first-order reversible language of type isomorphisms with negative and fractional types, specify an operational semantics for each extension, and prove that each extension forms a compact closed category. We furthermore show that both operational semantics can be merged using the standard combination of backtracking and exceptions resulting in a smooth interoperability of negative and fractional types. We illustrate the expressiveness of this combination by writing a reversible SAT solver that uses back- tracking search along freshly allocated and de-allocated locations. The operational semantics, most of its meta-theoretic properties, and all examples are formalized in a supplementary Agda package. CCS Concepts: • Theory of computation → Type theory; Abstract machines; Operational semantics. Additional Key Words and Phrases: Abstract Machines, Duality of Computation, Higher-Order Reversible Programming, Termination Proofs, Type Isomorphisms ACM Reference Format: Chao-Hong Chen and Amr Sabry.
    [Show full text]
  • IP Log for Eclipse.Platform Release 4.0, July 2010 Licenses
    IP Log for eclipse.platform Release 4.0, July 2010 Licenses • Eclipse Public License v1.0 Third-Party Code CQ Third-Party Code License Use ICU4J (core and extended ICU4J License (X License, 1065 function) and ICU4J MIT Style) Replacement plug-in Version: 3.6 ICU4J License (X License, 1116 ICU4J Version: 3.4.5.20061213 MIT Style) 1153 JSch 0.1.31 Version: 0.1.31 New BSD license Apache Lucene Version: 1.9.1 243 (Core+Contrib Analyzers Apache License, 2.0 Analysis Src) 257 APT Version: 1 New BSD license Mozilla Public License 1.1 (MPL), MIT Style with No 262 Cairo Version: 1.0.2 Endorsement Clause, Historical Permissive Notice & Disclaimer ICU4J License (X License, 280 ICU4J Version: 3.4 MIT Style) ICU4J License (X License, 281 ICU4J Version: 3.4.3 MIT Style) 293 jsch Version: 0.1.28 New BSD license 308 PNG unload Version: 1 MIT license 1232 Apache Ant Version: 1.7.0 Apache License, 2.0 ICU4J and ICU4J Replacement ICU4J License (X License, 1367 Version: 3.6.1 MIT Style) Olsen time zone data Version: 1368 Public Domain 2007e Work derived from IJG JPEG 1596 IJG License Version: Release 6b,337 unmodified 1826 JSch 0.1.35 New BSD license source & binary ICU4J and ICU4J replacement MIT License with "no unmodified 1919 Version: 3.8.1 edorsement" clause source & binary unmodified 2014 jsch Version: 0.1.37 New BSD license source & binary XHTML DTDs Version: unmodified 2044 W3C Document License Versions 1.0 and 1.1 (PB CQ331) source org.apache.ant Version: 1.6.5 2404 (ATO CQ1013) (using Orbit Apache License, 2.0 CQ2209) org.apache.lucene Version: 1.4.3 2405 (Core Source Only) (ATO Apache License, 2.0 CQ1014) (using Orbit CQ2210) Junit Version: 3.8.2 (ATO 2406 Common Public License 1.0 CQ299) (using Orbit CQ2206) Historical support for Java SSH modified 2410 Applet + Blowfish Version - v.
    [Show full text]
  • Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel
    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel Kelt Dockins [email protected] Design Patterns in PHP and Laravel Kelt Dockins Dolph, Arkansas USA ISBN-13 (pbk): 978-1-4842-2450-2 ISBN-13 (electronic): 978-1-4842-2451-9 DOI 10.1007/978-1-4842-2451-9 Library of Congress Control Number: 2016961807 Copyright © 2017 by Kelt Dockins This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Process Synchronisation Background (1)
    Process Synchronisation Background (1) Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes Producer Consumer Background (2) Race condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count- - could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with ―count = 5‖ initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} Solution: ensure that only one process at a time can manipulate variable count Avoid interference between changes Critical Section Problem Critical section: a segment of code in which a process may be changing Process structure common variables ◦ Only one process is allowed to be executing in its critical section at any moment in time Critical section problem: design a protocol for process cooperation Requirements for a solution ◦ Mutual exclusion ◦ Progress ◦ Bounded waiting No assumption can be made about the relative speed of processes Handling critical sections in OS ◦ Pre-emptive kernels (real-time programming, more responsive) Linux from 2.6, Solaris, IRIX ◦ Non-pre-emptive kernels (free from race conditions) Windows XP, Windows 2000, traditional UNIX kernel, Linux prior 2.6 Peterson’s Solution Two process solution Process Pi ◦ Mutual exclusion is preserved? ◦ The progress requirements is satisfied? ◦ The bounded-waiting requirement is met? Assumption: LOAD and STORE instructions are atomic, i.e.
    [Show full text]
  • APPLYING MODEL-VIEW-CONTROLLER (MVC) in DESIGN and DEVELOPMENT of INFORMATION SYSTEMS an Example of Smart Assistive Script Breakdown in an E-Business Application
    APPLYING MODEL-VIEW-CONTROLLER (MVC) IN DESIGN AND DEVELOPMENT OF INFORMATION SYSTEMS An Example of Smart Assistive Script Breakdown in an e-Business Application Andreas Holzinger, Karl Heinz Struggl Institute of Information Systems and Computer Media (IICM), TU Graz, Graz, Austria Matjaž Debevc Faculty of Electrical Engineering and Computer Science, University of Maribor, Maribor, Slovenia Keywords: Information Systems, Software Design Patterns, Model-view-controller (MVC), Script Breakdown, Film Production. Abstract: Information systems are supporting professionals in all areas of e-Business. In this paper we concentrate on our experiences in the design and development of information systems for the use in film production processes. Professionals working in this area are neither computer experts, nor interested in spending much time for information systems. Consequently, to provide a useful, useable and enjoyable application the system must be extremely suited to the requirements and demands of those professionals. One of the most important tasks at the beginning of a film production is to break down the movie script into its elements and aspects, and create a solid estimate of production costs based on the resulting breakdown data. Several film production software applications provide interfaces to support this task. However, most attempts suffer from numerous usability deficiencies. As a result, many film producers still use script printouts and textmarkers to highlight script elements, and transfer the data manually into their film management software. This paper presents a novel approach for unobtrusive and efficient script breakdown using a new way of breaking down text into its relevant elements. We demonstrate how the implementation of this interface benefits from employing the Model-View-Controller (MVC) as underlying software design paradigm in terms of both software development confidence and user satisfaction.
    [Show full text]
  • Dependency Injection in Unity3d
    Dependency Injection in Unity3D Niko Parviainen Bachelor’s thesis March 2017 Technology, communication and transport Degree Programme in Software Engineering Description Author(s) Type of publication Date Parviainen, Niko Bachelor’s thesis March 2017 Language of publication: English Number of pages Permission for web publi- 57 cation: x Title of publication Dependency Injection in Unity3D Degree programme Degree Programme in Software Engineering Supervisor(s) Rantala, Ari Hämäläinen, Raija Assigned by Psyon Games Oy Abstract The objective was to find out how software design patterns and principles are applied to game development to achieve modular design. The tasks of the research were to identify the dependency management problem of a modular design, find out what the solutions offered by Unity3D are, find out what the dependency injection pattern is and how it is used in Unity3D environment. Dependency management in Unity3D and the dependency injection pattern were studied. Problems created by Unity3D’s solutions were introduced with examples. Dependency in- jection pattern was introduced with examples and demonstrated by implementing an ex- ample game using one of the available third-party frameworks. The aim of the example game was to clarify if the use of dependency injection brings modularity in Unity3D envi- ronment and what the cost of using it is. The principles of SOLID were introduced with generic examples and used to assist depend- ency injection to further increase the modularity by bringing the focus on class design. Dependency injection with the help of SOLID principles increased the modularity by loosely coupling classes even though slightly increasing the overall complexity of the architecture.
    [Show full text]
  • Let's Get Functional
    5 LET’S GET FUNCTIONAL I’ve mentioned several times that F# is a functional language, but as you’ve learned from previous chapters you can build rich applications in F# without using any functional techniques. Does that mean that F# isn’t really a functional language? No. F# is a general-purpose, multi paradigm language that allows you to program in the style most suited to your task. It is considered a functional-first lan- guage, meaning that its constructs encourage a functional style. In other words, when developing in F# you should favor functional approaches whenever possible and switch to other styles as appropriate. In this chapter, we’ll see what functional programming really is and how functions in F# differ from those in other languages. Once we’ve estab- lished that foundation, we’ll explore several data types commonly used with functional programming and take a brief side trip into lazy evaluation. The Book of F# © 2014 by Dave Fancher What Is Functional Programming? Functional programming takes a fundamentally different approach toward developing software than object-oriented programming. While object-oriented programming is primarily concerned with managing an ever-changing system state, functional programming emphasizes immutability and the application of deterministic functions. This difference drastically changes the way you build software, because in object-oriented programming you’re mostly concerned with defining classes (or structs), whereas in functional programming your focus is on defining functions with particular emphasis on their input and output. F# is an impure functional language where data is immutable by default, though you can still define mutable data or cause other side effects in your functions.
    [Show full text]
  • Evil Pickles: Dos Attacks Based on Object-Graph Engineering∗
    Evil Pickles: DoS Attacks Based on Object-Graph Engineering∗ Jens Dietrich1, Kamil Jezek2, Shawn Rasheed3, Amjed Tahir4, and Alex Potanin5 1 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 2 NTIS – New Technologies for the Information Society Faculty of Applied Sciences, University of West Bohemia Pilsen, Czech Republic [email protected] 3 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 4 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 5 School of Engineering and Computer Science Victoria University of Wellington, Wellington, New Zealand [email protected] Abstract In recent years, multiple vulnerabilities exploiting the serialisation APIs of various programming languages, including Java, have been discovered. These vulnerabilities can be used to devise in- jection attacks, exploiting the presence of dynamic programming language features like reflection or dynamic proxies. In this paper, we investigate a new type of serialisation-related vulnerabilit- ies for Java that exploit the topology of object graphs constructed from classes of the standard library in a way that deserialisation leads to resource exhaustion, facilitating denial of service attacks. We analyse three such vulnerabilities that can be exploited to exhaust stack memory, heap memory and CPU time. We discuss the language and library design features that enable these vulnerabilities, and investigate whether these vulnerabilities can be ported to C#, Java- Script and Ruby. We present two case studies that demonstrate how the vulnerabilities can be used in attacks on two widely used servers, Jenkins deployed on Tomcat and JBoss.
    [Show full text]
  • Facet: a Pattern for Dynamic Interfaces
    Facet: A pattern for dynamic interfaces Author: Eric Crahen SUNY at Buffalo CSE Department Amherst, NY 14260 201 Bell Hall 716-645-3180 <[email protected]> Context: Wherever it is desirable to create a context sensitive interface in order to modify or control the apparent behavior if an object. Problem: How can I modify the behavior of an existing object so that different behaviors are shown under different circumstances; and yet still maintain a clean separation between the policy (when each behavior is available) and implementation of each behavior allowing them to be developed independently of one another? Forces: Interfaces provide an essential level of abstraction to object oriented programming. Generally, objects are able define aspects of their function very well using interfaces. At times, this may not be enough. When dealing with two or more classes whose responsibilities are distinctly separate, but whose behavior is closely related, classes can begin to resist modularization. For example, adding security to an application means inserting code that performs security checks into numerous locations in existing classes. Clearly, these responsibilities are distinct; the original classes being responsible for the tasks they were designed to perform, and the security classes being responsible for providing access control. However, making those original classes secure means intermingling code that deals with security. When the classes dealing with security are changed many classes are going to be impacted. One method of adding new behavior to an existing class might be to simply create a subclass and embed that new behavior. In the security example, this would mean creating a subclass for each class that needs to be secure and adding calls to the security code.
    [Show full text]