DOCSLIB.ORG

Component Design Recall: Problem with Subclassing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

the

gamedesigninitiative

at cornell university

Lecture 8

Component Design

Recall: Problem with Subclassing

—ꢀ Games have lots of classes

—ꢀ Each game entity is different

NPC

—ꢀ Needs its own functionality
(e.g. object methods)

  • Human
  • Orc

—ꢀ Want to avoid redundancies

—ꢀ Makes code hard to change —ꢀ Common source of bugs

Human Warrior
Human Archer

  • Orc
  • Orc

  • Archer
  • Warrior

—ꢀ Might be tempted to subclass

—ꢀ Common behavior in parents —ꢀ Specific behavior in children

Redundant Behavior

the

gamedesigninitiative

Architecture Patterns

2

at cornell university

Recall: Problem with Subclassing

—ꢀ Games have lots of classes

—ꢀ Each game entity is different

NPC

—ꢀ Needs its own functionality
(e.g. object methods)

  • Warrior
  • Archer

—ꢀ Want to avoid redundancies

—ꢀ Makes code hard to change —ꢀ Common source of bugs

Human Warrior

  • Orc
  • Human

Archer
Orc

  • Warrior
  • Archer

—ꢀ Might be tempted to subclass

—ꢀ Common behavior in parents —ꢀ Specific behavior in children

Redundant Behavior

the

gamedesigninitiative

Architecture Patterns

3

at cornell university

Alternative: Decorator Pattern

New
Functionality

Original Object

Reference to Original

base object
Functionality

Decorator
Object

Request

the

gamedesigninitiative

Architecture Patterns

4

at cornell university

Alternate: Delegation Pattern

Original Object

Reference to

Delegate

Request delegate

Object

Forward Request

Inversion of the Decorator Pattern

the

gamedesigninitiative

Architecture Patterns

5

at cornell university

Issues with Static Typing

Method in original class
Original

object class

obj.request(arg1,…, argn)ꢀ

Original Object

Reference to delegate

Delegate
Object

Request
Forward Request

the

gamedesigninitiative

Architecture Patterns

6

at cornell university

The Subclass Problem Revisited

Delegates?

NPC
Orc

Slot Slot Slot

Human

  • Human
  • Orc

NPC

Warrior

Archer
Human Warrior
Human Archer

  • Orc
  • Orc

  • Archer
  • Warrior

Redundant Behavior

the

gamedesigninitiative

Architecture Patterns

7

at cornell university

Component-Based Programming

Delegates

—ꢀ Role: Set of capabilities

Role 1

—ꢀ Class with very little data —ꢀ A collection of methods

Slot

Role 2

—ꢀ Add it to object as delegate

Slot

Entity

—ꢀ Object gains those methods

Role 3 Role 4

Slot

—ꢀ Acts as a “function pointer”

—ꢀ Can-it: search object roles

—ꢀ Check class of each role —ꢀ Better than duck typing —ꢀ Possible at compile time?

Field storing a single delegate or

a set of delegates

the

gamedesigninitiative

Architecture Patterns

8

at cornell university

Aside: Objective-C

—ꢀDelegates are emphasized in Objective-C

—ꢀ ObjC protocols function like Java interfaces —ꢀ But implement with a delegate, not a subclass

—ꢀOften leverages message passing

—ꢀ Method call is considered a message —ꢀ Can call any method on any object —ꢀ Will get runtime error if method not supported —ꢀ Heavily optimized in latest Apple compilers

the

gamedesigninitiative

Architecture Patterns

9

at cornell university

Aside: Objective-C

—ꢀDelegates are emphasized in Objective-C

—ꢀ ObjC protocols function like Java interfaces —ꢀ But implement with a delegate, not a subclass

—ꢀOften leverages message passing

—ꢀ Method call is considered a message —ꢀ Can call any method on any object —ꢀ Will get runtime error if method not supported —ꢀ Heavily optimized in latest Apple compilers

the

gamedesigninitiative

Architecture Patterns

10

at cornell university

Working With Static Typing

  • Uniform Method
  • Direct Access

ꢀ

if (o has role) {ꢀ o.doSomething(kitchenSink)ꢀ

extract role from oꢀ role.doSomething(info)ꢀ

}ꢀ

the

gamedesigninitiative

Architecture Patterns

11

at cornell university

Working With Static Typing

  • Uniform Method
  • Direct Access

ꢀ

if (o has role) {ꢀ o.doSomething(kitchenSink)ꢀ

extract role from oꢀ role.doSomething(info)ꢀ

}ꢀ

Problem:

Multiple capabilities

the

gamedesigninitiative

Architecture Patterns

12

at cornell university

Working With Static Typing

  • Uniform Method
  • Direct Access

ꢀ

if (o has role) {ꢀ o.doSomething(kitchenSink)ꢀ

extract role from oꢀ role.doSomething(info)ꢀ

}ꢀ

Problem:

Problem:

Big switch statements
Multiple capabilities

the

gamedesigninitiative

Architecture Patterns

13

at cornell university

Entities Need Both Is-a and Can-it ꢀ

  • Table
  • Chair

Objects share same capabilities in theory. But certain actions are preferred on each.

the

gamedesigninitiative

Architecture Patterns

14

at cornell university

Solving the Problem

  • Can-It
  • Is-A

—ꢀ Indicated by object roles

—ꢀ Component indicates role —ꢀ Check type of each role —ꢀ So again a typing solution

—ꢀ Indicated by object class

—ꢀ But could do more than that

—ꢀ Keep a bag of types

—ꢀ Contains of the descriptions that apply to this object

—ꢀ “Formal duck typing”

—ꢀ Example: table, heirloom

—ꢀ Not limited to method name —ꢀ Role type indicates action

—ꢀ Why would we do this?

name, not a noun

the

gamedesigninitiative

Architecture Patterns

15

at cornell university

Fast Can-It Testing: Bit Vectors

—ꢀGive each object a bit-vector to cover types

—ꢀ Each role is a position in the bit vector

—ꢀ Example:

0100101ꢀ

the

gamedesigninitiative

Architecture Patterns

16

at cornell university

Fast Can-It Testing: Bit Vectors

—ꢀGive each object a bit-vector to cover types

—ꢀ Each role is a position in the bit vector

—ꢀ Example:

0100101ꢀ

Can Build

  • Can Fight
  • Can Heal

—ꢀ Use array if more than 32/64 roles

the

gamedesigninitiative

Architecture Patterns

17

at cornell university

Fast Can-It Testing: Bit Vectors

—ꢀGive each object a bit-vector to cover types

—ꢀ Each role is a position in the bit vector

—ꢀ Example:

0100101ꢀ

Can Build

  • Can Fight
  • Can Heal

—ꢀ Use array if more than 32/64 roles

—ꢀTest is quick logical operation.

—ꢀ Example: vector & CAN_FIGHTꢀ

—ꢀ Faster than dynamic typing (why?)

the

gamedesigninitiative

Architecture Patterns

18

at cornell university

Model-Controller Separation Revisited

  • Model
  • Controller

—ꢀ Store/retrieve object data —ꢀ Process interactions

—ꢀ Preserve any invariants —ꢀ Data may include delegates —ꢀ Determines is-a properties
—ꢀ Look at current game state —ꢀ Look for “triggering” event —ꢀ Apply interaction outcome

Components

  • ?
  • ?

—ꢀ Process game actions

—ꢀ Attached to a entity (model) —ꢀ Uses the model as context —ꢀ DeterAmrcihniteecsturceaPnat-tietrnps roperties

the

gamedesigninitiative

19

at cornell university

Model-Controller Separation Revisited

  • Model
  • Controller

—ꢀ Store/retrieve object data —ꢀ Process interactions

—ꢀ Preserve any invariants —ꢀ Data may include delegates —ꢀ Determines is-a properties
—ꢀ Look at current game state —ꢀ Look for “triggering” event —ꢀ Apply interaction outcome

Components

Is this always the best idea?

  • ?
  • ?

—ꢀ Process game actions

—ꢀ Attached to a entity (model) —ꢀ Uses the model as context —ꢀ DeterAmrcihniteecsturceaPnat-tietrnps roperties

the

gamedesigninitiative

20

at cornell university

Recall: Lab 3 in CS 3152

the

gamedesigninitiative

Architecture Patterns

21

at cornell university

Processing Actions in Lab 3

GameplayController.cs
Ship.cs

  • —ꢀ Decides whether to shoot
  • —ꢀ Waits until objects commit

—ꢀ Checks intent in Ship object —ꢀ Performs action for intent
—ꢀ Stores intent in the object

—ꢀ But DOES NOT shoot

the

gamedesigninitiative

Game Architecture

22

at cornell university

Processing Actions in Lab 3

GameplayController.cs

Attach components to controller?

Ship.cs

  • —ꢀ Decides whether to shoot
  • —ꢀ Waits until objects commit

—ꢀ Checks intent in Ship object —ꢀ Performs action for intent
—ꢀ Stores intent in the object

—ꢀ But DOES NOT shoot

the

gamedesigninitiative

Game Architecture

23

at cornell university

Related: Handling the View

—ꢀ Way too much to draw

—ꢀ Backgrounds —ꢀ UI elements

Update Draw

—ꢀ Individual NPCs —ꢀ Other moveable objects

—ꢀ Cannot cram all in Draw —ꢀ Put it in game object?

—ꢀ But objects are models

—ꢀ Violates MVC again

the

gamedesigninitiative

Architecture Patterns

24

at cornell university

First Attempt: A Drawing Canvas

—ꢀ Treat display as a container

—ꢀ Often called a canvas —ꢀ Cleared at start of frame —ꢀ Objects added to container —ꢀ Draw contents at frame end

Passed as reference

—ꢀ Canvas abstracts rendering

—ꢀ Hides animation details

void draw(Canvas c) {ꢀ

// Specify perspectiveꢀ // Add to canvas

}ꢀ

—ꢀ Like working with widget

—ꢀ Implement draw(c) in model

—ꢀ Classic heavyweight model —ꢀ No problems with extension

the

gamedesigninitiative

Architecture Patterns

25

at cornell university

Problem: Canvas Methods

Ideal

Model1

draw(canvas)ꢀ

Canvas

drawShape(…)ꢀ

Model2

draw(canvas)ꢀ

the

gamedesigninitiative

Architecture Patterns

26

at cornell university

Problem: Canvas Methods

In Practice

Model1

draw(canvas)ꢀ

Canvas

drawShape1(…)ꢀ drawShape2(…)ꢀ

Model2

draw(canvas)ꢀ

the

gamedesigninitiative

Architecture Patterns

27

at cornell university

Views and Components

Slot

Component1ꢀ

drawShape1(…)ꢀ

Slot Slot

Model1 Model2

Canvas

drawPrimitive(…)ꢀ

Slot Slot Slot

Component1ꢀ

drawShape1(…)ꢀ

the

gamedesigninitiative

Architecture Patterns

28

at cornell university

Views and Components

Primitive effects

Slot

Component1ꢀ

Slot

Model1

drawShape1(…)ꢀ

Slot

Complex,
Shape-specific rendering

Slot

Canvas

drawPrimitive(…)ꢀ

Component1ꢀ

drawShape1(…)ꢀ

Slot

Model2

Slot

the

gamedesigninitiative

Architecture Patterns

29

at cornell university

Components and AI

Alert!

—ꢀ NPCs use sense-think-act cycle

—ꢀ Sense: perceive the world —ꢀ Think: choose an action —ꢀ Act: update the game state

—ꢀ Act is stored in components

—ꢀ Capabilities given by roles

—ꢀ Where are sense and think?

Yes

—ꢀ In the component/role?

This is hard

—ꢀ How do roles interact?

the

gamedesigninitiative

Game Architecture

30

at cornell university

Recommended publications
  • Game Architecture Revisited Recall: the Game Loop

    Game Architecture Revisited Recall: the Game Loop

    the gamedesigninitiative at cornell university Lecture 8 Game Architecture Revisited Recall: The Game Loop Receive player input Process player actions Update 60 times/s Process NPC actions Interactions (e.g. physics) = 16.7 ms Cull non-visible objects Transform visible objects Draw Draw to backing buffer Display backing buffer the gamedesigninitiative 2 Architecture Revisited at cornell university The Game Loop Receive player input Process player actions Update Process NPC actions Interactions (e.g. physics) Almost everything is in loop Draw Except asynchronous actions Is enough for simple games How do we organize this loop? Do not want spaghetti code Distribute over programmers the gamedesigninitiative 3 Architecture Revisited at cornell university Model-View-Controller Pattern Controller Calls the • Updates model in methods of response to events • Updates view with model changes Model View • Defines/manages • Displays model the program data to the user/player • Responds to the • Provides interface controller requests for the controller the gamedesigninitiative 4 Architecture Revisited at cornell university The Game Loop and MVC Model: The game state Value of game resources Location of game objects Update View: The draw phase Rendering commands only Major computation in update Draw Controller: The update phase Alters the game state Vast majority of your code the gamedesigninitiative 5 Architecture Revisited at cornell university Application Structure Root Controller Ownership Subcontroller Subcontroller View Model Model
  • Design Specification for Delegation and Incentives in Cardano

    Design Specification for Delegation and Incentives in Cardano

    Engineering Design Specification for Delegation and Incentives in Cardano–Shelley AN IOHK TECHNICAL REPORT Philipp Kant Lars Brunjes¨ Duncan Coutts [email protected] [email protected] [email protected] [email protected] April 11, 2019 Abstract This document describes the requirements and design for a delegation and incentives mechanism to be used in the Shelley release of Cardano. List of Contributors Lars Brunjes,¨ Jared Corduan, Duncan Coutts, Philipp Kant, Dimitris Karakostas, Aggelos Kiayias, Elias Koutsoupias, Mario Larangeira, Damian Nadales, Aikaterini-Panagiota Stouka. Contents 1 Purpose 4 2 Requirements 5 2.1 Functional Requirements . .5 2.1.1 Proof of Eligibility . .5 2.1.2 Visibility of Delegation on the Blockchain . .5 2.1.3 Restricting Chain Delegation . .5 2.1.4 Cheap Re-Delegation . .5 2.1.5 Neutral Addresses . .5 2.2 Security Requirements . .6 2.2.1 Sybil Attack Protection at Stake Pool Level . .6 2.2.2 Address Non-malleability . .6 2.2.3 Public Spending Keys Should not be Disclosed Prematurely . .6 2.2.4 Mitigate Key Exposure . .6 2.2.5 Handle Inactive Stake Pools . .6 2.2.6 Avoid Hard Transition . .6 2.2.7 Change Delegation Without Spending Key . .7 2.3 Non-functional Requirements . .7 2.3.1 Asymptotic space and time complexity . .7 2.3.2 Minimise economic attacks . .7 2.4 Requirements to Preserve Existing Features . .7 2.4.1 Master Recovery Key . .7 1 2.4.2 Address Recognition . .7 2.4.3 Wallet should be Runnable on Independent Devices . .7 2.4.4 Maintain Privacy .
  • Title: Foundation Patterns Authors: Dwight Deugo E-Mail: Deugo@Scs

    Title: Foundation Patterns Authors: Dwight Deugo E-Mail: Deugo@Scs

    Title: Foundation Patterns Authors: Dwight Deugo E-mail: [email protected] Address: School of Computer Science Carleton University 1125 Colonel By Drive Ottawa, Ontario, Canada, K1S 5B6 Telephone: (613) 520-2600 ext. 8438 (613) 520-4333 Fax: (613) 520-4334 Abstract: Many patterns depended on one important distinction: the distinction between an object's class and its type. For example, many patterns rely on interface inheritance, although, on examining their structures, most are described using implementation inheritance. The making of this implicit distinction gives evidence that there are patterns, fundamental to many, that live within other patterns and are at the foundation of good object-oriented principles. I give these patterns the name foundation patterns. I discuss two such foundation patterns: delegation and substitution, separating the two into their rightful positions, making clear what each patterns' role is in object-oriented design. Foundation Patterns Dwight Deugo [email protected] School of Computer Science Carleton University Introduction Although not mentioned, many patterns depend on one important distinction. This is the distinction between an object's class and its type. Stated another way, these patterns rely on interface inheritance rather than on implementation inheritance. Nevertheless, on examining their structures, most pattern descriptions use implementation inheritance. This is not surprising, since languages like Smalltalk and C++ do not explicitly support the notion of a type or a subtype within the language. Java is the exception to this, directly supporting interfaces and their inheritance, bringing attention to these well deserving topics. The making of this implicit distinction gives evidence that there are other patterns, fundamental to many, if not all patterns, which are either assumed and undocumented or still waiting to be discovered.
  • Enabling White-Box Reuse in a Pure Composition Language

    Enabling White-Box Reuse in a Pure Composition Language

    Enabling White-Box Reuse in a Pure Composition Language Diplomarbeit der Philosophisch-naturwissenschaftlichen Fakultat¨ der Universitat¨ Bern vorgelegt von Andreas Schlapbach Dezember 2002 Leiter der Arbeit: Prof. Dr. O. Nierstrasz Nathanael Scharli¨ Institut fur¨ Informatik und angewandte Mathematik i Abstract Inheritance is a key concept of object-oriented programming languages, features such as conceptual modeling and reusability are largely accredited to it. While many useful com- ponents have been, and will be, developed in this paradigm, the form of white-box reuse offered by inheritance has a fundamental flaw: reusing components by inheritance requires an understanding of the internals of the components. We can not treat components of object-oriented languages as black-box entities, inheritance breaks encapsulation and in- troduces subtle dependencies between base and extending classes. Component-oriented programming addresses this problem by shifting away from program- ming towards software composition. We build applications by scripting components. In- stead of overriding the internals of a component, we focus on composing its interfaces only. This form of black-box reuse leads to a flexible and extendible architecture with reusable components. In this master's thesis we propose a migration strategy from class inheritance { a white- box form of reuse { to component composition as a black-box form of reuse. We present a language extension that gives us the power of inheritance combined with the ease of scripting. It enables us to reuse Java components using inheritance in JPiccola { a small, pure and general composition language implemented on the Java platform { at a high level of abstraction. Using the services provided by the language extension we can seamlessly generate interfaces and subclasses from JPiccola.
  • Workflow Patterns in Bindflow

    Workflow Patterns in Bindflow

    Workflow Patterns implemented in BindFlow™ Jason Kleban BindFlow LLC Portions of the software described in this document are covered by U.S. Patent No. 8,051,427. Abstract We present an operating environment, called BindFlow™, and a companion program structure well suited for workflow programs which automate portions of real-world business processes. The flowchart logic of most business processes can be authored concisely using traditional programming techniques; however, the extended delays, overlapped execution, and hardware constraints in practical workflow scenarios severely complicate programs. We examine workflow programs as a mix of nondeterministic operations and deterministic transformations. Isolating a process’s deterministic transformations from its nondeterministic operations allows us to record every input into the process. Instances can be safely unloaded from memory, destroying state, because the record of the inputs is all that is required to rebuild the logical state of a process instance on demand. We introduce the BindFlow model and explore its ability to express the workflow patterns that have been recognized in the research by van der Aalst, Russell, ter Hofstede, et al., documented at http://www.workflowpatterns.com. 2 Pattern Implementation Quick Reference Control-Flow 20 Cancellation and Force Completion 53 Cancel Task 53 Basic 20 Cancel Case 54 Sequence 20 Cancel Region 55 Parallel Split 21 Cancel Multiple Instance Activity 56 Synchronization 22 Complete Multiple Instance Activity 57 Exclusive Choice 23 Iteration
  • Contents Credits & Contacts

    Contents Credits & Contacts

    overload issue 68 august 2005 contents credits & contacts C++ Interface Classes - Noise Reduction Mark Radford 6 Overload Editor: Alan Griffiths [email protected] A Technique for Register Access in C++ [email protected] Pete Goodliffe 9 Contributing Editor: Mark Radford Investigating Java Class Loading [email protected] Roger Orr 14 Advisors: Software Project Management: Phil Bass Stakeholder Metrics to Agile [email protected] Projects Thaddaeus Frogley Tom Gilb 18 [email protected] Richard Blundell C-side Re-sort [email protected] Kevlin Henney 22 Pippa Hennessy [email protected] Advertising: Thaddaeus Frogley [email protected] Overload is a publication of the ACCU. For details of the ACCU and other ACCU publications and activities, see the ACCU website. ACCU Website: http://www.accu.org/ Information and Membership: Join on the website or contact David Hodge [email protected] Publications Officer: John Merrells [email protected] ACCU Chair: Ewan Milne [email protected] 3 overload issue 68 august 2005 Editorial: Size Does Matter he way that one goes about developing and delivering a software project depends critically on the scale of the project. There is no “one size fits all” Tapproach. As a trivial example to illustrate this, no one would consider writing a test harness for a “hello world” program. (Actually, I have tried this question out on some TDD proponents over the last year - and I have only found one that insists that they would do so.) Why shouldn’t one write a test harness for “hello world”? As in is an important decision and may need revision as a project all design questions it is a matter of trade-offs: there is a cost to progresses.
  • Migrating Large Object-Oriented Applications Into Component-Based Ones Instantiation and Inheritance Transformation

    Migrating Large Object-Oriented Applications Into Component-Based Ones Instantiation and Inheritance Transformation

    GPCE’15 Migrating Large Object-oriented Applications into Component-based ones Instantiation and Inheritance Transformation Zakarea Alshara Abdelhak-Djamel Seriai Chouki Tibermacine Hinde Lilia Bouziane Christophe Dony Anas Shatnawi LIRMM, CNRS and University of Montpellier, France falshara, seriai, tibermacin, bouziane, dony, [email protected] Abstract architecture views, and it is easy to reuse their coarse-grained en- Large object-oriented applications have complex and numerous de- tities [5, 9]. Thus migrating these OO applications to CB ones pendencies, and usually do not have explicit software architectures. contributes to improve their maintainability, in addition to their Therefore they are hard to maintain, and parts of them are difficult reusability by feeding existing component repositories [12]. to reuse. Component-based development paradigm emerged for im- The migration process is composed of two main steps [1]: the proving these aspects and for supporting effective maintainability first step is CB architecture recovery where components and their and reuse. It provides better understandability through a high-level dependencies are identified. The second step is code transformation architecture view of the application. Thereby migrating object- where OO code is transformed into equivalent CB one. oriented applications to component-based ones will contribute to The step of CB architecture recovery was largely treated in the improve these characteristics (maintainability and reuse). In this literature [2–4, 7, 9]. Most of these works aim to identify compo- paper, we propose an approach to automatically transform object- nents as clusters of classes. They use clustering algorithms, among oriented applications to component-based ones. More particularly, other techniques, aiming at maximizing intra-component cohesion the input of the approach is the result provided by software ar- and minimize inter-component coupling to identify the architec- chitecture recovery: a component-based architecture description.
  • Ios Design Patterns

    Ios Design Patterns

    iOS Design Patterns Jackie Myrose CSCI 5448 Fall 2012 Design Patterns A design pattern is a common solution to a software problem They are helpful for speeding up problem solving, ensuring that a developer doesn’t have to re-invent the wheel for every situation They also give developers a common vocabulary with which to get across high-level ideas with minimal explanation and full understanding Why iOS? Design patterns are everywhere in iOS Because iOS is a fairly specific platform, developers often face similar problems over and over, so there are a few design patterns that are extremely common in iOS In this presentation Singleton Delegate Model View Controller Observer Façade Command Template Method Singleton The singleton pattern is very simple but extremely powerful It is a very common pattern, but developers have to be careful not to overuse it Because abuse of the singleton pattern is common, some developers avoid the pattern altogether Singleton When a class is restricted to just one instantiation, that one object is called a singleton In some situations it can be problematic to have two instances of a class running, this should be the only reason to use the singleton pattern The next slide contains a basic example of creating a singleton in objective-c, however keep in mind that this code is not thread safe Singleton - code +(ExClass *) singleton{! " "static ExClass *sharedInstance = nil;! " "! " "if ( sharedInstance == nil){! " " "sharedInstance = [[ExClass alloc] init];! " "}! " "return sharedInstance;! }!
  • Applying Software Design Pattern on Ios Application

    Applying Software Design Pattern on Ios Application

    Mohammad Abdullah Atik Applying Software Design Pattern on iOS Application A case study Finnkino Helsinki Metropolia University of Applied Sciences Bachelor of Engineering Information Technology Bachelor’s Thesis 3 November 2014 Abstract Author(s) Mohammad Abdullah Atik Title Applying Software Design Pattern on iOS Application Number of Pages 31 pages Date 3 November 2014 Degree Bachelor of Engineering Degree Programme Information Technology Specialisation option Software Engineering Instructor(s) Peter Hjort, Senior Lecturer Software developers practice software design patterns and principles to solve commonly occurring problems while ensuring extensible robust and maintainable system. The thesis aimed to study a subset of software patterns and principles. The practical goal of the thesis was to develop an iOS application with proper patterns applied. The main focus was to recognize which pattern would suit for an application’s various design challenges and what benefits would be harnessed by it. The study aimed to answer two questions: how a pattern needed to solve the problem was recognized and what were the consequences of applying the pattern. An action research method was followed for this project. It involved design, analysis and implementation phase for developing the application. Xcode IDE was used as the development environment to implement the practical task. Application usability testing and profiling were done with Instrument tools which are part of the IDE. Debugging and compiling were done with Apple’s new tool LLVM (Low Level Virtual Machine). The result of the practical task is an iOS application named Finnkino which allows searching and viewing movie information in nearby theatres within Finland. In addition it also shows current, upcoming and top movies around the globe.
  • Javascript Patterns

    Javascript Patterns

    JavaScript Patterns JavaScript Patterns Stoyan Stefanov Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo JavaScript Patterns by Stoyan Stefanov Copyright © 2010 Yahoo!, Inc.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary Treseler Indexer: Potomac Indexing, LLC Production Editor: Teresa Elsey Cover Designer: Karen Montgomery Copyeditor: ContentWorks, Inc. Interior Designer: David Futato Proofreader: Teresa Elsey Illustrator: Robert Romano Printing History: September 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. JavaScript Patterns, the image of a European partridge, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. ISBN: 978-0-596-80675-0 [SB] 1284038177 To my girls: Eva, Zlatina, and Nathalie Table of Contents Preface . ................................................................... xiii 1. Introduction .
  • Amity School of Engineering & Technology Amity

    Amity School of Engineering & Technology Amity

    Amity School of Engineering & Technology Amity University Object Oriented System Design Code: CSE416 Prepared By Hari Mohan Pandey Assistant Professor, CSE Department [email protected] Module Notes Department of Computer Science & Engineering ODD Semester 2014 Object Oriented System Design Page: 1/74 UNIT-3 DIAGRAMS 3.1 Sequence diagrams A sequence diagram is an interaction diagram that details how operations are carried out - - what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window. Figure: Sequence Diagram-1 Object Oriented System Design Page: 2/74 The Reservation window sends a makeReservation () message to a HotelChain. The HotelChain then sends a makeReservation () message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation. Within a sequence diagram, on object is available in the box at the top of a dotted vertical line. Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message. Each message is labeled at minimum with the message name. In our diagram, the Hotel issues a self call to determine if a room is available.
  • Architecture Patterns Architecture: the Big Picture

    Architecture Patterns Architecture: the Big Picture

    the gamedesigninitiative at cornell university Lecture 11 Architecture Patterns Architecture: The Big Picture the gamedesigninitiative 2 Architecture Patterns at cornell university Architecture: The Big Picture the gamedesigninitiative 3 Architecture Patterns at cornell university Utilizing Software Patterns Pattern: reusable solution to a problem Typically a template, not a code library Tells you how to design your code Made by someone who ran into problem first In many cases, pattern gives you the interface List of headers for non-hidden methods 2110 all Specification for non-hidden methods over again Only thing missing is the implementation the gamedesigninitiative 4 Architecture Patterns at cornell university Example: Singletons Goal: Want to limit class to a single instance Do not want to allow users to construct new objects But do want them to access the single object Application: Writing to the console/terminal Want a unique output stream to write to console Many output streams would conflict w/ each other Given by a unique object in Java (System.out) A class with static methods in C# (not a singleton) the gamedesigninitiative 5 Architecture Patterns at cornell university Creating a Singleton in Java public class Singleton { public static final Singleton instance = new Singleton(); private Singleton() { // Initialize all fields for instance } public static Singleton getInstance() { return instance; } } the gamedesigninitiative 6 Architecture Patterns at cornell university Creating a Singleton in Java public class