COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh...
-
date post
20-Dec-2015 -
Category
Documents
-
view
220 -
download
0
Transcript of COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh...
![Page 1: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/1.jpg)
COMS W3156:Software Engineering, Fall 2001
Lecture #23: OS, design patterns
Janak J Parekh
![Page 2: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/2.jpg)
Administrativia
• Oops– Handling of GameMap in GameEvent is slightly wrong
– We’ll release a fix today
• Feedback?• Returning HW’s
– Grr, our TA’s…
• Reminder: Research Fair tomorrow– http://acm.cs.columbia.edu/research
![Page 3: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/3.jpg)
Next class
• Mythical Man-Month review
• Final exam review– By the way, think of it as a “final midterm”…– Let’s go through the reading list right now
![Page 4: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/4.jpg)
Today’s class
• Some miscellaneous C points
• Finish discussion on operating systems
• Introduction to design patterns
![Page 5: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/5.jpg)
On gets()
• Yes, Phil’s right: you shouldn’t use gets
• fgets(string, strlen(string), stdin);
• But for the scope of this homework, it’s not like we’re writing code that would be subject to security vulnerabilities– Tho Phil will still argue with me about it
![Page 6: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/6.jpg)
Streams in C
• FILEs (actually FILE *)
• Open with fopen(), close with fclose()
• Have fread() and fwrite()
• Plus fprintf() and fscanf()
• And ftell()/fseek() for random access
• Are buffered
• Have pushback
![Page 7: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/7.jpg)
Strings in C
• #include <string.h>• char *strcat(char *dest, const char *src);
• char *strcpy(char *dest, const char *src);
• size_t strlen(const char *s);• int strcmp(const char *s1, const char *s2);
• Should really use “n” variants (strncat, strncpy, etc.) if doing network programming
![Page 8: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/8.jpg)
UNIX
• Core concept: everything is a file
• Devices are “special files”, stored in /dev
• UNIX devices are character or block oriented– tty vs. disk, for example– mice, audio?
• mknod command
![Page 9: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/9.jpg)
Speaking of files…
• Filesystems are often considered a core functionality of the OS
• However, it’s usually separately modularized: convenience abstraction layer
• Two common models:– Rooted (UNIX and cousins): mount points– Non-rooted (DOS, Windows)
• Links…
![Page 10: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/10.jpg)
Special filesystems
• “Virtual” filesystems– /proc
• In Linux and Solaris• Has a number of useful sets of information, no
longer just “processes”
– /tmp• On certain machines, actually ramdisk• Is this really virtual?
• NFS filesystems
![Page 11: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/11.jpg)
Processes
• The “fork” model: start off a new process as a duplicate of an existing one
• Copy-on-write methodology: only create as much of the new process as necessary
• Multitasking of processes– Cooperative: “hey, let me know when you’re done, so I
can give time to another process”– Preemptive: “yo, your slot is up”
• Interprocess communication: messages/queues, shared memory, pipes, domain sockets
![Page 12: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/12.jpg)
Memory management
• Allocation: assign memory blocks to processes, as well as dynamic memory allocation from a “heap”
• Segmentation: prevent programs from overwriting each other’s memory
• Virtual memory: abstract away memory into “pages” which may be swapped in and out of disk– What to swap requires “replacement strategy”
• Memory-mapped files
![Page 13: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/13.jpg)
Networking
• At first, write directly to network hardware (yuck!)
• TCP/IP, socket API built on top of most OS’s (BSD socket API)
• You have no idea how nice Java sockets are in comparison to C/BSD sockets…
![Page 14: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/14.jpg)
Shell
• Not really part of the OS, but expected to be bundled with it
• Front-end to operating system• Allow for convenient file management and
process control• bash, cmd just make a bunch of system calls…• Explorer: a GUI front-end• eshell: now this is freaky
![Page 15: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/15.jpg)
Design patterns
• The book that started it all: Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, and Vlissides, 1995– Usually referred to by Gamma or “Gang of
Four”– Basic concept based on A Pattern Language:
Towns/Buildings/Construction, Christopher Alexander, 1977
![Page 16: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/16.jpg)
Definition of a design pattern
• Alexander: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
• Not data structures-oriented, and not particularly domain-specific
![Page 17: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/17.jpg)
Definition of a design pattern (II)
• “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context”
• General goal: design with more flexibility than you initially might
• Generally presented as Name, Problem, Solution, Consequences
![Page 18: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/18.jpg)
What we’ll do
• Just a collection of some of the more useful design patterns
• If you’re interested, pick up a copy of this book: it’s easy to get– It is a bit dated, though: a lot of patterns are
now internalized in existing systems
![Page 19: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/19.jpg)
Strategy
• Instead of linking to one implementation of a function, develop an interface and allow runtime selection of the actual implementation
• Often useful for differentiating between many similar operations in a program– Instead of lots of if’s
• Java makes this easy: late-binding and interfaces– Phil uses this in his Server
![Page 20: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/20.jpg)
Iterator
• Less novel today: used in both C++ and Java• You’re less concerned with the data structure:
you’d just like a pointer that will iterate through all the data in a consistent manner
• Java’s is half-baked, just like the rest of java.util• Warning: if data structure changes while you’re
iterating… sometimes, toArray is better
![Page 21: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/21.jpg)
Flyweight
• Technique for dealing with lots and lots of objects: share the complex object and have it point to a simpler one
• In a document, each alphanumeric character: if represented by a separate object, too expensive
• Instantiate one object per character (i.e. 52) and share
![Page 22: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/22.jpg)
Singleton
• Mechanism of ensuring only one object instance of an typeclass Singleton {
public: static Singleton* instance();
protected: Singleton();
private: static Singleton* _instance;
};
• Java statics make this simple
![Page 23: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/23.jpg)
Factory method
• Provide an abstract construction interface, possibly in a separate class
• Allows subclasses to substitute their own constructors
• Typical Pattern technique of substituting a more flexible “loose coupling” for built in OO rigidity
• Also useful if often-redundant initialization• Java: java.net.SocketImplFactory, javax.swing.
BorderFactory
![Page 24: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/24.jpg)
Chain of Responsibility
• Decouple sender and receiver
• Allow for multiple receivers
• If the “handler” of a message isn’t known per se
• Sort of like event programming, but more deterministic
![Page 25: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/25.jpg)
Memento
• Opaque “state objects” to memorize the state of an object– “Opaque” to other objects: “Caretaker” can only save
and transfer, “Originator” can actually use data
– Therefore avoids violation of encapsulation
• Useful for “restoring” objects• Example: “undoing” operations in a graphics
editor
![Page 26: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/26.jpg)
Mediator
• “Middleman” object – encapsulates how objects interact with each other, so they can be independent
• Dependencies might also change between objects
• All components communicate only with mediator
• Like an “event hub”, but well-defined
![Page 27: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/27.jpg)
Observer
• Very common GUI programming paradigm
• Leads directly to event programming (which in itself is a relatively recent construct)
• Define a one-to-many dependency between objects so that when the parent changes state, dependents are notified
![Page 28: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/28.jpg)
Proxy
• Provide a “surrogate” or placeholder for another object to control access to it
• Useful for cost, abstraction• “Sophisticated pointer”• Can be extrapolated to the common
network programming paradigm– RMI, CORBA use “proxy” objects– Web proxy
![Page 29: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/29.jpg)
Adapter
• Convert interface of a class into another interface
• Swing Adapters are actually a bit different from this: they’re partial implementations– Interestingly, other Swing classes can be
considered Adapters– JTextPane is an “adapter” from the
JComponent to a “Document”
![Page 30: COMS W3156: Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu.](https://reader036.fdocuments.net/reader036/viewer/2022062407/56649d4b5503460f94a2844a/html5/thumbnails/30.jpg)
What does this mean for you?
• OS: help you to understand the “big picture”, not immediate in work scope of class
• Design patterns: You know several of these already; it’s just a “standardization” of common OO concepts