1 / 85

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu https://ase.cs.columbia.edu/. Topics covered in this lecture. General Design Goals Design Patterns. Design Goals. Design Goals. Within a class (or component) High Cohesion Completeness Convenience

waggoner
Télécharger la présentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.eduhttps://ase.cs.columbia.edu/ COMS W4156

  2. Topics covered in this lecture • General Design Goals • Design Patterns COMS W4156

  3. Design Goals COMS W4156

  4. Design Goals • Within a class (or component) • High Cohesion • Completeness • Convenience • Clarity • Consistency • Across classes (or components) • Low Coupling COMS W4156

  5. Cohesion and Coupling • Cohesion is a property or characteristic of an individual unit • Coupling is a property of a collection of units • High cohesion GOOD, high coupling BAD • Design for change: • Reduce interdependency (coupling): You don't want a change in one unit to ripple throughout your system • Group functionality (cohesion): Easier to find things, intuitive metaphor aids understanding COMS W4156

  6. Cohesion • The measure of strength of the association of elements within a unit • Cohesion scale: • Functional cohesion (strongest, most desirable) • Sequential cohesion • Communicational cohesion • Procedural cohesion • Temporal cohesion • Logical cohesion • Coincidental cohesion (weakest, undesirable) COMS W4156

  7. Cohesion • Coincidental cohesion - elements have no meaningful relationship to one another • Logical cohesion - elements perform similar activities, but the activities to be executed are chosen from outside the unit • Temporal cohesion - elements are related in time (all should be done together) COMS W4156

  8. Cohesion • Communicational cohesion - elements perform different functions, but each function references the same input or output information • Sequential (or informational) cohesion - elements are related such that output data from one serves as input data to the next • Functional cohesion - elements contribute to a single, well-defined task COMS W4156

  9. Coupling • A measure of the interdependence of one software unit to another • Coupling scale • Content coupling (worst) • Common coupling • Control coupling • Stamp coupling • Data coupling (best / minimal needed coupling) • No direct coupling COMS W4156

  10. Coupling • No Direct Coupling - Independent • Data Coupling - Communicate by passing parameters • Stamp Coupling - Communicate via a passed data structure that contains more information than necessary for the two units to perform their functions COMS W4156

  11. Coupling • Control Coupling - Communicate using at least one "control flag" • Common Coupling - Share the same global data area • Content Coupling – • One unit changes a statement in another (usually applicable only to interpreted languages) • One unit references or alters data contained inside another • One unit branches into another COMS W4156

  12. Design Goals • Within a class (or component) • High Cohesion • Completeness • Convenience • Clarity • Consistency • Across classes (or components) • Low Coupling COMS W4156

  13. Naming Conventions • Most modern programming languages supply their own naming conventions (learn it, use it! – Java, C++, C#) • Otherwise, choose a scheme at design-time and stick to it at coding-time • For components, interfaces, classes, types, methods, exceptions, members, parameters, variables, … COMS W4156

  14. Separation of Concerns • “The programmer is having to do several things at the same time: • describe what is to be computed; • organize the computation sequencing into small steps; • organize memory management during the computation. • Ideally, the programmer should be able to concentrate on one of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks.” [Chris Reade, Elements of Functional Programming, 1989] COMS W4156

  15. Design Patterns COMS W4156

  16. Design Pattern • A general repeatable solution to a commonly occurring problem • A description of the problem and the essence of its solution • Should be sufficiently abstract to be reused in different settings • Designed to avoid re-design • Allow developers to communicate using well known, well understood names for software interactions COMS W4156

  17. Example: Delegation • An object outwardly expresses certain behavior but in reality delegates responsibility for implementing that behavior to an associated object • Very general concept, refined in several more specific design patterns COMS W4156

  18. Example: Delegation class A { void f() { System.out.println("A: doing f()"); } void g() { System.out.println("A: doing g()"); } } class C { // delegation A a = new A(); void f() { a.f(); } void g() { a.g(); } // normal attributes X x = new X(); void y() { /* do stuff */ } } public class Main { public static void main(String[] args) { C c = new C(); c.f(); c.g(); } } COMS W4156

  19. Example: Proxy Pattern • An object functions as an interface to another object • Provide a surrogate or placeholder that uses an extra level of indirection to support distributed, controlled or intelligent access to an object • In its most general form, a proxy is <something> functioning as an interface to <something else>. The <something else> could be anything: a network connection, a large object in memory, a file, or some other resource COMS W4156

  20. Non-Software Proxy Pattern COMS W4156

  21. Software Proxy Pattern COMS W4156

  22. Discussion: Proxy • Maintains a reference that lets it access the real subject • Provides an interface identical to the subject's, so that a proxy can be substituted for the real subject • Controls access to the real subject and may be responsible for creating and deleting it • May also: • Count the number of references to the real object so that it can be freed automatically when there are no more references • Load a persistent object into memory when it's first referenced • Check that the real object is locked before it is accessed to ensure that no other object can change it • … COMS W4156

  23. Types of Proxies • Remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space • Virtual proxies are placeholders for “expensive to create” or “resource hungry” objects, may cache additional information about the real subject so that they can postpone accessing it • Protection proxies check that the caller has the access permissions required to perform a request and may provide different clients with different levels of access • Others: copy-on-write, cache, synchronization, … COMS W4156

  24. Proxy Pattern Example COMS W4156

  25. Example: Façade Pattern • A single class that represents an entire subsystem or library • Provides a unified interface to a set of interfaces • May simplify by providing convenient methods for common tasks that internally involve multiple classes/methods • Often semantic wrapper of existing [legacy] objects COMS W4156

  26. Non-Software Façade Pattern COMS W4156

  27. Software Façade Pattern COMS W4156

  28. Discussion: Façade • Knows which subsystem classes are responsible for a request and delegates client requests to appropriate objects • Subsystem classes handle work assigned by façade but have no knowledge of the façade and keep no reference to it • Reduces dependencies of outside code on the inner workings of a subsystem • May reduce learning curve for novice users but be insufficient for power users COMS W4156

  29. Façade Pattern Example COMS W4156

  30. History of “Design Patterns” • (Building) Architect Christopher Alexander • A Pattern Language (1977) • Several other books • www.patternlanguage.com “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. “ COMS W4156

  31. History of Software Design Patterns • Arose from frameworks like Model-View-Controller (MVC) used in early OO programming, notably Smalltalk • “Gang of Four” (GoF): Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides • Design Patterns: Elements of Reusable Object-Oriented Software(1995) – described 23 patterns (observed, not invented) • Many conferences, symposia, books, … COMS W4156

  32. Design Patterns “A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.” [GoF] COMS W4156

  33. Design Pattern Elements • Name • Problem description • Solution description • Not a concrete design but a template for a design solution that can be instantiated in different ways • Consequences • The results and trade-offs of applying the pattern COMS W4156

  34. Design Pattern Elements (Expanded) • name and classification • intent • also known as • differentiation • motivation • applicability • structure • participants • collaborations • consequences • implementation • sample code • known uses • related patterns COMS W4156

  35. Original Catalog of Patterns COMS W4156

  36. Creational Patterns • Concerned with instantiation • Create objects for you, rather than having you instantiate objects directly COMS W4156

  37. Creational Patterns • Factory Method – creates an instance of several derived classes • Abstract Factory – creates an instance of several families of classes • Singleton – a class of which only a single instance can exist, ensures the class has only one instance and provides a global point of access to it COMS W4156

  38. Factory Method Pattern • Define an interface for creating an object, but let subclasses decide which class to instantiate • Lets a class defer instantiation to subclasses • Common in toolkits and frameworks where library code needs to create objects of types that may be subclassed by applications using the framework • More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects COMS W4156

  39. Non-Software Factory Method Pattern COMS W4156

  40. Software Factory Method Pattern COMS W4156

  41. Discussion: Factory Method • Defines a "virtual" constructor • Unlike a constructor, factory methods can have different and more descriptive names • Unlike a constructor, an existing object might be reused, instead of a new object created (object pooling) • The new operator considered harmful (make all constructors private or protected) COMS W4156

  42. Factory Method Pattern Example class Complex { public static Complex fromCartesian(double real, double imag) { return new Complex(real, imag); } public static Complex fromPolar(double rho, double theta) { return new Complex(rho * cos(theta), rho * sin(theta)); } private Complex(double a, double b) { //... } } Complex c = Complex.fromPolar(1, pi); COMS W4156

  43. Abstract Factory Pattern • Creates an instance of any of a family of classes • Provide an interface for creating families of related or dependent objects without specifying their concrete classes • Useful for families of products and to enforce families of products that must be used together • Promotes consistency among products • Example: DocumentCreator class that provides interfaces to create instances of several kinds of documents, e.g., createLetter() and createResume() COMS W4156

  44. Non-Software Abstract Factory Pattern COMS W4156

  45. Software Abstract Factory Pattern COMS W4156

  46. Discussion: Abstract Factory • Coordinates the instantiation of sets of objects that have varying implementations in such a way that only legitimate combinations of instances are possible, and hides these concrete instances behind a set of abstractions • Hides from consuming (client) objects: • The number of sets of instances supported by the system • Which set is currently in use • The concrete types that are instantiated at any point • The issue upon which the sets vary (might be determined from a config file, deployment descriptor, administrative GUI, etc.) COMS W4156

  47. Abstract Factory Pattern Example COMS W4156

  48. Singleton Pattern • Allow for only one instance of a given class to ever exist (encapsulates that the number of instances is constrained) • Provides a mechanism to obtain this instance that any client can access • Examples include objects needed for logging, communication, database access, etc. COMS W4156

  49. Non-Software Singleton Pattern COMS W4156

  50. Software Singleton Pattern COMS W4156

More Related