Stoop 439-decorator
•Download as PPT, PDF•
0 likes•594 views
This document describes the Decorator design pattern. The Decorator pattern allows behavior to be added to individual objects dynamically at runtime by wrapping them in decorator objects that contain the added behavior. This provides a flexible alternative to subclassing for extending functionality. Decorators work by maintaining a reference to a component object and conforming to the same interface as the component. Requests are forwarded to the component and decorators can perform additional actions before and after forwarding.
Report
Share
Report
Share
Recommended
Stoop 440-adaptor
The document discusses the adapter design pattern, which allows classes with incompatible interfaces to work together. The adapter pattern involves a target interface that clients expect, an adaptee with a different interface that needs adapting, and an adapter class that converts the adaptee's interface to the target interface. The adapter acts as a bridge between the adaptee and target, allowing the adaptee's functionality to be accessed by clients through the target interface.
Stoop 422-naming idioms
This document discusses naming conventions and standards for Smalltalk code. It recommends that names should reveal intention, follow standard protocols, and use intention-revealing selectors. Specific naming guidelines are provided for variables, methods, classes, parameters, and temporaries. Names should indicate roles rather than types where possible. The document emphasizes that naming is important for communication and maintaining code quality. It concludes by recommending the book "Smalltalk Best Practice Patterns" as a useful reference.
Stoop 433-chain
1) The chain of responsibility pattern avoids coupling the sender of a request to its receiver by allowing more than one object to handle the request. The request is passed along a chain of receiving objects until one of the objects handles it.
2) It reduces coupling between objects and simplifies connections by having each object in the chain only know about its successor instead of all possible receivers.
3) Responsibilities can be flexibly distributed among objects by adding or changing objects in the chain at runtime.
Stoop 421-design heuristics
This document outlines several design heuristics for object-oriented programming, as inspired by Arthur Riel. It discusses concepts like hiding data within classes, minimizing coupling between classes, ensuring classes have a single clear responsibility, and avoiding tight dependencies between classes. The heuristics are intended to produce high cohesion within classes and loose coupling between classes.
Stoop ed-unit ofreuse
This document discusses using hook and template methods to improve code reuse in object-oriented programs. Hook methods provide places where subclasses can insert specialized behavior, while template methods provide reusable context. Examples show hook methods like printOn: and postCopy that subclasses can override to customize object printing and copying behavior. Template methods like printString and copy provide reusable context by calling the hook methods. This approach allows code to be reused while still allowing customization in subclasses.
Stoop 450-s unit
Unit testing involves writing small tests for individual units or classes of code to ensure specified behaviors are maintained. Tests should be written incrementally and even before code is written. When bugs are discovered, write tests to demonstrate the bug before fixing. Tests act as documentation and provide confidence when refactoring code. Common unit testing frameworks like SUnit and JUnit provide tools for writing, running, and collecting test results. Tests should be repeatable, require no human intervention, and change less often than the code being tested.
Stoop 301-internal objectstructureinvw
The document discusses the internal structure of objects in VisualWorks Smalltalk. It describes three ways that classes can be created: as non-indexable pointers, indexable pointers, and indexable non-pointers. The formatting of classes in stored in the format instance variable of Behavior objects. This determines whether a class uses pointers, is indexable, fixed, or uses bits to store instances. The size of individual objects depends on factors like whether they are pointers, indexable, and their class and instance variable sizes.
Recommended
Stoop 440-adaptor
The document discusses the adapter design pattern, which allows classes with incompatible interfaces to work together. The adapter pattern involves a target interface that clients expect, an adaptee with a different interface that needs adapting, and an adapter class that converts the adaptee's interface to the target interface. The adapter acts as a bridge between the adaptee and target, allowing the adaptee's functionality to be accessed by clients through the target interface.
Stoop 422-naming idioms
This document discusses naming conventions and standards for Smalltalk code. It recommends that names should reveal intention, follow standard protocols, and use intention-revealing selectors. Specific naming guidelines are provided for variables, methods, classes, parameters, and temporaries. Names should indicate roles rather than types where possible. The document emphasizes that naming is important for communication and maintaining code quality. It concludes by recommending the book "Smalltalk Best Practice Patterns" as a useful reference.
Stoop 433-chain
1) The chain of responsibility pattern avoids coupling the sender of a request to its receiver by allowing more than one object to handle the request. The request is passed along a chain of receiving objects until one of the objects handles it.
2) It reduces coupling between objects and simplifies connections by having each object in the chain only know about its successor instead of all possible receivers.
3) Responsibilities can be flexibly distributed among objects by adding or changing objects in the chain at runtime.
Stoop 421-design heuristics
This document outlines several design heuristics for object-oriented programming, as inspired by Arthur Riel. It discusses concepts like hiding data within classes, minimizing coupling between classes, ensuring classes have a single clear responsibility, and avoiding tight dependencies between classes. The heuristics are intended to produce high cohesion within classes and loose coupling between classes.
Stoop ed-unit ofreuse
This document discusses using hook and template methods to improve code reuse in object-oriented programs. Hook methods provide places where subclasses can insert specialized behavior, while template methods provide reusable context. Examples show hook methods like printOn: and postCopy that subclasses can override to customize object printing and copying behavior. Template methods like printString and copy provide reusable context by calling the hook methods. This approach allows code to be reused while still allowing customization in subclasses.
Stoop 450-s unit
Unit testing involves writing small tests for individual units or classes of code to ensure specified behaviors are maintained. Tests should be written incrementally and even before code is written. When bugs are discovered, write tests to demonstrate the bug before fixing. Tests act as documentation and provide confidence when refactoring code. Common unit testing frameworks like SUnit and JUnit provide tools for writing, running, and collecting test results. Tests should be repeatable, require no human intervention, and change less often than the code being tested.
Stoop 301-internal objectstructureinvw
The document discusses the internal structure of objects in VisualWorks Smalltalk. It describes three ways that classes can be created: as non-indexable pointers, indexable pointers, and indexable non-pointers. The formatting of classes in stored in the format instance variable of Behavior objects. This determines whether a class uses pointers, is indexable, fixed, or uses bits to store instances. The size of individual objects depends on factors like whether they are pointers, indexable, and their class and instance variable sizes.
10 - OOP - Inheritance (b)
The document discusses inheritance and method lookup in Smalltalk. It explains that inheritance allows classes to reuse and extend the behavior of their ancestors. Method lookup starts by searching the class of the receiver, and if not found proceeds to search superclasses. The keyword super represents the receiver but changes the starting point of method lookup to the superclass of the method containing the super expression. This allows methods to invoke behaviors defined in their parent classes.
Double Dispatch
This document discusses using double dispatch to determine which method to invoke based on both the receiver and an argument. It provides examples of printing documents using type checks, which has drawbacks when new document types are added. Double dispatch solves this by having the receiver send a message back to the argument, passing itself as an argument, allowing the most specific method to be invoked based on both objects. It also provides a number coercion example where double dispatch avoids type checks by having integers and floats dispatch to primary operations on each other.
12 - Conditions and Loops
This document discusses core concepts in Smalltalk including conditionals, loops, collections, common object behavior, and copying objects. It covers boolean logic and conditional expressions, the collection hierarchy with 80+ classes including Array, OrderedCollection, Dictionary, and Set. Common methods for collections like do:, select:, collect: are also summarized, as well as printing, reading, copying and notifying objects in the programming environment.
Stoop 437-proxy
This document discusses the proxy pattern. The proxy pattern provides a surrogate or placeholder for another object to control access to it. There are different types of proxies like remote proxies, virtual proxies, and protection proxies. A proxy maintains a reference to the real subject and presents the same interface to control access and optionally perform additional tasks when the subject is accessed.
14 - Exceptions
Exception handling in Smalltalk involves catching exceptions using an "on:do:" block. The document discusses the standardization of exceptions in 1996, the predefined exception classes like Error and Notification, and how to catch, signal, and handle exceptions in code. It also covers exception sets, the exception environment, and different ways exceptions can be handled or exited from including resume, return, retry, and resignalAs:.
08 refactoring
This document provides an overview of refactoring and design patterns. It begins with some principles of object-oriented design like the open-closed principle. It then defines refactoring as changing code without altering external behavior to improve structure. Common code smells that indicate needs for refactoring are described, like duplicated code. The document outlines the Law of Demeter and provides examples of violations. It concludes by introducing design patterns and focusing on the singleton pattern.
5 - OOP - Smalltalk in a Nutshell (c)
Smalltalk has a uniform object model where everything is an object. There is only one mechanism of message passing between objects. Inheritance is single between classes. Classes are also objects that are instances of other metaclasses. Method lookup follows a single mechanism by looking for methods in the class of the receiver.
Stoop 423-smalltalk idioms
This document provides guidance on various Smalltalk coding idioms through examples and explanations. It discusses topics such as:
- Using constructor methods to ensure valid object creation
- Defining comparison methods like <= consistently
- Writing query methods instead of exposing internal state
- Structuring methods to perform single identifiable tasks
- Implementing delegation to share behavior without inheritance
- Commenting methods to explain intent not obvious in code
The overall message is to think carefully about interface and implementation choices to write clear, well-structured Smalltalk code based on idioms that have proven useful.
Stoop 300-block optimizationinvw
Blocks in VisualWorks can be full, copying, clean, or inlined. Full blocks are most costly as they require a separate evaluation context, while clean blocks contain no references to outside variables and are compiled directly into the calling method. The programmer should aim to write code that uses clean blocks, such as by avoiding variable assignments, using streams instead of iterative methods, and utilizing inject:into: to suppress outside references. Defining blocks as cleanly as possible allows for better optimization by the compiler.
Stoop 436-strategy
The document discusses the strategy design pattern, which defines a family of algorithms, encapsulates each in a separate class, and defines the same interface so they can be interchangeable. The strategy pattern allows algorithms to vary independently from clients that use them by assigning responsibility for a task to various strategy classes. This improves flexibility by making algorithms easily replaceable at runtime and reduces complexity in client classes. The key participants are a strategy interface, concrete strategy classes that implement it, and a context class that maintains a reference to a strategy and delegates work to it.
10 - OOP - Inheritance (a)
This document discusses inheritance and method lookup in Smalltalk. It explains that inheritance allows classes to reuse and extend existing behavior from their ancestors. Method lookup starts by searching the class of the receiver, then traversing up the inheritance hierarchy if not found. The keyword super sends a message starting the lookup in the superclass of the method's class rather than the receiver's class, allowing overridden methods to invoke the superclass implementation.
Stoop ed-class forreuse
This document discusses principles of object-oriented design, including:
1. Parametrizing code to avoid hardcoding constants and allow runtime changes without recompilation.
2. Defining behavior independently of state through abstract state and message layers.
3. Dividing programs into short, single-purpose methods to improve readability, reuse, and maintenance.
Stoop ed-some principles
The document discusses several principles of software design including:
1) The open-closed principle which states that code should be open for extension but closed for modification.
2) The dependency inversion principle which states that high level modules should not depend on low level modules and both should depend on abstractions.
3) The interface segregation principle which states that dependencies should depend on the smallest possible interface to avoid "fat" interfaces.
4) The acyclic dependency principle which states that dependency structures between packages should not contain cyclic dependencies.
12 virtualmachine
This document discusses virtual machines and their implementation. It begins with an introduction to virtual machines, noting that they provide an abstract computing architecture that supports programming languages in a hardware-independent way. It then outlines the main components of a virtual machine, including the heap store, interpreter, automatic memory management, and threading system. The document dives into more detail on each of these components and also discusses optimizations that can be performed. It concludes by noting that while virtual machines provide benefits like platform independence, there is an overhead to their execution.
Stoop 414-smalltalk elementsofdesign
This document discusses various elements of object-oriented design, including instance initialization, enforcing instance creation interfaces, instance and class methods/variables, class initialization, and other design patterns and principles. It provides examples and recommendations for properly initializing instances, creating robust creation interfaces, sharing state between classes and instances, and avoiding common anti-patterns. The document also includes a case study on the Scanner class in Smalltalk to illustrate some of these concepts.
Debugging VisualWorks
This document discusses common mistakes and debugging techniques in VisualWorks. It covers issues such as: confusing true and True, redefining classes, modifying self and super, redefining basic methods, iterating over and modifying collections, using breakpoints, and printing for debugging. The document provides examples and recommendations to avoid common bugs and debug issues efficiently.
Stoop sed-class initialization
The document discusses class initialization in object-oriented programming. It explains that class initialization is used to initialize class variables and instance variables when a class is loaded. The class initialization method, typically named "initialize", is automatically called by the system and can be used to set up default values for properties that are shared across all class instances. The document provides an example Date class that defines various class variables for storing things like month names and days in a month, and initializes these values in its Date class>>initialize method.
Stoop metaclasses
The document discusses metaclasses in Smalltalk. Some key points:
1. Every class is an instance of a metaclass. The metaclass hierarchy parallels the class hierarchy.
2. Metaclasses inherit from Class and Behavior. Every metaclass is an instance of Metaclass.
3. The metaclass of Metaclass is also an instance of Metaclass, completing the metaclass hierarchy.
Stoop 423-some designpatterns
This document discusses the composite design pattern. It begins with an overview of composites, stating that composites allow composing objects into tree structures to represent part-whole hierarchies, and clients can treat individual and composite objects uniformly. It then provides more details on composites, including participants like component and leaf, collaborations, and consequences. Examples are given of applying composites to graphical user interface elements like rectangles, lines, and text. Variations and relationships to other patterns like visitors are also discussed. The key points are that composites allow representing hierarchical structures and treating components and composites uniformly.
11 - OOP - Numbers
Numbers in Smalltalk support automatic coercion so that numbers of different types (e.g. integer and float) can be used together in arithmetic operations. When addition fails due to a type mismatch, the numbers will retry the operation after coercing one number to the type of the other based on their generality (level of precision). This allows calculations to be performed without needing to manually convert number types.
Bridging the Divide between Architecture and Code (Germany JUGs version)
(Version from German JUG talks April 2018)
Abstract
Static diagrams on wikis and white-boards might capture the vision of architects, but they don’t much help programmers to understand how the code they’re working on right now fits into the architecture. Nor are the programmers warned when they violate the diagrams as they forge changes, line-by-line.
This is a huge problem – it is ultimately individual lines of code that make or break an architecture; and we know that a clean architecture will help teams develop a more flexible product, with less complexity, less wasted effort, etc. Worse, without practical architectural guidance, programmers wrestle with invisible structures that emerge from thousands of inter-dependent lines of code.
And being invisible, these structures become ever more complex, coupled, and tangled. In fact, uncontrolled structure actively fights against productive development.
This talk shows how to rein in emergent code-base structures and gradually transform them into a cogent, defined architecture. You will see how…
- Visualizing the emergent structure makes a code-base easier to understand.
- Restructuring to remove tangles and reduce coupling makes the visualized code-base easier to work on.
- Specifying layering and dependency rules converts good structure into a controlled architecture that guides the team as the code-base evolves and grows.
A key ingredient is a live visualization, inside the IDE, of the detailed code the programmer is working on, in the context of the overall architecture. In short, you will learn how bridging the architect/programmer divide can convert code-base structure from liability into an asset that actively works for development productivity.
Stoop ed-subtyping subclassing
This document discusses the differences between subclassing and subtyping in object-oriented design. It explains that subclassing is using inheritance primarily for code reuse, even if the subclass interface is not compatible with the superclass interface. Subtyping uses inheritance to reuse interface specifications so that subclasses are substitutable for their superclasses. The document recommends favoring subtyping over subclassing for reusable software since it leads to more understandable class relationships based on interfaces rather than implementation.
More Related Content
Viewers also liked
10 - OOP - Inheritance (b)
The document discusses inheritance and method lookup in Smalltalk. It explains that inheritance allows classes to reuse and extend the behavior of their ancestors. Method lookup starts by searching the class of the receiver, and if not found proceeds to search superclasses. The keyword super represents the receiver but changes the starting point of method lookup to the superclass of the method containing the super expression. This allows methods to invoke behaviors defined in their parent classes.
Double Dispatch
This document discusses using double dispatch to determine which method to invoke based on both the receiver and an argument. It provides examples of printing documents using type checks, which has drawbacks when new document types are added. Double dispatch solves this by having the receiver send a message back to the argument, passing itself as an argument, allowing the most specific method to be invoked based on both objects. It also provides a number coercion example where double dispatch avoids type checks by having integers and floats dispatch to primary operations on each other.
12 - Conditions and Loops
This document discusses core concepts in Smalltalk including conditionals, loops, collections, common object behavior, and copying objects. It covers boolean logic and conditional expressions, the collection hierarchy with 80+ classes including Array, OrderedCollection, Dictionary, and Set. Common methods for collections like do:, select:, collect: are also summarized, as well as printing, reading, copying and notifying objects in the programming environment.
Stoop 437-proxy
This document discusses the proxy pattern. The proxy pattern provides a surrogate or placeholder for another object to control access to it. There are different types of proxies like remote proxies, virtual proxies, and protection proxies. A proxy maintains a reference to the real subject and presents the same interface to control access and optionally perform additional tasks when the subject is accessed.
14 - Exceptions
Exception handling in Smalltalk involves catching exceptions using an "on:do:" block. The document discusses the standardization of exceptions in 1996, the predefined exception classes like Error and Notification, and how to catch, signal, and handle exceptions in code. It also covers exception sets, the exception environment, and different ways exceptions can be handled or exited from including resume, return, retry, and resignalAs:.
08 refactoring
This document provides an overview of refactoring and design patterns. It begins with some principles of object-oriented design like the open-closed principle. It then defines refactoring as changing code without altering external behavior to improve structure. Common code smells that indicate needs for refactoring are described, like duplicated code. The document outlines the Law of Demeter and provides examples of violations. It concludes by introducing design patterns and focusing on the singleton pattern.
5 - OOP - Smalltalk in a Nutshell (c)
Smalltalk has a uniform object model where everything is an object. There is only one mechanism of message passing between objects. Inheritance is single between classes. Classes are also objects that are instances of other metaclasses. Method lookup follows a single mechanism by looking for methods in the class of the receiver.
Stoop 423-smalltalk idioms
This document provides guidance on various Smalltalk coding idioms through examples and explanations. It discusses topics such as:
- Using constructor methods to ensure valid object creation
- Defining comparison methods like <= consistently
- Writing query methods instead of exposing internal state
- Structuring methods to perform single identifiable tasks
- Implementing delegation to share behavior without inheritance
- Commenting methods to explain intent not obvious in code
The overall message is to think carefully about interface and implementation choices to write clear, well-structured Smalltalk code based on idioms that have proven useful.
Stoop 300-block optimizationinvw
Blocks in VisualWorks can be full, copying, clean, or inlined. Full blocks are most costly as they require a separate evaluation context, while clean blocks contain no references to outside variables and are compiled directly into the calling method. The programmer should aim to write code that uses clean blocks, such as by avoiding variable assignments, using streams instead of iterative methods, and utilizing inject:into: to suppress outside references. Defining blocks as cleanly as possible allows for better optimization by the compiler.
Stoop 436-strategy
The document discusses the strategy design pattern, which defines a family of algorithms, encapsulates each in a separate class, and defines the same interface so they can be interchangeable. The strategy pattern allows algorithms to vary independently from clients that use them by assigning responsibility for a task to various strategy classes. This improves flexibility by making algorithms easily replaceable at runtime and reduces complexity in client classes. The key participants are a strategy interface, concrete strategy classes that implement it, and a context class that maintains a reference to a strategy and delegates work to it.
10 - OOP - Inheritance (a)
This document discusses inheritance and method lookup in Smalltalk. It explains that inheritance allows classes to reuse and extend existing behavior from their ancestors. Method lookup starts by searching the class of the receiver, then traversing up the inheritance hierarchy if not found. The keyword super sends a message starting the lookup in the superclass of the method's class rather than the receiver's class, allowing overridden methods to invoke the superclass implementation.
Stoop ed-class forreuse
This document discusses principles of object-oriented design, including:
1. Parametrizing code to avoid hardcoding constants and allow runtime changes without recompilation.
2. Defining behavior independently of state through abstract state and message layers.
3. Dividing programs into short, single-purpose methods to improve readability, reuse, and maintenance.
Stoop ed-some principles
The document discusses several principles of software design including:
1) The open-closed principle which states that code should be open for extension but closed for modification.
2) The dependency inversion principle which states that high level modules should not depend on low level modules and both should depend on abstractions.
3) The interface segregation principle which states that dependencies should depend on the smallest possible interface to avoid "fat" interfaces.
4) The acyclic dependency principle which states that dependency structures between packages should not contain cyclic dependencies.
12 virtualmachine
This document discusses virtual machines and their implementation. It begins with an introduction to virtual machines, noting that they provide an abstract computing architecture that supports programming languages in a hardware-independent way. It then outlines the main components of a virtual machine, including the heap store, interpreter, automatic memory management, and threading system. The document dives into more detail on each of these components and also discusses optimizations that can be performed. It concludes by noting that while virtual machines provide benefits like platform independence, there is an overhead to their execution.
Stoop 414-smalltalk elementsofdesign
This document discusses various elements of object-oriented design, including instance initialization, enforcing instance creation interfaces, instance and class methods/variables, class initialization, and other design patterns and principles. It provides examples and recommendations for properly initializing instances, creating robust creation interfaces, sharing state between classes and instances, and avoiding common anti-patterns. The document also includes a case study on the Scanner class in Smalltalk to illustrate some of these concepts.
Debugging VisualWorks
This document discusses common mistakes and debugging techniques in VisualWorks. It covers issues such as: confusing true and True, redefining classes, modifying self and super, redefining basic methods, iterating over and modifying collections, using breakpoints, and printing for debugging. The document provides examples and recommendations to avoid common bugs and debug issues efficiently.
Stoop sed-class initialization
The document discusses class initialization in object-oriented programming. It explains that class initialization is used to initialize class variables and instance variables when a class is loaded. The class initialization method, typically named "initialize", is automatically called by the system and can be used to set up default values for properties that are shared across all class instances. The document provides an example Date class that defines various class variables for storing things like month names and days in a month, and initializes these values in its Date class>>initialize method.
Stoop metaclasses
The document discusses metaclasses in Smalltalk. Some key points:
1. Every class is an instance of a metaclass. The metaclass hierarchy parallels the class hierarchy.
2. Metaclasses inherit from Class and Behavior. Every metaclass is an instance of Metaclass.
3. The metaclass of Metaclass is also an instance of Metaclass, completing the metaclass hierarchy.
Stoop 423-some designpatterns
This document discusses the composite design pattern. It begins with an overview of composites, stating that composites allow composing objects into tree structures to represent part-whole hierarchies, and clients can treat individual and composite objects uniformly. It then provides more details on composites, including participants like component and leaf, collaborations, and consequences. Examples are given of applying composites to graphical user interface elements like rectangles, lines, and text. Variations and relationships to other patterns like visitors are also discussed. The key points are that composites allow representing hierarchical structures and treating components and composites uniformly.
11 - OOP - Numbers
Numbers in Smalltalk support automatic coercion so that numbers of different types (e.g. integer and float) can be used together in arithmetic operations. When addition fails due to a type mismatch, the numbers will retry the operation after coercing one number to the type of the other based on their generality (level of precision). This allows calculations to be performed without needing to manually convert number types.
Viewers also liked (20)
Similar to Stoop 439-decorator
Bridging the Divide between Architecture and Code (Germany JUGs version)
(Version from German JUG talks April 2018)
Abstract
Static diagrams on wikis and white-boards might capture the vision of architects, but they don’t much help programmers to understand how the code they’re working on right now fits into the architecture. Nor are the programmers warned when they violate the diagrams as they forge changes, line-by-line.
This is a huge problem – it is ultimately individual lines of code that make or break an architecture; and we know that a clean architecture will help teams develop a more flexible product, with less complexity, less wasted effort, etc. Worse, without practical architectural guidance, programmers wrestle with invisible structures that emerge from thousands of inter-dependent lines of code.
And being invisible, these structures become ever more complex, coupled, and tangled. In fact, uncontrolled structure actively fights against productive development.
This talk shows how to rein in emergent code-base structures and gradually transform them into a cogent, defined architecture. You will see how…
- Visualizing the emergent structure makes a code-base easier to understand.
- Restructuring to remove tangles and reduce coupling makes the visualized code-base easier to work on.
- Specifying layering and dependency rules converts good structure into a controlled architecture that guides the team as the code-base evolves and grows.
A key ingredient is a live visualization, inside the IDE, of the detailed code the programmer is working on, in the context of the overall architecture. In short, you will learn how bridging the architect/programmer divide can convert code-base structure from liability into an asset that actively works for development productivity.
Stoop ed-subtyping subclassing
This document discusses the differences between subclassing and subtyping in object-oriented design. It explains that subclassing is using inheritance primarily for code reuse, even if the subclass interface is not compatible with the superclass interface. Subtyping uses inheritance to reuse interface specifications so that subclasses are substitutable for their superclasses. The document recommends favoring subtyping over subclassing for reusable software since it leads to more understandable class relationships based on interfaces rather than implementation.
Design patterns structuralpatterns(thedecoratorpattern)
The document discusses the Decorator design pattern, which allows additional responsibilities to be attached to an object dynamically at runtime. It provides examples of how the Decorator pattern can be used to add features like borders and scrolling to views. The Decorator pattern provides a more flexible alternative to inheritance for extending object functionality compared to traditional inheritance which can result in explosion of classes.
Stoop ed-frameworks
This document discusses frameworks and compares them to libraries. Frameworks define the overall architecture and flow of a program, while libraries are called by a program to extend their functionality. Frameworks work by calling methods defined in subclasses, following a predefined interaction and flow. Libraries are called by a program and return control back to the program. Frameworks rely on inheritance to allow customization through subclassing, while libraries are customized through composition.
7 - OOP - OO Concepts
This document provides an introduction to essential object-oriented concepts including objects, classes, inheritance, composition, and comparison. It discusses how object-oriented programming views the world as interacting objects and focuses on encapsulating data and procedures while promoting modularity and reuse through concepts like classes, inheritance, polymorphism and late binding.
Decorator design pattern
Presentation is about Decorator Design Pattern from DESIGN PATTERN course. Content is based on JNTUH syllabus.
Decorator Pattern
The document discusses the decorator design pattern. The decorator pattern allows adding new behaviors to existing objects at runtime by placing them inside decorator objects that contain the original object. This allows functionality to be added without changing the object's class. Some key points made are: the decorator pattern adds functionality at runtime through composition; decorations are independent and can be mixed; and it is used to attach additional responsibilities to objects without subclassing. An example using shapes and color decorators is provided to demonstrate implementation.
1 - OOP
This document discusses object-oriented programming and modeling. It introduces key concepts like objects, classes, inheritance, and how they help address the inherent complexity in software as it evolves over time. Objects encapsulate both data and behavior, and classes define common properties and behaviors for groups of objects. Inheritance allows classes to share and specialize behaviors through subclass hierarchies. Together, these concepts provide abstraction and reuse capabilities that help manage complexity in software systems.
Bridging the divide between architecture and code (US version)
(As presented at Boston, New York, San Francisco JUGs 2018)
Static diagrams on wikis and white-boards might capture the vision of architects, but they don’t much help programmers to understand how the code they’re working on right now fits into the architecture. Nor are the programmers warned when they violate the diagrams as they forge changes, line-by-line.
This is a huge problem – it is ultimately individual lines of code that make or break an architecture; and we know that a clean architecture will help teams develop a more flexible product, with less complexity, less wasted effort, etc. Worse, without practical architectural guidance, programmers wrestle with invisible structures that emerge from thousands of inter-dependent lines of code. And being invisible, these structures become ever more complex, coupled, and tangled.
In fact, uncontrolled structure actively fights against productive development.
This talk shows how to rein in emergent code-base structures and gradually transform them into a cogent, defined architecture.
Cs 1023 lec 8 design pattern (week 2)
The document discusses design patterns, which are reusable solutions to common software design problems. It provides examples of different types of patterns, including creational (Factory Method, Abstract Factory, Builder, Prototype, Singleton), structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy), and behavioral (Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor) patterns. Each pattern is defined and an example problem and solution using the pattern is described.
Stoop ed-lod
The document discusses coupling and the Law of Demeter principle, which states that objects should only communicate with their immediate neighbors. Following this principle leads to code with looser coupling, better encapsulation, and easier substitution of components. The document provides examples of correct and incorrect ways to follow the Law of Demeter when sending messages to instance variables, arguments, self, and newly created objects. It also discusses some exceptions like collections, as well as considerations around using accessors instead of direct instance variable access. Overall it emphasizes designing objects with complete interfaces that protect encapsulation.
Docker in a big company
Hey curious friend, let's play a game. How can we bring together two different companies, an established enterprise with traditional dev and ops having cultural differences when working together with a DevOps champion startup. In the middle exists a number of real use cases on how we are bringing DevOps culture with Docker to Atos Worldline. In my talk I will discuss the first use cases for Docker at Atos Worldline, where we are today, learnings and benefits until now, our future technology stack and how Docker is changing our human stack a.k.a. how we communicate and work together.
Rails Presenters
A quick run down on the presenter pattern in rails, code for the talk is here https://github.com/ridget/presenters_app
Stoop 434-composite
This document discusses the composite pattern, which allows objects to be grouped together into tree structures to represent part-whole hierarchies. The composite pattern allows clients to treat both individual objects and compositions of objects uniformly. It is applicable when representing part-whole hierarchies and treating compositions and individual objects the same. Key participants are components, leaves, and composites. Composites define behavior for components with children by storing child components and implementing operations to delegate to children.
Exhibits and Presenters
The document discusses decorators, exhibits, and presenters design patterns. Decorators allow adding new functionality to objects dynamically without subclassing. Exhibits connect a model object to a context for rendering, wrapping the model and encapsulating rendering decisions. Presenters deal with views and models, moving view logic out of the view layer and into presenter classes to clean the view layer. Exhibits differ from presenters in that exhibits don't know about view languages while presenters speak the language of the view.
Lessons Learned from Dockerizing Spark Workloads: Spark Summit East talk by T...
Many initiatives for running applications inside containers have been scoped to run on a single host. Using Docker containers for large-scale production environments poses interesting challenges, especially when deploying distributed Big Data applications like Apache Spark.
Some of these challenges include container lifecycle management, smart scheduling for optimal resource utilization, network configuration and security, and performance. At BlueData, we’re “all in” on Docker containers – with a specific focus on Spark applications. We’ve learned first-hand how to address these challenges for Fortune 500 enterprises and government organizations that want to deploy Big Data workloads using Docker.
In this session, you’ll learn about networking Docker containers across multiple hosts securely. We’ll discuss ways to achieve high availability across distributed Big Data applications and hosts in your data center. And since we’re talking about very large volumes of data, performance is a key factor. So we’ll discuss some of the storage options we explored and implemented at BlueData to achieve near bare-metal I/O performance for Spark using Docker. We’ll share our lessons learned as well as some tips and tricks on how to Dockerize your Big Data applications in a reliable, scalable, and high-performance environment.
Brief introduction to Object Oriented Analysis and Design
This document provides an overview of object-oriented analysis and design (OOAD). It discusses why OOAD is needed, the benefits it provides, and key concepts like objects, inheritance, polymorphism, encapsulation, cohesion/coupling, and design patterns. OOAD involves analyzing a problem domain to identify objects and their relationships, then designing a conceptual solution where objects collaborate through defined responsibilities and interfaces. The document emphasizes designing for comprehensibility, extensibility, and maintainability by following OO principles like information expert, pure fabrication, and high cohesion/low coupling.
Design Pattern lecture 3
The document outlines several structural design patterns including Adapter, Bridge, Composite, Decorator, Façade, Proxy, and Flyweight. It provides descriptions of what each pattern is, where it would be used, why it would be used, and how it works at a high level. For example, it states that the Adapter pattern enables a noncompliant interface to be used through an intermediary that manages an adaptation process to effect compliance. It is used when needing to integrate with a noncompliant interface or leverage another design's functionality. An intermediary class maps the desired functionality to the required target.
Restructuring
"Restructuring - Improving the modularity of an existing code-base" wurde als Vortrag vor der Java Usergroup Berlin-Brandenburg von Chris Chedgey von www.structure101.com gehalten.
2012 02-modularity-animated-120309090811-phpapp02
The document discusses restructuring code to improve modularity. It defines restructuring as reorganizing a codebase without modifying code to improve understandability. The author advocates using visualization tools like Levelized Structure Maps to understand a codebase's structure at a global level in order to divide it into coherent modules. Various restructuring strategies are presented, including merging parallel structures, busting large class tangles, and moving classes and packages to improve dependencies before further refactoring. The goal is to tackle complexity before modularity to make the codebase easier to comprehend and maintain.
Similar to Stoop 439-decorator (20)
Bridging the Divide between Architecture and Code (Germany JUGs version)
Bridging the Divide between Architecture and Code (Germany JUGs version)
Design patterns structuralpatterns(thedecoratorpattern)
Design patterns structuralpatterns(thedecoratorpattern)
Bridging the divide between architecture and code (US version)
Bridging the divide between architecture and code (US version)
Lessons Learned from Dockerizing Spark Workloads: Spark Summit East talk by T...
Lessons Learned from Dockerizing Spark Workloads: Spark Summit East talk by T...
Brief introduction to Object Oriented Analysis and Design
Brief introduction to Object Oriented Analysis and Design
More from The World of Smalltalk
05 seaside canvas
The document describes brush hierarchies and attributes for canvas and tags in HTML. It defines hierarchies for canvas, brushes and tags. It lists the factory selector, brush class and attribute accessors for various tag brushes. This includes div, fieldset, form inputs, buttons, tables and other tags. It provides the classes and methods to represent and manipulate these elements when building HTML documents.
99 questions
This document provides an overview of the key concepts in the Smalltalk programming language. It discusses how Smalltalk is a fully reflective, dynamic object-oriented programming environment. Smalltalk uses a simple uniform object model that allows for live, dynamic and interactive software development. The document outlines various Smalltalk basics like syntax, standard classes, coding idioms, debugging practices, design patterns and more. It also covers advanced topics like reflection and how the Smalltalk meta-model is reified through reflection.
13 traits
This document provides an overview of traits in programming. It discusses the limitations of single and multiple inheritance, as well as mixins. Traits are introduced as a way to share behavior across class hierarchies without these issues. Key points about traits are that they provide methods but no state, and classes have full control over trait composition. The document also presents a case study on refactoring stream classes using traits for improved reuse and design. It concludes with discussion on the implementation of traits in Pharo and potential future directions.
11 bytecode
This document provides an overview of working with bytecode in Pharo. It discusses:
- The Pharo compiler and how it translates code to an abstract syntax tree (AST), intermediate representation (IR), and finally bytecode.
- Generating bytecode using the IRBuilder tool, which allows defining bytecode instructions like stack operations, jumps, sends, and accessing variables.
- Parsing and interpreting bytecode using the InstructionStream hierarchy, which allows analyzing, printing, and decompiling bytecode.
10 reflection
Reflection allows programs to examine and modify their own structure and behavior at runtime. The document discusses introspection, which allows observing an object's state, and intercession, which enables modifying execution state. It covers reification, representing runtime concepts as objects, and how this enables metaprogramming to manipulate a running system. Key topics are reflective capabilities in various languages, structural versus behavioral reflection, and how reflection is implemented using metaobjects and metaclasses.
09 metaclasses
1. The document discusses metaclasses in Smalltalk and provides 7 key points about their structure and relationships.
2. Every class is an instance of a metaclass, and the metaclass hierarchy parallels the class hierarchy. The metaclass of every class inherits from Class.
3. Metaclasses inherit from Class and Behavior. The Metaclass represents metaclass behavior and its sole instance is the metaclass of every class.
07 bestpractice
This document discusses various best practice patterns for object-oriented programming in Smalltalk, including:
1. Naming conventions for classes, methods, variables and parameters to clearly indicate their purpose and role.
2. Using delegation to share implementation between classes without inheritance. Delegation patterns include simple delegation, self delegation, and reversing methods.
3. Double dispatch and method objects for handling multiple cases through message passing rather than conditionals.
4. Lazy initialization, caching, and conversion methods to optimize performance of expensive computations.
5. Patterns for collections, intervals and streams including comparing and ordering objects.
06 debugging
The document provides guidance on debugging in Smalltalk. It discusses common syntactic, semantic, and encapsulation errors. It also covers debugging patterns such as using print statements, tests, inspectors, breakpoints, and debuggers to debug code. The document emphasizes that the debugger, inspector, browser, and message name finder are useful debugging tools and that tests are important to prevent regressions when debugging. It also notes some best practices like avoiding modifying collections during iteration, using accessors to encapsulate state, and not referencing class names directly.
05 seaside
This document provides an overview of the Seaside web application framework. It discusses key Seaside concepts like components, control flow, composition, and more. The document contains lecture notes on Seaside, including roadmaps, explanations of concepts, code examples, and screenshots.
04 idioms
This document discusses Smalltalk coding idioms and best practices. It covers topics like:
- Using cascades and the "yourself" message to chain messages to the same receiver.
- Distributing responsibilities across many small, carefully named methods to promote reuse and maintainability.
- Techniques for initializing objects, establishing class invariants, and representing instance creation.
- Debugging techniques like printing an object's state.
The document provides code examples and explanations for common patterns in Smalltalk, such as initializing instance variables, creating collection objects, and defining constructor and accessor methods. It is intended as a guide for writing well-structured and maintainable Smalltalk code.
03 standardclasses
The document discusses Smalltalk standard classes. It covers the Object class which defines common behavior for all objects. Number classes are described, including automatic coercion between types. Strings and arrays are also covered, including literal and regular array creation. Variable types like global, instance, and block variables are explained. Control structures are implemented through message passing and blocks. Various collection classes are introduced at the end.
02 basics
Smalltalk is an object-oriented programming language where everything is an object and communication is done through message passing. The document discusses Smalltalk basics including its syntax, variables, methods, blocks, control structures and more. It provides a roadmap for learning Smalltalk and examples to illustrate Smalltalk concepts.
01 intro
This document provides an introduction to the Smalltalk programming language and environment. It outlines the course schedule and goals, which include learning about Smalltalk's history and object-oriented model, as well as concepts like classes, metaclasses, reflection, and advanced design patterns. The document discusses Smalltalk's origins at Xerox PARC and the key ideas it was influenced by. It also describes Smalltalk's pure object model where everything is an object that communicates through message passing. Finally, it provides an overview of the Smalltalk development environment and tools like the browser, debugger, and inspector.
Stoop sed-smells
This document discusses several basic design principles and smells:
- A class should have a single responsibility and minimize access to its data.
- Inheritance should represent an "is-a" relationship, not be used for implementation convenience.
- Methods should not expose implementation details and overuse of conversions should be avoided.
- Missing information should be handled gracefully rather than raising errors.
- Nil values should be avoided by returning empty collections instead.
- Objects rather than strings or tuples should be used to represent data.
- The tell-don't-ask principle of using polymorphism rather than conditionals on types should be followed.
- Encapsulation should be maintained by not overusing accessors and
Stoop sed-sharing ornot
The document discusses the design of the Scanner class in Smalltalk. It summarizes that the Scanner class has an instance variable (typeTable) and a class variable (TypeTable) that both refer to the type table object. The class variable TypeTable is used to initialize the type table once, while each scanner instance uses its own typeTable variable that can be customized if needed. This allows the type table to be shared and initialized only once, while also allowing instances to customize it if they want via copying the table.
Stoop sed-class initialization
The document discusses class initialization in object-oriented programming. It explains that class initialization is used to initialize class variables and instance variables when a class is loaded. The class initialization method, which in Squeak is named 'initialize', is automatically called by the system at load time or can be explicitly called by the programmer. It provides an example of a Date class initialization method that initializes various class variables with data like month names and numbers of days in each month.
Stoop ed-inheritance composition
The document discusses different approaches to structuring code for a text formatting editor, including inheritance, composition, and delegation. It notes some drawbacks of inheritance like difficulty changing policies at runtime and responsibility not being clear. Composition is recommended instead as it allows changing strategies at runtime, has clear responsibility between components, and avoids code bloat. Delegation to other objects using strategies is given as an example implementation.
Stoop ed-dual interface
This document discusses the concept of dual interfaces in object-oriented design, where a class has two types of clients - external clients and subclasses. It notes that making fields private prevents subclasses from accessing or modifying them directly, so protected accessors should be provided instead to empower subclasses while preventing direct field access by external clients. This dual interface approach benefits classes by controlling field access for clients but empowering subclasses.
More from The World of Smalltalk (18)
Recently uploaded
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Choosing The Best AWS Service For Your Website + API.pptx
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
National Security Agency - NSA mobile device best practices
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Artificial Intelligence for XMLDevelopment
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
5th LF Energy Power Grid Model Meet-up Slides
5th Power Grid Model Meet-up
It is with great pleasure that we extend to you an invitation to the 5th Power Grid Model Meet-up, scheduled for 6th June 2024. This event will adopt a hybrid format, allowing participants to join us either through an online Mircosoft Teams session or in person at TU/e located at Den Dolech 2, Eindhoven, Netherlands. The meet-up will be hosted by Eindhoven University of Technology (TU/e), a research university specializing in engineering science & technology.
Power Grid Model
The global energy transition is placing new and unprecedented demands on Distribution System Operators (DSOs). Alongside upgrades to grid capacity, processes such as digitization, capacity optimization, and congestion management are becoming vital for delivering reliable services.
Power Grid Model is an open source project from Linux Foundation Energy and provides a calculation engine that is increasingly essential for DSOs. It offers a standards-based foundation enabling real-time power systems analysis, simulations of electrical power grids, and sophisticated what-if analysis. In addition, it enables in-depth studies and analysis of the electrical power grid’s behavior and performance. This comprehensive model incorporates essential factors such as power generation capacity, electrical losses, voltage levels, power flows, and system stability.
Power Grid Model is currently being applied in a wide variety of use cases, including grid planning, expansion, reliability, and congestion studies. It can also help in analyzing the impact of renewable energy integration, assessing the effects of disturbances or faults, and developing strategies for grid control and optimization.
What to expect
For the upcoming meetup we are organizing, we have an exciting lineup of activities planned:
-Insightful presentations covering two practical applications of the Power Grid Model.
-An update on the latest advancements in Power Grid -Model technology during the first and second quarters of 2024.
-An interactive brainstorming session to discuss and propose new feature requests.
-An opportunity to connect with fellow Power Grid Model enthusiasts and users.
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
Ocean Lotus cyber threat actors represent a sophisticated, persistent, and politically motivated group that poses a significant risk to organizations and individuals in the Southeast Asian region. Their continuous evolution and adaptability underscore the need for robust cybersecurity measures and international cooperation to identify and mitigate the threats posed by such advanced persistent threat groups.
Taking AI to the Next Level in Manufacturing.pdf
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
How to Get CNIC Information System with Paksim Ga.pptx
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
20240609 QFM020 Irresponsible AI Reading List May 2024
Everything I found interesting about the irresponsible use of machine intelligence in May 2024
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays, June 2024 with Maria Copot 20
Programming Foundation Models with DSPy - Meetup Slides
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
TrustArc Webinar - 2024 Global Privacy Survey
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Recently uploaded (20)
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
AI 101: An Introduction to the Basics and Impact of Artificial Intelligence
National Security Agency - NSA mobile device best practices
National Security Agency - NSA mobile device best practices
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
Ocean lotus Threat actors project by John Sitima 2024 (1).pptx
How to Get CNIC Information System with Paksim Ga.pptx
How to Get CNIC Information System with Paksim Ga.pptx
20240609 QFM020 Irresponsible AI Reading List May 2024
20240609 QFM020 Irresponsible AI Reading List May 2024
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
Stoop 439-decorator
- 1. S.Ducasse 1 QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture. Stéphane Ducasse Stephane.Ducasse@univ-savoie.fr http://www.listic.univ-savoie.fr/~ducasse/ Decorator
- 2. S.Ducasse 2 License: CC-Attribution-ShareAlike 2.0 http://creativecommons.org/licenses/by-sa/2.0/
- 3. S.Ducasse 3 Decorator • Attach additional responsib • ilities to an object dynamically. • Decorators provide a • flexible alternative to • subclassing for extending • functionality. • Aka:Wrapper
- 4. S.Ducasse 4 Decorator Intent • Attach additional responsib ilities to an object dynamically. • Decorators provide a flexible alternative to • subclassing for extending functionality. • Aka:Wrapper
- 5. S.Ducasse 5 Motivation • Adding behavior to individual object not entire class • scrollbar • border
- 6. S.Ducasse 6 Inheritance? • Does not work well • Too much combination border, color, scrollbars, bounds, translation... • To static: Clients cannot control when to put a border or not...
- 7. S.Ducasse 7 Decorator • Enclose the component into another one that adds border...in another one that adds scrollbar... • The decorator conforms to the interface of the component it decorates so that its presence is transparent to the component's clients. • The decorator forwards requests to the component and may perform additional actions (such as drawing a border) before or after forwarding
- 9. S.Ducasse 9 Applicability • When responsibilities can be withdrawn • When responsibilities can be added transparently • When subclassing is not possible (combination explosion)
- 10. S.Ducasse 10 Possible Decorator Structure
- 11. S.Ducasse 11 Participants • Component (VisualComponent) • defines the interface for objects that can have responsibilities added to them dynamically. • ConcreteComponent (TextView) • defines an object to which additional responsibilities can be attached. • Decorator • maintains a reference to a Component object and defines an interface that conforms to Component's interface. • ConcreteDecorator (BorderDecorator, ScrollDecorator) • adds responsibilities to the component.
- 12. S.Ducasse 12 Collaborations • Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.
- 13. S.Ducasse 13 About Identity • A decorator and its component aren't identical. • A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. • If the decorator is wrapping, then identity of the object may change. • Good at construction time, but else should “adapt” the references from the decorated to the decorator.
- 14. S.Ducasse 14 Consequences • More flexibility than static inheritance. Dynamic addition of properties • Avoids feature-laden classes high up in the hierarchy. • Lots of little objects.
- 15. S.Ducasse 15 Implementation • Interface conformance. A decorator object's interface must conform to the interface of the component it decorates. ConcreteDecorator classes must therefore inherit from a common class (at least in C++). • Omitting the abstract Decorator class. There's no need to define an abstract Decorator class when you only need to add one responsibility. • Keeping Component classes lightweight. Component should specify an interface, decorators are then easier to define
- 16. S.Ducasse 16 Wrapping or not? Conforming or not • With decorator • With strategies
- 17. S.Ducasse 17 Strategies? • Strategies are a better choice when the Component class is heavyweight, thereby making the Decorator pattern too costly to apply. • The Strategy-based approach might require modifying the component to accommodate new extensions. • a strategy can have its own specialized interface, • a decorator's interface must conform to the component's. • A strategy needs only define the interface for rendering a border, which means that the strategy can be lightweight even if the Component class is heavyweight.
- 18. S.Ducasse 18 Known Uses • VisualWorks Wrapper hierarchy • Stream Decorators inVisualWorks: • BOSSTransporter is a stream decorator • FormattedStream is a stream decorator