Of the SOLID principles, made famous by Robert C. Martin, we'll discuss the Single Responsibility Principle and the Open/Closed Principle, two of the presenter's favorite principles. But at the same time the least understood and used principles. That's why this session will explain them thoroughly and give real life examples instead of the regular customer & order examples. You'll walk away knowing what the benefits are and how to use them properly.
=============================
THIS PRESENTATION IS OUTDATED
See a newer version here: http://www.slideshare.net/openservices/introduction-to-oslc-and-linked-data
===================================
An introduction to Open Services for Lifecycle Collaboration (OSLC):
- The OSLC community
- Linked Data and RDF
- OSLC specifications
Of the SOLID principles, made famous by Robert C. Martin, we'll discuss the Single Responsibility Principle and the Open/Closed Principle, two of the presenter's favorite principles. But at the same time the least understood and used principles. That's why this session will explain them thoroughly and give real life examples instead of the regular customer & order examples. You'll walk away knowing what the benefits are and how to use them properly.
=============================
THIS PRESENTATION IS OUTDATED
See a newer version here: http://www.slideshare.net/openservices/introduction-to-oslc-and-linked-data
===================================
An introduction to Open Services for Lifecycle Collaboration (OSLC):
- The OSLC community
- Linked Data and RDF
- OSLC specifications
This presentation focus on the S.O.L.I.D. software engineering principles for object-oriented design. We will see and discuss the rule-set with simple examples. S.O.L.I.D. stands for
S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle
Beyond design patterns and principles - writing good OO codeMatthias Noback
Of course, you should read all you can about SOLID, Design patterns, Patterns of Enterprise Application Architecture, etc. Once you have a basic understanding of these topics you still have to write that code though, and write it well too! What is good code? Are there some guidelines, or rules of thumb, which you can follow while making your everyday coding decisions?
In this talk I’ll cover many of these coding guidelines, which aren’t usually covered by patterns or principles books. They should help you write better code and give you a richer vocabulary for reviewing other people’s code. Some of the subjects that we’ll discuss are: state, mutability, CQS, one-method objects, domain-first, API-driven, functional programming influences, object boundaries, (de)serialization, and many more!
Ever heard of the Law of Demeter? How about the Liskov Substitution Principle? This talk introduces key object-oriented laws and principles currently used in our field and provides guidance for their use when building applications on the .NET platform.
The presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of Object Oriented Design. These are 5 principles compiled by Rober Cecil Martin aka Uncle Bob. The benefit of these principles is to achieve a good OO design which is high in cohesion and low in coupling thus easily adaptable to change
In the mobile app development community a well-known issue is the problem of growing codebases.
Balazs Kovacs, our Chief Solution Architect gave a presentation on a budapest.mobile event about our take on mobile app architectures.
Contents:
- History
- Problems / Requirements
- Our Solution
- Pros & Cons
- Tools
- Lessons learnt
A presentation by Supercharge
www.supercharge.io
Development principles in test automation!David Baak
Test automation is a prominent part of testing. To further improve our test automation we should look at development practices. One important practice to improve the maintainability of the test automation is to create clean code. Recognizing clean code is quite easy. If it reads like prose and you understand the intent (almost) immediately while you are not the author, then it’s probably clean. However, writing clean code is difficult. This presentation gives you pointers on how to create readable code by using proper naming and refactoring.
This course provides a detailed introduction to the Object Oriented techniques identified by Robert Martin as the SOLID principles of software design. Intended for both novice and intermediary developers, each of the five principles are fully defined and explored. Real-world coding examples are provided for each software tenant to help fully expound upon the design techniques. By the end of the session, developers will be able to identify common code smells while applying SOLID programming practices that ensure clean and maintainable code.
This presentation focus on the S.O.L.I.D. software engineering principles for object-oriented design. We will see and discuss the rule-set with simple examples. S.O.L.I.D. stands for
S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle
Beyond design patterns and principles - writing good OO codeMatthias Noback
Of course, you should read all you can about SOLID, Design patterns, Patterns of Enterprise Application Architecture, etc. Once you have a basic understanding of these topics you still have to write that code though, and write it well too! What is good code? Are there some guidelines, or rules of thumb, which you can follow while making your everyday coding decisions?
In this talk I’ll cover many of these coding guidelines, which aren’t usually covered by patterns or principles books. They should help you write better code and give you a richer vocabulary for reviewing other people’s code. Some of the subjects that we’ll discuss are: state, mutability, CQS, one-method objects, domain-first, API-driven, functional programming influences, object boundaries, (de)serialization, and many more!
Ever heard of the Law of Demeter? How about the Liskov Substitution Principle? This talk introduces key object-oriented laws and principles currently used in our field and provides guidance for their use when building applications on the .NET platform.
The presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of Object Oriented Design. These are 5 principles compiled by Rober Cecil Martin aka Uncle Bob. The benefit of these principles is to achieve a good OO design which is high in cohesion and low in coupling thus easily adaptable to change
In the mobile app development community a well-known issue is the problem of growing codebases.
Balazs Kovacs, our Chief Solution Architect gave a presentation on a budapest.mobile event about our take on mobile app architectures.
Contents:
- History
- Problems / Requirements
- Our Solution
- Pros & Cons
- Tools
- Lessons learnt
A presentation by Supercharge
www.supercharge.io
Development principles in test automation!David Baak
Test automation is a prominent part of testing. To further improve our test automation we should look at development practices. One important practice to improve the maintainability of the test automation is to create clean code. Recognizing clean code is quite easy. If it reads like prose and you understand the intent (almost) immediately while you are not the author, then it’s probably clean. However, writing clean code is difficult. This presentation gives you pointers on how to create readable code by using proper naming and refactoring.
This course provides a detailed introduction to the Object Oriented techniques identified by Robert Martin as the SOLID principles of software design. Intended for both novice and intermediary developers, each of the five principles are fully defined and explored. Real-world coding examples are provided for each software tenant to help fully expound upon the design techniques. By the end of the session, developers will be able to identify common code smells while applying SOLID programming practices that ensure clean and maintainable code.
Object Oriented Design Principles
~ How to become a SOLID programmer ~
~ A guide to make a well-designed application with Laravel ~
"Proper Object Oriented Design makes a developer's life easy, whereas bad design makes it a disaster"
SOLID Design Principles applied in JavaIonut Bilica
Video: https://www.youtube.com/watch?v=0cU-4LrcWI0
SOLID Design Principles applied in Java: rules to develop scalable and easily maintainable code
Speaker: Ionut Bilica - Senior Software Developer @ Luxoft Romania.
During this talk we will discuss about the SOLID Principles described by Robert C. Martin, applying them in the Java programming language. Each principle will be explained in detail, with practical Java examples.
We will asses how these principles make it easy to develop the software for the entire duration of the project, and how some problems can appear if these principles are not applied. We will present common code fragments that do not respect these principles, and we'll see how we can correct them. Taking the SOLID principles into consideration, we will also analyse a real Java project using a Static Code Analyzer tool (e.g. STAN).
Finally, we will discuss the strategies on how to apply these design principles in "greenfield" projects, as well as "legacy" projects, while offering some tips and tricks.
"Refactoring to SOLID Code" session presentation from
Emerging .NET Devs - October 2011 User Group Meeting.
Please note that this presentation has been simplified for publishing.
During this talk we will discuss about the SOLID Principles described by Robert C. Martin, applying them in the Java programming language. Each principle will be explained in detail, with practical Java examples.
We will assess how these principles make it easy to develop the software for the entire duration of the project, and how some problems can appear if these principles are not applied. We will present common code fragments that do not respect these principles, and we'll see how we can correct them. Taking the SOLID principles into consideration, we will also analyse a real Java project using a Static Code Analyzer tool (e.g. STAN).
Finally, we will discuss the strategies on how to apply these design principles in "greenfield" projects, as well as "legacy" projects, while offering some tips and tricks.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
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.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
2. About us
Jarno Walgemoed Jan-Kees van Andel
–Architect @JPoint –Architect @JPoint
–Fa-Med
r –Rabobank
r
pe
pe
–Blinker –SNS Bank
lo
ve
–DJI
elo
D e –Apache MyFaces
v
–Devoxx Steering
De
SOLID Software Design 2
15. Code quality
Is this code quality?
/**
* This controller contains default Action and Render mappings,
* used as fallback for handling invalid URL's. This prevents DOS
* attacks, because a "no-handler-found“ Exception results in a
* corrupt application state in WAS and can only be restored by
* restarting the application. These handlers solve this problem.
*/
@Controller
@RequestMapping("VIEW")
public class DefaultController {
SOLID Software Design 15
16. Code quality
Is this code quality?
/**
* This controller contains default Action and Render mappings,
* used as fallback for handling invalid URL's. This prevents DOS
* attacks, because a "no-handler-found“ Exception results in a
* corrupt application state in WAS and can only be restored by
* restarting the application. These handlers solve this problem.
*/
@Controller
@RequestMapping("VIEW")
public class WebSphereASDefaultHandlerController {
SOLID Software Design 16
17. Code quality
Tonight, code quality means OO Design
– OOD is not free or easy, not even with Java/C#
– A lot of structured programming out there!
SOLID Software Design 17
18. Code quality
Tonight, code quality means SOLID principles
– Not about Object Oriented Modeling
• (Person, User, Plane is-a Vehicle, etc)
• Highlighting Nouns
– But about Dependency Management
SOLID Software Design 18
19. Code quality
Tonight, code quality means Dependency Mgt
– Because
• We DON’T want rigid code
• We DON’T want changes to cause ripple effects
• We DON’T want fragile code
• We DO want easily unit testable code
• We DO want reusable code
• We DO want readable code
SOLID Software Design 19
27. Single Responsibility Principle
“A class should have only one reason to change”
– Theory
– Simple example
– Real world example
– Considerations
– Conclusion
SOLID Software Design 27
28. Single Responsibility Principle
Theory
– A Class Should Only Have One Reason To Change
– Also referred to with the term Cohesion
(DeMarco, Page-Jones)
– Separation of Concerns
– Classes should have ONE well-defined
responsibility
SOLID Software Design 28
30. Single Responsibility Principle
Simple example
– Database application interface specification
public interface Database {
public void connect(String url);
public void disconnect();
public ResultSet executeQuery(String query);
}
SOLID Software Design 30
31. Single Responsibility Principle
Simple example
– What if the protocol changes?
– What if the connection management changes?
– What if we want to implement pooling or caching?
– We’ll need to change the database implementation
in both cases
SOLID Software Design 31
32. Single Responsibility Principle
Simple example
– How about this?
public interface DatabaseConnection {
public ResultSet executeQuery(String query);
}
public interface DatabaseConnectionManager {
public DatabaseConnection connect(String url);
public void disconnect(DatabaseConnection conn);
}
SOLID Software Design 32
33. Single Responsibility Principle
Simple example
– DatabaseConnection implementations handle
querying
– DatabaseConnectionManager implementations
handle connections
– We’ve managed to split two responsibilities
SOLID Software Design 33
35. Single Responsibility Principle
Considerations
– If the application doesn’t require changing either
of the coupled responsibilities at different times
DON’T USE SRP
– Don’t apply SRP if there are no symptoms
– Treat it as a guideline
– Be consistent in what you call a “Responsibility”
• Split on functionality, domain, architecture, layers and
do this in a consistent way
SOLID Software Design 35
36. Single Responsibility Principle
Conclusion
– Simplest SOLID principle, hardest to get right
– Be critical deciding whether or not an SRP
violation needs to be fixed
– Stay pragmatic!
– State management simplified by separating object
lifecycles
SOLID Software Design 36
38. Open-Closed Principle
“Software entities should be open for extension,
but closed for modification”
– Theory
– Simple example
– Real world example
– Considerations
– Conclusion
SOLID Software Design 38
39. Open-Closed Principle
Theory
– Helps preventing rigidity and cascading changes
– Open for extension
• Behaviour of a module can be extended
– Closed for modification
• Extending does not result in a source change for a
module
SOLID Software Design 39
41. Open-Closed Principle
Simple Example
– We are using this Rectangle object
public class Rectangle {
private int width; private int height;
public int getWidth() {
return width;
}
public int getHeight() {
return height;
}
}
SOLID Software Design 41
42. Open-Closed Principle
Simple Example
– With this function we calculate area totals
public class AreaCalculator {
public int calculateTotalArea(Rectangle [] rectangles) {
int totalArea = 0;
for(Rectangle rectangle : rectangles){
totalArea +=
rectangle.getWidth() * rectangle.getHeight();
}
return totalArea;
}
}
SOLID Software Design 42
43. Open-Closed Principle
Simple Example
– Now we want to add a circle to the equation
public class Circle {
private int radius;
public int getRadius() {
return radius;
}
}
SOLID Software Design 43
44. Open-Closed Principle
Simple Example
– What happens to the calculation?
public double calculateTotalArea(Object [] objects) {
double totalArea = 0;
for(Object object : objects){
if(object instanceof Rectangle){
Rectangle rectangle = (Rectangle)object;
totalArea += rectangle.getWidth() * rectangle.getHeight();
}
if(object instanceof Circle){
Circle circle = (Circle)object;
totalArea += circle.getRadius() * circle.getRadius() * Math.PI;
}
}
return totalArea;
}
SOLID Software Design 44
45. Open-Closed Principle
Simple Example
– This is poor design (of course)
– The calculate method is not closed for
modification and not open for extension
– Adding a Circle requires the developer to change
the calculation code!
SOLID Software Design 45
46. Open-Closed Principle
Simple Example
– Introducing Shape and extending it
public abstract class Shape {
public abstract double getArea();
}
public class Circle extends Shape {
public double getArea() {
return radius * radius * Math.pi;
}
…
}
SOLID Software Design 46
47. Open-Closed Principle
Simple Example
– Simplifies AreaCalculator substantially
– Allows future extension
public class AreaCalculator {
public double calculateTotalArea(Shape[] shapes) {
double totalArea = 0;
for (Shape shape : shapes) {
totalArea += shape.getArea();
}
return totalArea;
}
}
SOLID Software Design 47
48. Open-Closed Principle
Simple Example
– The calculation is now Open for extension and
closed for modification
– Adding another shape to the equation no longer
requires a change to the calculate implementation
SOLID Software Design 48
50. Open-Closed Principle
Considerations
– Abstraction is key
– So… should we just abstract everything? No.
– Abstract elements that require frequent change
– Overuse of abstractions can create clutter
– Avoid premature abstraction
SOLID Software Design 50
51. Open-Closed Principle
Conclusion
– At the heart of Object Oriented design
– Design using logical, useful abstractions
– Add abstractions only when required
– Expect having no changes in your code
– Stimulate change (test, iterate)
– Properly refactor code that’s affected by these changes
SOLID Software Design 51
52. Open-Closed Principle
Question: Real world usages of OCP?
– Examples in Java API
– Examples in GoF Design Patterns
– Big abusers
SOLID Software Design 52
53. Liskov Substitution Principle
“If for each object o1 of type S there is an object o2 of
type T such that for all programs P defined in terms of
T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T”
– Come again?
SOLID Software Design 53
54. Liskov Substitution Principle
“Subtypes must be substitutable for their base
types”
– Theory
– Simple example
– Real world example
– Considerations
– Conclusion
SOLID Software Design 54
55. Liskov Substitution Principle
Theory
– Polymorphism problem
– A extends B
• This means A IS-A B
• …but is this always true for A and B?
SOLID Software Design 55
57. Liskov Substitution Principle
Simple Example
– Square extends Rectangle
• Square IS-A Rectangle, right?
– Difference between Square and Rectangle
• Rectangle can have different height and width settings
• Square has equal values for both
SOLID Software Design 57
58. Liskov Substitution Principle
Simple Example
– So, this is correct then?
class Rectangle {
private int width; private int height;
public Rectangle(int width, int height) {
this.width = width;
this.height = height;
} // Setters left out for brevity
}
class Square extends Rectangle {
// Initialize as a square
public Square(int size) {
super(size, size);
}
}
SOLID Software Design 58
59. Liskov Substitution Principle
Simple Example
– Suppose we test the Square like this
Square square = new Square(42);
assertEquals(42, square.getWidth()); // Ok
square.setHeight(50);
// Width should be the same as height, and we changed it!
assertEquals(50, square.getWidth()); // Whoops!
– Our square suddenly is a 42 by 50 Rectangle!
SOLID Software Design 59
60. Liskov Substitution Principle
Simple Example
– Fixing is easy, but is this really the way to go?
class Square extends Rectangle {
public void setWidth(int width) {
super.setWidth(width);
super.setHeight(width);
}
public void setHeight(int height) {
super.setHeight(height);
super.setWidth(height);
}
}
SOLID Software Design 60
61. Liskov Substitution Principle
Simple Example
– Maybe better to do this
class Square extends Shape { // Immutable
private final int size;
public Square(int size) {
this.size = size;
}
@Override
public int getHeight() {
return size;
}
@Override
public int getWidth() {
return size;
}
}
SOLID Software Design 61
62. Liskov Substitution Principle
Considerations
– The IS-A relationship not always applies in code
• A square is a rectangle in the real world
• A square is not a rectangle in code – contract breaks
when square doesn’t override rectangle behaviour
– Immutability can make a difference
• public Rectangle(int width, int height);
• public Square(int size);
• If both are immutable, Rectangle really IS-A Square!
SOLID Software Design 62
63. Liskov Substitution Principle
Conclusion
– Rule of thumb
• Instead of: A IS-A B, use: A is substitutable by B
– Inherit from a more abstract supertype if needed
• Rectangle and Square could both inherit from Shape
• Shape should enforce no rules for width and height
– Should you prevent LSP violations at all cost? No.
• What if you only have a method that draws Rectangles
• Will the LSP violation be a problem then?
SOLID Software Design 63
64. Liskov Substitution Principle
Question: Real world usages of LSP?
– Examples in Java API
– Examples in GoF Design Patterns
– Big abusers
SOLID Software Design 64
65. Interface Segregation Principle
“Clients should not be forced to depend on
methods that they do not use”
– Theory
– Simple example
– Real world example
– Considerations
– Conclusion
SOLID Software Design 65
67. Interface Segregation Principle
Simple Example
– Interface definition for a worker doing work
public interface Worker {
public void work();
public void eat();
}
– Implementation for a generic employee
public class Employee implements Worker {
public void work() { // do work stuff }
public void eat() { // eat lunch, keep up strength ;) }
}
SOLID Software Design 67
68. Interface Segregation Principle
Simple Example
– Robots are also part of the business
public class Robot implements Worker {
public void work() { // Work (without union breaks }
public void eat() { // Wait, what? }
}
– But they don’t eat lunch
– Still, eat() has to be implemented
SOLID Software Design 68
69. Interface Segregation Principle
Simple Example
– Split up the interfaces into sensible pieces
public interface NutritionConsumer {
public void eat();
}
public interface Worker {
public void work();
}
SOLID Software Design 69
70. Interface Segregation Principle
Simple Example
– Implement the interfaces as needed
public class Employee implements Worker, NutritionConsumer {
public void work() { }
public void eat() { }
}
public class Robot implements Worker {
public void work() {}
}
SOLID Software Design 70
71. Interface Segregation Principle
Simple Example
– Class dealing with Worker objects
public class WorkloadManager {
public void putWorkerToWork(Worker worker) {
worker.work();
}
}
– Can deal with both robots and employees
– Doesn’t need to be concerned with the nutritional
needs of the Employee type workers
SOLID Software Design 71
72. Interface Segregation Principle
Considerations
– Avoid coupling between interfaces and clients
– Clients should only depend on methods they use
– Separation reduces the risk of changes cascading
to implementing classes that do not have a need
for those methods
SOLID Software Design 72
73. Interface Segregation Principle
Conclusion
– Separate interfaces when it makes sense
– Don’t overdo it!
• Prevent classes having to implement many interfaces
• Prevent one-method interfaces
– Common sense is key (again)
• Split up interfaces as soon as clients show the need to
do so
SOLID Software Design 73
75. Dependency Inversion Principle
“High-level modules should not depend on low-
level modules directly, but through abstraction”
“Abstractions should not depend on details,
details should depend on abstractions”
– Theory
– Simple example
– Real world example
– Considerations
– Conclusion
SOLID Software Design 75
77. Dependency Inversion Principle
Simple Example
– Application that monitors system status
public class SystemStatus {
private HeatGauge gauge;
public void checkTemperature() throws OverheatingException {
if(gauge.actualTemperature() > 55) {
throw new OverheatingException();
}
}
}
SOLID Software Design 77
78. Dependency Inversion Principle
Simple Example
– HeatGauge implementation
public class HeatGauge {
public int actualTemperature() {
// Do some measuring and return the results
}
}
SOLID Software Design 78
79. Dependency Inversion Principle
Simple Example
– Systemstatus directly depends on HeatGauge
– Changes to HeatGauge can affect SystemStatus
public class SystemStatus {
private HeatGauge gauge = new HeatGauge();
public void checkTemperature() throws OverheatingException {
if(gauge.actualTemperature() > 55) {
throw new OverheatingException();
}
}
}
SOLID Software Design 79
80. Dependency Inversion Principle
Simple Example
– Abstract away the dependency
public interface HeatGauge {
public int actualTemperature();
}
public class HeatGaugeImpl implements HeatGauge {
public int actualTemperature() {
// Do some measuring
}
}
SOLID Software Design 80
81. Dependency Inversion Principle
Simple Example
– Use the new abstraction
public class SystemStatus {
// Less dependent by using the interface
private HeatGauge gauge = new GaugeImpl();
public void checkTemperature() throws OverheatingException {
if(gauge.actualTemperature() > 55) {
throw new OverheatingException();
}
}
}
– Better, but not perfect
SOLID Software Design 81
82. Dependency Inversion Principle
Simple Example
– Improving the example
public class SystemStatus {
private HeatGauge heatGauge;
public SystemStatus(HeatGauge heatGauge){
this.heatGauge = heatGauge;
}
public void checkTemperature() throws OverheatingException {
if(heatGauge.actualTemperature() > 55) {
throw new OverheatingException();
}
}
}
– Abstracts away the implementation used to gauge
the temperature
SOLID Software Design 82
83. Dependency Inversion Principle
Considerations
– Clients should ‘own’ the interfaces used to access
low-level modules
– Not the same as Dependency Injection (DI)
• Dependency Inversion
– Using abstractions to achieve loose coupling
– Ownership should be at client level
• Dependency Injection
– Design pattern to implement loose coupling
SOLID Software Design 83
84. Dependency Inversion Principle
Conclusion
– Maybe the most relevant of all SOLID principles
– Allows robust code to be written using
abstractions
– Dependency Inversion
• Relevant when designing functionality
– Dependency Injection
• Relevant when implementing functionality
– Do all classes need an interface? No.
SOLID Software Design 84
85. Dependency Inversion Principle
Question: Real world usages of DIP?
– Examples in Java API
– Examples in GoF Design Patterns
– Big abusers
SOLID Software Design 85
87. Other principles
Not SOLID, but just as important!
– REP: Release reuse Equivalency Principle
– CCD: Common Closure Principle
– CRP: Common Reuse Principle
– ADP: Acyclic Dependencies Principle
– SDP: Stable Dependencies Principle
– SAP: Stable Abstractions Principle
– From the same book as SOLID
SOLID Software Design 87
88. Other principles
Not SOLID, but just as important!
– REP: Release reuse Equivalency Principle
– CCD: Common Closure Principle
– CRP: Common Reuse Principle
– About package cohesion
SOLID Software Design 88
89. Other principles
Not SOLID, but just as important!
– ADP: Acyclic Dependencies Principle
– SDP: Stable Dependencies Principle
– SAP: Stable Abstractions Principle
– About package coupling
SOLID Software Design 89
93. Conclusion
Master the SOLID principles
– Use it in your communications
– Use it to challenge your design/yourself
– Applicable to modules, libraries, components...
– But don’t be dogmatic about it
– Don’t write SOLID, just because you can
– Try to see the disadvantages too!
– Don’t just believe the hype!
SOLID Software Design 93
94. Conclusion
SOLID principles are no hard rules
– Definitely no hard rules!
– Also no goals, just a means to an end
– There are more principles
– Principle of least Knowledge
– Premature optimization is the root of all evil
– Composition over Inheritance
– K.I.S.S. / Y.A.G.N.I.
SOLID Software Design 94
95. Conclusion
Don’t be dogmatic
– Even Uncle Bob said this
– http://blog.objectmentor.com/articles/2009/02/06/on
– In response to
– http://www.joelonsoftware.com/items/2009/01/31.ht
SOLID Software Design 95
Java API: -Examples: -Abusers: Almost every class with Context or Manager in it (javax.faces.FacesContext, javax.persistence.EntityManager, javax.servlet, HttpServletRequest, java.lang.Math, java.util.Collections) GoF Examples: Template Method, Chain of Responsibility, Decorator Abusers:
Java API: -Examples: javax.servlet.Filter, -Abusers: java.lang.String GoF -Examples: Template Method, Chain of Responsibility, Decorator, Abstract Factory, Command -Abusers: Singleton What about Aspect Oriented Programming? Open-Closed Principle on module level
Java API: -Examples: javax.servlet.HttpServlet (interfaces of HttpServletRequest/Response passed in, details are hidden) -Abusers: All static functions GoF -Examples: Strategy, State, Iterator, -Abusers: Spring Framework (Dependency Injection vs. Dependency Inversion)