COMS W3156: Software Engineering, Fall 2001

1. COMS W3156:Software Engineering, Fall 2001 Lecture #23: OS, design patterns Janak J Parekh janak@cs.columbia.edu

2. 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

3. 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

4. Today’s class • Some miscellaneous C points • Finish discussion on operating systems • Introduction to design patterns

5. 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 

6. 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

7. 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

8. 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

9. 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…

10. 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

11. 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

12. 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

13. 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…

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Singleton • Mechanism of ensuring only one object instance of an type class Singleton { public: static Singleton* instance(); protected: Singleton(); private: static Singleton* _instance; }; • Java statics make this simple

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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”

30. 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