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.
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.
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.
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.
This BJUG presentation is focused on the unique inter-process communication (IPC) mechanism introduced by Android, namely Binder. As such, we will be exploring the entire Android software stack, starting from the Linux kernel, moving up to the Linux userspace, reaching the Android framework and ending our journey with some real-life usages of Binder in Android applications.
We will show how widely used Binder actually is in Android, thus proving that it is a cornerstone of the operating system. The main focus is on the programming model exposed towards developers and we will highlight when, how and why it should be used.
https://bjug.ro/binding-android-piece-by-piece/
The theory of SOLID principles was
introduced by Robert C. Martin in his 2000
paper “Design Principles and Design
Patterns”.
SOLID => Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
This presentation talks about the five SOLID principles of Object Oriented Design described by Rober C. Martin in his best-seller book "Agile Principles, Patterns, and Practices in C#". The five principle described are:
- Single Responsibility Principle
- Open-Close Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
The presentation is took from the Software Engineering course I run in the bachelor-level informatics curriculum at the University of Padova.
Lego For Engineers - Dependency Injection for LIDNUG (2011-06-03)Theo Jungeblut
My presentation for the LinkedIn .NET User Group (LIDNUG) from June 3rd 2011 about Dependency Injections and related Design Patterns and Best Practices using Lego Technic for visualizing the concepts and ideas.
"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.
Clean Code - Design Patterns and Best Practices at Silicon Valley Code CampTheo Jungeblut
Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code.
You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012.
However, the demonstrated patterns and practice can be applied to almost every other programming language too.
This BJUG presentation is focused on the unique inter-process communication (IPC) mechanism introduced by Android, namely Binder. As such, we will be exploring the entire Android software stack, starting from the Linux kernel, moving up to the Linux userspace, reaching the Android framework and ending our journey with some real-life usages of Binder in Android applications.
We will show how widely used Binder actually is in Android, thus proving that it is a cornerstone of the operating system. The main focus is on the programming model exposed towards developers and we will highlight when, how and why it should be used.
https://bjug.ro/binding-android-piece-by-piece/
The theory of SOLID principles was
introduced by Robert C. Martin in his 2000
paper “Design Principles and Design
Patterns”.
SOLID => Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.
Learning solid principles using c#
S Single Responsibility Principle
O Open Closed Principle
L Liskovs Substitution Principle
I Interface Segregation Principle
D Dependency Inversion principle
This presentation talks about the five SOLID principles of Object Oriented Design described by Rober C. Martin in his best-seller book "Agile Principles, Patterns, and Practices in C#". The five principle described are:
- Single Responsibility Principle
- Open-Close Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
The presentation is took from the Software Engineering course I run in the bachelor-level informatics curriculum at the University of Padova.
Lego For Engineers - Dependency Injection for LIDNUG (2011-06-03)Theo Jungeblut
My presentation for the LinkedIn .NET User Group (LIDNUG) from June 3rd 2011 about Dependency Injections and related Design Patterns and Best Practices using Lego Technic for visualizing the concepts and ideas.
"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.
Clean Code - Design Patterns and Best Practices at Silicon Valley Code CampTheo Jungeblut
Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code.
You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012.
However, the demonstrated patterns and practice can be applied to almost every other programming language too.
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"
Improving the Design of Existing SoftwareSteven Smith
Combat technical debt and keep your code maintainable using these principles, heuristics, and refactoring techniques. Presented October 2017 at DogfoodCon in Columbus, OH. Learn more at http://bit.ly/PS-Refactoring
The maze of Design Patterns & SOLID PrinciplesMuhammad Raza
There are several mistakes usually developers make during product development. So keeping your demand of how to optimize time and resources so that there should be the least scope of errors and bugs we brought a demanding topic for you. This talk will cover the best practices that should be involved in web development and if you are adopting them your code will project you more experienced than an experienced developer.
Refactoring Applications using SOLID PrinciplesSteven Smith
We’ve all heard about well-designed software projects, where things aren’t (yet) a big ball of mud that’s painful to work with, but many of us aren’t lucky enough to work on these. Nor is it an option for us to get to start a brand new “greenfield” project, where we can leave behind the legacy of spaghetti code and technical debt our current project might have.
But there is hope! By applying refactoring steps based on SOLID principles of object oriented design, we can reduce the technical debt of our existing application, improve our code quality, and hopefully make our application more enjoyable and productive to work with.
In this session, we’ll briefly introduce the SOLID principles and several design patterns, and then we’ll apply these principles and patterns by improving the design of an existing application through several refactoring steps.
I gotta dependency on dependency injectionmhenroid
Satisfy your desire to be a better software developer by learning how to implement Dependency Injection (DI) in your application. Dependency Injection is one of the more popular implementations of Inversion of Control (IoC) that helps to increase modularity and extensibility of software. In this lecture, we'll discuss the benefits of DI, methods for implementing and refactoring existing code to use DI, adding unit tests using MSTest and Moq, popular DI frameworks like Unity, Ninject, and Castle Windsor, as well as alternative IoC patterns and anti-patterns.
Improving The Quality of Existing SoftwareSteven Smith
Presented at DevReach 2013.
As developers, most of our time is spent working on existing software. Sure, occasionally we get the chance to fire up a new Solution in Visual Studio, and that can be exciting. But after the first day, we find ourselves once more having to deal with the work we did yesterday. And today, we know more than we did yesterday, so there are things we’d do differently, if we had it to do over.
Over time, software rots. If we’re not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car – it’s preventive maintenance. In this session, Steve will look at some common places to look for signs of degradation in existing applications, and steps to take to improve the code. Examples will use C# and primarily ASP.NET.
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
Improving the Quality of Existing SoftwareSteven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse?
Improving the Quality of Existing Software - DevIntersection April 2016Steven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse? How can we improve our skills and techniques so that writing high quality software becomes our default, fastest way of working?
Improving the Quality of Existing SoftwareSteven Smith
Given at DogFoodCon 2016 in Columbus, Ohio
As developers, most of our time is spent working on existing software – even if it’s just the software we wrote ourselves, yesterday. And over time, software rots. If were not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car “ its preventive maintenance. In this session, Steve will cover some common places to look for signs of degradation in existing applications, and describe the steps we can take to improve our code. Examples will use C# and primarily ASP.NET.
Breaking Dependencies to Allow Unit TestingSteven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
NO1 Uk best vashikaran specialist in delhi vashikaran baba near me online vas...Amil Baba Dawood bangali
Contact with Dawood Bhai Just call on +92322-6382012 and we'll help you. We'll solve all your problems within 12 to 24 hours and with 101% guarantee and with astrology systematic. If you want to take any personal or professional advice then also you can call us on +92322-6382012 , ONLINE LOVE PROBLEM & Other all types of Daily Life Problem's.Then CALL or WHATSAPP us on +92322-6382012 and Get all these problems solutions here by Amil Baba DAWOOD BANGALI
#vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore#blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #blackmagicforlove #blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #Amilbabainuk #amilbabainspain #amilbabaindubai #Amilbabainnorway #amilbabainkrachi #amilbabainlahore #amilbabaingujranwalan #amilbabainislamabad
About
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Technical Specifications
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
Key Features
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface
• Compatible with MAFI CCR system
• Copatiable with IDM8000 CCR
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
Application
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
Sachpazis:Terzaghi Bearing Capacity Estimation in simple terms with Calculati...Dr.Costas Sachpazis
Terzaghi's soil bearing capacity theory, developed by Karl Terzaghi, is a fundamental principle in geotechnical engineering used to determine the bearing capacity of shallow foundations. This theory provides a method to calculate the ultimate bearing capacity of soil, which is the maximum load per unit area that the soil can support without undergoing shear failure. The Calculation HTML Code included.
3. 3
Introduction
> Where we are?
Methodology and Design Tech
Process
Tools
Methodology
Design
technique
Heavyweight
process
Agile
process
Process
appraisal and improvement
For supporting
process
For supporting
methodology
For supporting
Design technique
4. 4
Principles
> What is a bad design?
> The principles
• OCP open-closed principle
• SRP single responsibility principle
• ISP interface segregation principle
• LSP Liskov substitution principle
• DIP dependency inversion principle
> Principles reviewed
5. 5
Bad designs
> Rigidity – hard to change
> Fragility – easy to break
> Immobility – hard to reuse
> Viscosity – hard to do the right thing
> Needless Complexity – over design
> Needless Repetition – error prone
> Opacity – hard to read and understand
6. 6
Open Closed Principle
> Examples of OCP violation
public interface Shape extends Comparable{
public void draw();
}
public class Circle implements Shape {
public void draw() {
}
public int compareTo(Object o) {
if (o instanceof Rectangel) {
return -1;
}
else if (o instanceof Circle) {
return 0;
}
else {
return 1;
}
}
}
Shape
Circle Rectangle
New
Shape
7. 7
Open Closed Principle
Software entities should be open for extension,
but closed for modification
B. Meyer, 1988
> Be open for extension
• module's behavior can be extended
> Be closed for modification
• source code for the module must not be changes
> Modules should be written so they can be extended without requiring
them to be modified
8. 8
Open Closed Principle
> How to:
• Encapsulate what varies.
• Abstraction is the KEY.
• Use “Data-Driven” approaches.
> This principle implies that:
• Make all member variables private.
• No global variables.
• RTTI (Run-Time Type Information) is dangerous.
> Also:
• No significant program can be 100% closed.
• OK to take the first bullet.
9. 9
Single Responsibility Principle
> Examples of SRP violation
Computational
Geometry
Application
Graphical
Application
GUI
Rectangle
draw()
area()
> This violation is bad for that:
• We must include the GUI in the Computational Geometry
application.
• If a change to the Graphical Application causes the Rectangle to
change, that change may force us to rebuild, retest, and redeploy
the Computational Geometry Application.
10. 10
Single Responsibility Principle
> A Class should have one reason to change
• A Responsibility is a reason to change
> Single Responsibility = increased cohesion
> Not following results in needless dependencies
• More reasons to change.
• Rigidity, Immobility
11. 11
Single Responsibility Principle
> Conform to SRP:
Computational
Geometry
Application
Graphical
Application
Rectangle
draw()
GUI
Geometric
Rectangle
area()
13. 13
Interface Segregation Principle
> Many client specific interfaces are better than one general
purpose interface
> Create an interface per client type not per client
• Avoid needless coupling to clients
GraphicalRect_I
draw()
Computational
Geometry
Application
Graphical
Application
Rectangle
draw()
area()
GUI
GeometricRect_I
Area()
14. 14
Liskov Substitution Principle
“What is wanted here is something like the following
substitution property: 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.”
(Barbara Liskov, 1988)
15. 15
Liskov Substitution Principle
> Any subclass should always be usable instead of its
parent class.
• Pre-conditions can only get weaker
• Post-conditions can only get stronger
> Derived classes should require no more and promise no
less.
16. 16
Liskov Substitution Principle
public interface Bird{
public void fly();
}
public class Parrot implements Bird {
public void fly() {
System.out.println(“OK, I can fly.”);
}
}
public class Penguin implements Bird {
public void fly() {
throw new IllegalStateExeption(“Sorry, I can not fly…”);
}
}
>Example of LSP violation:
public class BirdCustomer {
……………..
Bird bird = new Parrot();
bird.fly();
……………..
……………..
bird = new Penguin();
bird.fly(); // oops, the customer will
be surprised!
…………….
…………….
}
17. 17
Liskov Substitution Principle
public class Rectangle {
public void setWidth(double w) {
this.width = w;
}
public void setHeight(double h) {
this.height = h;
}
public double area() {
return this.width * this.height;
}
}
public class Square extends Rectangle {
public void setWidth(double w) {
super.setWidth(w);
super.setHeight(w);
}
public void setHeight(double h) {
super.setWidth(h);
super.setHeight(h);
}
}
>Example of LSP violation:
public class RectangleCustomer {
……………..
Rectangel rect = new Square();
rect.setWidth(4);
rect.setHeight(5);
assert rect.area()==20;// oops, the
customer will be surprised!
…………….
…………….
}
20. 20
Dependency Inversion Principle
> A base class in an inheritance hierarchy should not know any of its
subclasses
> Modules with detailed implementations are not depended upon, but depend
themselves upon abstractions
> OCP states the goal; DIP states the mechanism;
> LSP is the insurance for DIP
I. High-level modules should not depend on low-level modules.
Both should depend on abstractions.
II. Abstractions should not depend on details.
Details should depend on abstractions
R. Martin, 1996
21. 21
Dependency Inversion Principle
> OO layering: Conforming to DIP
Policy
Policy
Layer
Policy Service
Interface
Mechanism
Mechanism Layer
Mechanism Service
Interface
Utility
Utility
Layer
22. 22
Dependency Inversion Principle
> This principle implies:
• Programming to interfaces, not implementations.
• Both the naming and the physical location of interfaces should
respect their customers, not their implementations.
• Dependency Injection.
Anyway, I need to depend on a concrete implementation object at
runtime, how can I get it?
23. 23
Dependency Inversion Principle
> Dependency Injection:
• Don’t use new operator to instantiate a concrete class where
you need, instead inject it from outside.
> Dependency Injection options:
• Constructor Injection with PicoContainer
• Setter Injection with Spring
• Interface Injection
• Using a Service Locator
For details, refer to
http://www.martinfowler.com/articles/injection.html
24. 24
OO Principles Reviewed
> Encapsulate what varies.
> Favor composition over inheritance.
> Program to interfaces, not implementations.
> Strive for loosely coupled designs between objects
that interact.
> Classes should be open for extension but closed for
modification.
> Depend on abstraction. Do not depend on concrete
classes.
> Only talk to your friends.
> Don’t call us, we’ll call you.
> A class should have only one reason to change.
Oh, what is this?
25. 25
Law of Demeter
> Only talk to your friends, also known as “Law of
Demeter”.
> Only invoke methods that belong to:
• The object itself.
• Objects passes in as a parameter to the method.
• Any object the method creates or instantiates.
• Any components of the object. (objects directly referred to)
> Violating when you write a_object.m1().m2();
> Keep our circle of friends small clear responsibility
decrease complexity
> Law of Demeter for Concerns (LoDC) is good for Aspect
Oriented Software Development.
27. 27
Evil Stuff
> Singletons / Global variables
• Singletons are actually OO global variables.
> Getters, Setters
• Evil for exposing information/implementation which should be hidden.
• Eliminate data movement. Data flow is procedure-oriented thinking.
• Don't ask for the information you need to do the work; ask the object that
has the information to do the work for you.
• Exceptions: computational query, get/set an interface
• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-
toolbox.html?page=1
• http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html
> Helper Classes
• Actually global procedures, hard to maintain.
• http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx
• http://blogs.msdn.com/nickmalik/archive/2005/09/07/462054.aspx
28. 28
Anti-Patterns
> Category
• Design related: The Blob, Poltergeist, Swiss Army Knife, Dead End
• Development related: Golden Hammer, Input Kludge
• Architecture related: Reinvent the wheel, Vendor lock-in
> The category:
• http://www.antipatterns.com/briefing/index.htm
• http://www.devx.com/Java/Article/29162
> Poltergeist:
http://www.icmgworld.com/corp/news/Articles/RS/jan_0302.asp
> Dead End:
http://www.icmgworld.com/corp/news/Articles/RS/jan_0402.asp
30. 30
Cookie – Thread Safe Singleton
public class Singleton {
private static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
public class Singleton {
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
volatile can make the double-check singleton thread safe, but only since Java5.
31. 31
Cookie – The dilemma of Observer
private class Model extends Observable {
public void handleAttributeChange(int value)
{
this.setChanged();
this.notifyObservers(value);
}
}
Observer observer = new Observer() {
public void update(Observable o, Object arg)
{
System.out.println(arg);
}
};
model.addObserver(observer)
new Thread() {
public void run() {
model.handleAttributeChange(1);
}
}.start();
new Thread() {
public void run() {
model.handleAttributeChange(2);
}
}.start();
Not thread safe, notifications to observers may be lost!
Notification order not guaranteed, early notification, maybe late received by observers.
32. 32
Cookie – The dilemma of Observer
private class Model extends Observable {
public synchronized void
handleAttributeChange(int value) {
this.setChanged();
this.notifyObservers(value);
}
}
model.addObserver(observer);
final Object object = new Object();
Observer observer = new Observer() {
public void update(Observable o, Object arg) {
synchronized (object) {
System.out.println(arg);
}
}
};
model.addObserver(observer);
new Thread() {
public void run() {
synchronized (object) {
model.addObserver()
}
}
}.start();
model.handleAttributeChange(1);
Notifications will not be lost.
But, still not thread safe, dead-lock is permitted!