The document discusses object oriented design (OOD) and its advantages over procedural design. It covers key OOD principles like encapsulating state and behavior within objects, separating interfaces from implementations, and designing around solutions instead of problems. The document uses examples like modeling colors as an enum versus objects to illustrate OOD concepts and how it can help address changes in requirements.
Sterling Barton Movemements of a Hypnotic NatureBrent Barton
This presentation focuses on an exercise the helps us understand emergent design, iterations (if you only touch it once, you are not iterating), teamwork and operating from high-level requirements. This is based on cross-functional, self-organizing teams and overlapping development phases that are the roots of Scrum
Invincible React States with Domain Driven Design Prateek
The presentation for the talk on the use of Domain-Driven Design for creating react states that speak the language of the business.
This talk was a part of React Day Bangalore.
Sterling Barton Movemements of a Hypnotic NatureBrent Barton
This presentation focuses on an exercise the helps us understand emergent design, iterations (if you only touch it once, you are not iterating), teamwork and operating from high-level requirements. This is based on cross-functional, self-organizing teams and overlapping development phases that are the roots of Scrum
Invincible React States with Domain Driven Design Prateek
The presentation for the talk on the use of Domain-Driven Design for creating react states that speak the language of the business.
This talk was a part of React Day Bangalore.
The presentation contain the Thinking about Thinking and Language.
The process of thinking, types, problem solving, various bias, linguistic theories of thinking are included.
Solving a “Transportation Planning” Problem through the Programming Language “C”Shahadat Hossain Shakil
Solving a “Transportation Planning” problem through the programming language “C”
Presented by
Yousuf Mahid (0615012)
Shahadat Hossain Shakil (0615020)
Khadija Akhter (0615027)
Visualization of Hajime Yoshino’s Logical Jurisprudence. IRIS 2017Vytautas Čyras
Presentation to publication In: E. Schweighofer, F. Kummer, W. Hötzendorfer, C. Sorge (eds.) Trends and Communities of Legal Informatics. Proceedings of the 20th International Legal Informatics Symposium IRIS 2017, 23–25 February 2017, Salzburg, pp. 349–358. OCG, Vienna. ISBN 978-3-903035-15-7. Also in online journal Jusletter IT, Die Zeitschrift für IT und Recht, 23 February 2017, ISSN 1664-848X, Editions Weblaw, http://jusletter-it.weblaw.ch/issues/2017/IRIS.html. (Peer reviewed – Jury LexisNexis Best Paper Award IRIS2017).
ABSTRACT. Hajime Yoshino’s Logical Jurisprudence (LJ) is an important concept in legal infor-matics. Yoshino aims for a logic-based systematization in the legal domain. He focuses on legal reasoning and systematization. Inevitably, embracing law as a whole brings us to Hans Kelsen’s Pure Theory of Law. In sum, three issues are important in LJ: logic, Kelsen and legal informatics. In this paper we aim to visualize the architecture of LJ. We suggest expanding this with legal ontologies and words. The granularity of word-phrase-sentence-text is about different methods which apply to different units.
In Actors system, we can change State or Behaviors during runtime in actors. There are multiple ways for changing behaviors like conditional based and Hotswap but Finite State Machine(FSM) is the cleanest way. If we have finite number of state in our system then FSM is the good practice.
The objective is to explain how a software design may be represented as a set of interacting objects that manage their own state and operations and to introduce various models that describe an object-oriented design.
Finite State Machines are overlooked at best, ignored at worst, and virtually always dismissed. This is tragic since FSMs are not just about Door Locks (the most commonly used example). On the contrary, these FSMs are invaluable in clearly defining communication protocols – ranging from low-level web-services through complex telephony application to reliable interactions between loosely-coupled systems. Properly using them can significantly enhance the stability and reliability of your systems.
Join me as I take you through a crash-course in FSMs, using erlang’s gen_fsm behavior as the background, and hopefully leaving you with a better appreciation of both FSM and erlang in the process.
It is a mathematical modelling of computation that is extensively used for designing both computer programs as well as sequential logic circuits and can be perceived as an intellectual machine in one of a finite number of states. Copy the link given below and paste it in new browser window to get more information on Finite State Machine:- http://www.transtutors.com/homework-help/computer-science/finite-state-machines.aspx
The presentation contain the Thinking about Thinking and Language.
The process of thinking, types, problem solving, various bias, linguistic theories of thinking are included.
Solving a “Transportation Planning” Problem through the Programming Language “C”Shahadat Hossain Shakil
Solving a “Transportation Planning” problem through the programming language “C”
Presented by
Yousuf Mahid (0615012)
Shahadat Hossain Shakil (0615020)
Khadija Akhter (0615027)
Visualization of Hajime Yoshino’s Logical Jurisprudence. IRIS 2017Vytautas Čyras
Presentation to publication In: E. Schweighofer, F. Kummer, W. Hötzendorfer, C. Sorge (eds.) Trends and Communities of Legal Informatics. Proceedings of the 20th International Legal Informatics Symposium IRIS 2017, 23–25 February 2017, Salzburg, pp. 349–358. OCG, Vienna. ISBN 978-3-903035-15-7. Also in online journal Jusletter IT, Die Zeitschrift für IT und Recht, 23 February 2017, ISSN 1664-848X, Editions Weblaw, http://jusletter-it.weblaw.ch/issues/2017/IRIS.html. (Peer reviewed – Jury LexisNexis Best Paper Award IRIS2017).
ABSTRACT. Hajime Yoshino’s Logical Jurisprudence (LJ) is an important concept in legal infor-matics. Yoshino aims for a logic-based systematization in the legal domain. He focuses on legal reasoning and systematization. Inevitably, embracing law as a whole brings us to Hans Kelsen’s Pure Theory of Law. In sum, three issues are important in LJ: logic, Kelsen and legal informatics. In this paper we aim to visualize the architecture of LJ. We suggest expanding this with legal ontologies and words. The granularity of word-phrase-sentence-text is about different methods which apply to different units.
In Actors system, we can change State or Behaviors during runtime in actors. There are multiple ways for changing behaviors like conditional based and Hotswap but Finite State Machine(FSM) is the cleanest way. If we have finite number of state in our system then FSM is the good practice.
The objective is to explain how a software design may be represented as a set of interacting objects that manage their own state and operations and to introduce various models that describe an object-oriented design.
Finite State Machines are overlooked at best, ignored at worst, and virtually always dismissed. This is tragic since FSMs are not just about Door Locks (the most commonly used example). On the contrary, these FSMs are invaluable in clearly defining communication protocols – ranging from low-level web-services through complex telephony application to reliable interactions between loosely-coupled systems. Properly using them can significantly enhance the stability and reliability of your systems.
Join me as I take you through a crash-course in FSMs, using erlang’s gen_fsm behavior as the background, and hopefully leaving you with a better appreciation of both FSM and erlang in the process.
It is a mathematical modelling of computation that is extensively used for designing both computer programs as well as sequential logic circuits and can be perceived as an intellectual machine in one of a finite number of states. Copy the link given below and paste it in new browser window to get more information on Finite State Machine:- http://www.transtutors.com/homework-help/computer-science/finite-state-machines.aspx
Product lessons from the launch of Unified Search, a massive redesign of LinkedIn's search experience, presented at the Stanford Graduate School of Business High Tech Club on May 16, 2014
Agile projects embrace changes and apply techniques to make these changes easy to be done. But not for the architecture! This talk presents techniques to manage and sustain the architecture, enabling it to evolve during the project and support innovation by adopting new technologies. A concrete example will be shown to illustrate the approach.
Why Agile is incompatible with Matrix organizations, the collateral damage that Matrix organizations exert on their projects and products, and how to break these things. Some highlights: Cross-functional teams, Tuckman's Stages of Team Formation, Test Automation Pyramid.
I've given this talk at the Agile Network India meetup on 2019-07-27.
This presentation tries to discuss the benefits of modularization and what it could bring to our apps. The sample code used for the demo can be found here: https://gitlab.com/kuuuurt/modularization-sample-marvel-characters
Case Study - Rescuing a Troubled Project C.A. McCall-Peat Liberty Li.pdfsales88
Case Study - Rescuing a Troubled Project C.A. McCall-Peat Liberty Life, Johannesburg, South
Africa P.O. Box 10499, Johannesburg, 2000, South Africa, telephone +27 11 408-3687, fax +27
11 408-3650, email: c..t@liberty.co.za Summary This case study outlines a troubled project and
the issues faced by the project. The case study attendees are asked to analyze the project
information provided and to recommend courses of action to bring the project back on track.
Attendees are also asked to suggest actions that could be taken on future similar projects to
mitigate encountering similar problems. The key lessons learnt could be applied by other
organizations to avoid common pitfalls which result in projects going off track, as well as
knowing the telltale signs of troubled projects and actions to take to bring them back on track.
This is an interactive session, which utilizes group discussion to facilitate the adult learning
experience. Background A leading financial services company embarked on a new product
development project. The nature of the company's business is that it operates in an extremely
competitive environment that necessitates fast delivery to market so as to prevent competitor
companies from gaining dominant market share with similar competitive products. The key
success factors of the project were, therefore, time to market and quality. Cost of delivery was
not a major concern. Scope The scope of the project was to make a new investment product,
including the systems changes, the policy documents, marketing launch material, and the
administrative user training. The project was divided into sub-projects consisting of: Systems,
Marketing, Training, and Legal. A project manager was appointed, as well as sub-project co-
coordinators. Time Scales The launch date was set as 1 June 2002. The product had to be ready
for launch on this date, as all the marketing material would reflect this date and the launch had to
precede the launch of similar products from competitors. The project start date was 3 December
2001. The tasks that had been completed prior to 3 December were the Business Case
compilation and approval and the project team establishment. Technology The systems
development was to be done using the Java programming language and environment, which was
new to the development team. The developers were sent on Java programming training 2 weeks
prior to the project start. The developers were used to working in a COBOL programming
environment and had not worked with any object-oriented languages before. Case Study
Summary of Events Business Case Development The Product Development Department
developed the Business Case for the proposed new product, including projected cost/benefit
analysis based on previous similar products and current market share. The Business Case was
reviewed by Executive Management and approved. Requirements Definition The Product
Development Department developed the requirements specification for the new product. .
Github Copilot and tools that help us code better are cool. But I’m lucky if I spend 90 minutes a day writing code. We really need to optimize the hours we spend reviewing code, updating tickets and tracing where our code is deployed. Learn how I save an hour a day streamlining non-coding tasks.
This talk is unique because 99% of developer productivity tools and hacks are about coding faster, better, smarter. And yet the vast majority of our time is spent doing all of this other stuff. After I started focusing on optimizing the 10 hours I spend every day on non-coding tasks, I found I my productivity went up and my frustration at annoying stuff went way down. I cover how to save time by reducing cognitive load and by cutting menial, non-coding tasks that we have to perform 10-50 times every day. For example:
Bug or hotfix comes through and you want to start working on it right away so you create a branch and start fixing. What you don’t do is create a Jira ticket but then later your boss/PM/CSM yells at your due to lack of visibility. I share how I automated ticket creation in Slack by correlating Github to Jira.
You have 20 minutes until your next meeting and you open a pull request and start a review. But you get pulled away half way through and when you come back the next day you forgot everything and have to start over. Huge waste of time. I share an ML job I wrote that tells me how long the review will take so I can pick PRs that fit the amount of time I have.
You build. You ship it. You own it. Great. But after I merge my code I never know where it actually is. Did the CI job fail? Is it release under feature flag? Did it just go GA to everyone? I share a bot I wrote that personally tells me where my code is in the pipeline after it leaves my hands so I can actually take full ownership without spending tons of time figuring out what code is in what release.
Similar to Object Oriented Design And Programing (20)
Template driven code generation tool, fore real time and safety critical systems.
API message formating and serialisation.
Template driven source code generator for any language : Ada, C, C#, Java, ...
Template driven code generation tool, fore real time and safety critical systems.
API message formating and serialisation.
Template driven source code generator for any language : Ada, C, C#, Java, ...
Template driven code generation tool, fore real time and safety critical systems.
API message formating and serialisation.
Template driven source code generator for any language : Ada, C, C#, Java, ...
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
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.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
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.
3. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
3
1
4. Changes Request : flexible solution
Productive
Initial Request programmer
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
4
5. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
5
6. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Unproductive
programmer
1 Week 1 Day
After After
31/03/03
6
7. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Few Weeks Later
Unproductive
programmer
1 Week 1 Day
After After
31/03/03
7
8. Changes Request : flexible solution
Productive
Unproductive
Initial Request Evolution
programmer
programmer
Request
1 Day
After
Few Weeks Later
1 Week 1 Day
After After
31/03/03
8
9. Changes Request : flexible solution
Unproductive
Initial Request Evolution
programmer
Request
1 Day
After
Few Weeks Later
Productive
programmer
1 Week 1 Day
After After
31/03/03
9
10. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
10
1
11. Changes Sources During Development
Requirements :
Customers Discover What they Really Want During or at the
End of Developments
Technology
Performances Are Increasing With Time
Skill
We Learn and Understand the Problem and We Discover
the Right Solution on the Job
Short Term Politic
No Comments
31/03/03
11
12. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
12
1
13. program in the future tense.
Initial Request
Present tense 1 Day
programming After Short term
1 Week Medium to long term
Future tense
programming After
31/03/03
13
14. program in the future tense.
Initial Request Evolution Request
Present tense 1 Day
programming After
Few Weeks Later
Future tense 1 Week 1 Day
programming After After
31/03/03
14
15. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
15
1
16. Object VS Procedural
Procedural
The code solution “structure” is the problem
“structure”.
When problems “changes” the code structure
changes.
Object
The solution is based on integration and
collaboration of independent entities (component).
An entity is a code subset.
Integration and Collaboration are managed by tools
(compiler).
When the problems “changes” the collaboration
31/03/03
scheme changes not entity’s code.
16
17. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
17
1
18. User Input
Operation:
A: Addition
B: Subtraction
C: Division
E: Multiplication
Enter a choice =>
31/03/03
18
19. User Input
Operation: Addition
A: First Integer
B: Second Integer
Enter a choice =>
31/03/03
19
20. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
20
1
21. Procedural Programming
Character
Imput CH
case
CH = A CH = B CH = C
Procedure A () Procedure B () Procedure C()
case
Proc A1() Proc A2() Proc A3() Character Character
Input CH Input CH
case case
Character CH = 1 CH = 2 CH = 3 CH = 1 CH = 2
Input CH
case
CH = 1 CH = 2 CH = 3 Proc d () Proc e () Proc f () Proc g () Proc h ()
Proc a () Proc b () Proc c ()
31/03/03
21
22. Hierarchical Programming
Tapez un nom ici
Tapez un titre de fonction ici
Tapez un nom ici Tapez un nom ici Tapez un nom ici
Tapez un titre de fonction ici Tapez un titre de fonction ici Tapez un titre de fonction ici
31/03/03
22
23. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
23
1
24. User Input : Operation in R and C
Operation:
A: Real
B: Complex
Enter a choice =>
31/03/03
24
25. User Input
Operation: Complex Addition
A: First Number real part
B: First Number imaginary part
C: Second Number real part
D: Second Number imaginary part
Enter a choice =>
31/03/03
25
26. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
26
27. Changes Request : flexible solution
Initial Request Evolution Request
1 Day Few Weeks Later
After
1 Week 1 Day
After After
31/03/03
27
31. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
31
1
35. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
35
1
36. Object Paradigm
GOF definition for object: A run-time entity that packages both data and the
procedures that operate on that data.
Object
Object
Data Operation
Operation
Operation
Operation
Operation
Operation
Operation
Operation
Attribute Interfaces
31/03/03
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
36 Design Patterns: Elements of Reusable Object-Oriented Software.
37. Object Paradigm
GOF definition for object: A run-time entity that packages both data and the
procedures that operate on that data.
UML class
Object
Object
Name
Data Operation
Operation Operation
Operation
Operation
Operation Operation
Operation
Operation
Operation Attribute
Operation
Operation
Attribute Interfaces
UML:
31/03/03
Unified Modelling Language
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
37 Design Patterns: Elements of Reusable Object-Oriented Software.
38. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
38
39. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
39
40. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
40
46. OOD hides the problem space
With OOD likely to change aspects are encapsulated
and hidden to other objects.
How and What are separated
The problem : What
The solution : How
31/03/03
46
47. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
47
1
48. The problem is in the User Input
Colour
A: Black,
B: Brown,
C: Red,
D: Orange,
E: Yellow,
F: Green,
G: Blue,
Enter a colour =>
31/03/03
48
49. Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
}
31/03/03
49
50. structural switch
static void printsColor(int Value) {
switch(Value) {
case Black :
processing 1
case Brown:
processing 2
case Red:
processing 3
case Orange:
processing 4
case Yellow:
processing 5
case Green:
processing 6
case Blue:
processing 7
31/03/03
}
}
50
51. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3 static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4 switch(status) {
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5 case NIL_EXIT_STATE :
processing 2 case COORDINATION_TERMINATED, processing 1
case FLIGHT_ACTIVATION_ALARM: processing 6 case FLIGHT_ACTIVATION_PROPOSAL:
processing 3 case UNKNOWN_EXIT_STATE processing 2
case FLIGHT_ACTIVATION_CONFIRMED: processing 7 case FLIGHT_ACTIVATION_ALARM:
processing 4 } processing 3
case HANDOVER_TRANSFERED, } case FLIGHT_ACTIVATION_CONFIRMED:
processing 5 processing 4
case COORDINATION_TERMINATED, case HANDOVER_TRANSFERED,
processing 6 processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Software
}
}
Software Module B
Module A Software
Module D
static void flightUpdate(int status) {
Software Software
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
31/03/03
}
}
51
52. The problem space and the solution space.
If the switch value reflects the problem for example user
inputs.
When the user request new case you have to change
everywhere you use the switch value.
31/03/03
52
53. Example 3: The problem is in the User Input
Colour
A: Black,
B: Brown,
C: Red,
D: Orange,
E: Yellow,
F: Green,
G: Blue,
H: NewColor,
Enter a colour =>
31/03/03
53
54. Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
NewColor,
}
31/03/03
54
55. structural switch
static void printsColor(int Value) {
switch(Value) {
case Black :
processing 1
case Brown:
processing 2
case Red:
processing 3
case Orange:
processing 4
case Yellow:
processing 5
case Green:
processing 6
case Blue:
processing 7
case NewColor,
31/03/03
processing 7
}
55 }
56. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5
processing 2 case COORDINATION_TERMINATED, static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_ALARM: processing 6
processing 3 case UNKNOWN_EXIT_STATE switch(status) {
case FLIGHT_ACTIVATION_CONFIRMED: processing 7
processing 4 } case NIL_EXIT_STATE :
case HANDOVER_TRANSFERED, } processing 1
processing 5 case FLIGHT_ACTIVATION_PROPOSAL:
case COORDINATION_TERMINATED, processing 2
processing 6 case FLIGHT_ACTIVATION_ALARM:
case UNKNOWN_EXIT_STATE processing 3
processing 7 case FLIGHT_ACTIVATION_CONFIRMED:
} processing 4
} case HANDOVER_TRANSFERED,
Software
processing 5
case COORDINATION_TERMINATED,
processing 6
case UNKNOWN_EXIT_STATE
Module B
processing 7
}
Software
}
Module A Software
Module D
static void flightUpdate(int status) {
Software Software
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Changes
31/03/03
}
}
56
57. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5
processing 2 case COORDINATION_TERMINATED, static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_ALARM: processing 6
processing 3 case UNKNOWN_EXIT_STATE switch(status) {
case FLIGHT_ACTIVATION_CONFIRMED: processing 7
processing 4 } case NIL_EXIT_STATE :
case HANDOVER_TRANSFERED, } processing 1
processing 5 case FLIGHT_ACTIVATION_PROPOSAL:
case COORDINATION_TERMINATED, processing 2
processing 6 case FLIGHT_ACTIVATION_ALARM:
case UNKNOWN_EXIT_STATE processing 3
processing 7 case FLIGHT_ACTIVATION_CONFIRMED:
} processing 4
} case HANDOVER_TRANSFERED,
Software
processing 5
case COORDINATION_TERMINATED,
processing 6
case UNKNOWN_EXIT_STATE
Module B
processing 7
}
Software
}
Module A Software
Module D
Software Software
Spaghetti Plate
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Changes
31/03/03
}
}
57
58. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
58
59. Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
59
67. Polymorphism
Print()
Client Color
+print()
31/03/03
67
68. Polymorphism
Print()
Client Color
+print()
Black
+ print()
31/03/03
68
69. Code of the Black object print() operation
class Black extends Color
{
public void print()
{
System.out.println( quot; Black quot;); }
}
31/03/03
69
70. Polymorphism
Print()
Client Color
+print()
Black Brown
+ print() + print()
31/03/03
70
71. Code of the Brown object print() operation
class Brown extends Color
{
public void print()
{
System.out.println( quot; Brown quot;); }
}
31/03/03
71
72. Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
72
73. Code of the Red object print() operation
class Red extends Color
{
public void print()
{
System.out.println( quot; Red quot;); }
}
31/03/03
73
74. Code of the Blue object print() operation
class Blue extends Color
{
public void print()
{
System.out.println( quot; Blue quot;); }
}
31/03/03
74
75. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
75
1
76. Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
76
77. Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown Red Blue
+ print() + print() + print() + print()
newColor
31/03/03
+ print()
77
78. Code of the Blue object print() operation
class NewColor extends Color
{
public void print()
{
System.out.println( quot; NewColor quot;); }
}
31/03/03
78
79. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
79
1
80. GOF
GoF stand for Gang of Four.
It refers to the pattern seminal book of John Vlissides,
Erich Gamma, Richard Helm, Ralph Johnson:
Title: Design Patterns: Elements of Reusable Object-
Oriented Software.
31/03/03
80
82. Design Pattern GOF Definition
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.
31/03/03
82
83. Why Design Pattern ?
Because we want to use polymorphism to manage
the changes
But it is very difficult to find the object class lattice
which leads to polymorphism
Design pattern Language is a catalogue of object
class lattices which handle a certain problem with
polymorphism.
31/03/03
83
84. What to Expect from Design Patterns
A Common Design Vocabulary
A Documentation and Learning Aid
An Adjunct to Existing Methods
A Target for Refactoring
Anti pattern are also useful.
31/03/03
84
89. What to Expect from Design Patterns
A Common Design Vocabulary
A Documentation and Learning Aid
An Adjunct to Existing Methods
A Target for Refactoring
Anti pattern are also useful.
31/03/03
89
90. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
90
1
91. The GOF Abstract Factory Design Pattern
*GoF stand for Gang of Four. It refers to the famous books of John Vlissides, Erich Gamma, Richard Helm,
31/03/03
Ralph Johnson. Design Patterns: Elements of Reusable Object-Oriented Software.
91
92. Factory Pattern
Print()
Client Color
+print()
UNKNOWN_EXIT
Black Brown Red _STATE
+ print() + print() + print() + print()
ColorFactory
31/03/03
+ create()
92
93. Factory Pattern
The switch is now hidden in the object state factory.
The factory returns a new object of the right derived
class by using a switch case on the state integer
code.
The client always sees the root class object type
Color.
Each state object know how to manage client
invocation in its case.
31/03/03
93
94. Factory pseudo code
static color create(int Color) {
switch(Color) { New Object
case Black :
return color = new black();
break;
case Brown:
return color = new brown();
break;
case Red:
return color = new red();
break;
case Orange :
return color = new Orange();
break;
case Yellow:
return color = new Yellow();
break;
case Green :
return color = new Green();
break;
case Blue :
31/03/03
return color = new Blue();
}
}
94
95. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
95
1
96. Dynamic Polymorphism
Static polymorphism (Factory)
State machine
Pattern State creates one object for each state and
uses polymorphism to enable transparent client
invocation.
Dynamic Polymorphism
31/03/03
96
97. State Pattern (from the GoF)
31/03/03
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
Design Patterns: Elements of Reusable Object-Oriented Software.
97
104. State model transformation
Client HelloContext Color
Request() Handle()
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10
105. State model transformation
Client HelloContext Color
Request() Handle()
Context
Concrete state
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10
106. Polymorphism and state patterns
If we have an object which state can change during
its lifetime and we have to perform different
operations according to the object state we use the
pattern state.
pattern State avoids switch even if the state of the
object is changing
pattern State creates one object for each state and
uses polymorphism to enable transparent client
invocation.
31/03/03
10
107. Objective
State pattern avoid structural switch
No enumeration in Java
An enumeration may be managed as a state
machine.
31/03/03
10
108. Next step
Model Driven Development
Code generation
31/03/03
10
109. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
10
110. Object Oriented Design (OOD)
in software industry
The second order polynomial example
Emmanuel FUCHS
111. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
11
137. Checks Roots Interval : procedural solution
Discriminat
Sign
>0 <0
=0
Computes root case 1 Computes roots case 2 2
T F T F
( /X1/ <= X & X <=
X == X1
/X2/ )
Return True Return False Return True Return False Return False
End
31/03/03
13
138. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
13
139. Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
13
141. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
14
142. First Object Model : Domain Model
Second Order
Polynomial
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
31/03/03
14
143. First Object Model : Domain Model
Second Order
Polynomial Discriminant
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
31/03/03
14
144. First Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
14
145. Design Model Creation without Factory
Second Order
Polynomial
computeRoots()
create()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
14
146. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
14
147. Domain Model
Second Order Discriminant
Polynomial
31/03/03
14
148. Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory create
Discriminant
31/03/03
14
149. Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory
Discriminant
31/03/03
14
150. First Design Model with operation
Second Order
Polynomial
Double a
Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
151. Discriminant
class Discriminant {
private double delta;
public Discriminant (double a, double b, double c) {
delta = (b * b) - (4.0 * a * c);
}
public double value () {
return delta;
}
}
31/03/03
15
152. Factory: Initial Requirements
static Polynome create( double a, double b, double c) {
Discriminant theDiscriminant = new Discriminant(a,b,c);
double delta = theDiscriminant.value();
Polynome polynome;
if (delta == 0.0) {
return polynome = new SingleRootPolynome(a,b,c,theDiscriminant) ;
}
else if (delta > 0.0) {
return polynome = new TwoRootsPolynome(a,b,c,theDiscriminant) ;
}
else {
return polynome = new NoRootPolynome(a,b,c,theDiscriminant);
}
}
31/03/03
15
153. Factory 1° Requirements Change
static Polynome create( double a, double b, double c) {
Discriminant theDiscriminant = new Discriminant(a,b,c);
double delta = theDiscriminant.value();
Polynome polynome;
if (delta == 0.0) {
return polynome = new SingleRootPolynome(a,b,c,theDiscriminant) ;
}
else if (delta > 0.0) {
return polynome = new TwoRootsPolynome(a,b,c,theDiscriminant) ;
}
else {
return polynome = new ComplexRootsPolynome(a,b,c,theDiscriminant);
}
}
31/03/03
15
154. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
15
155. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
156. Computes root : Single Root Polynomial
void computesRoots() {
System.out.println (quot; Single root: quot;);
System.out.println (quot; x = quot; + (-b / (2.0*a)));
}
31/03/03
15
157. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
159. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
160. Computes root : No Root Polynomial
void computesRoots() {
System.out.println (quot; No rootsquot;);
}
31/03/03
16
161. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
16
162. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
16
163. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots Complex Roots
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
16