COMS W3156:Software Engineering, Fall 2001

Lecture #23: OS, design patterns

Janak J Parekh

janak@cs.columbia.edu

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

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

Today’s class

• Some miscellaneous C points

• Finish discussion on operating systems

• Introduction to design patterns

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

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

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

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

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…

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

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

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

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…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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