1 web applications – design issues. 2 data requirements –persistent –consistent (no corruption...
Post on 22-Dec-2015
213 views
TRANSCRIPT
2
Data
• Requirements– Persistent– Consistent (no corruption even if server fails)– Concurrent updates– Transactions
• Solution: Database
• Relational or schema-less
• (Also, SQL is a great DSL for data queries)
4
Entities Need Dedicated IDs
(Even if they have unique names)
• Domain may change – names may stop being unique
• There's a need to support renaming – (But not re-IDing)
• Creating a new entity– A temporary name such as "xyz398556" is weird
5
The Agony of ID-based data
• Several objects representing the same entity– (same id)– Each one is updated due to a different client request– Still, they all reflect the same “entity” and should exhibit
the same data
• References are often useless
• Caching & memory managements problems
• Counter intuitive to OOP style
6
Multiple Services
• Recall– Entities– Values– Services
• Web applications– Many services– Many configurations of services
• Configurations– Deployment– Testing– Development– Admin– Console – Database A vs. Database B
7
Encapsulation
• Maintaining consistency of the data– (Invariants)
• Example: a vector class– size, items.length need to be aligned
class Vector { public Object[] items = new Object[10]; public int size = 0; public void add(Object o) { items[size++] = o;}
8
Web of objects
• OOP: Objects communicating via messages– (Calls to overridable methods)
• Some of the objects are likely to be encapsulated– (preserve invariants)
9
Invariants in Web of Objects
• Database Manager– OracleQueryBuilder, OracleDataSource– MySqlQueryBuilder, MySqlDataSource
• Communication Channel– XMPPListener, XMPPMessage– …
10
Example: Model Class
• Two fields: queryBuilder, dataSource
• Option 1: Initialized inside the class– High Safety: no mismatch– Low flexibility: Hard to reuse/adapt to new contexts
• Option 2: Injected from the outside– Not as safe– More flexible
11
One Computation - Many Webs
• Eventually, there is a computation that needs to be carried out
• Many options regarding where sub-computations reside
• Developer can decide on borders of responsibility
12
High Fan Out• One object is doing many things
– Low cohesion
• Fine-grained control – objects can be easily replaced
13
Low Fan Out (Telescopic Structure)
• Difficult to replace an object– (recall: some of these objects are encapsulated)– Often the first object determines the entire chain– Changing an object requires many new subclasses
• (Just to override the "new X()" expressions
14
Static is evil
• Static access:– static methods– new X()– super calls– Constructors
• form unbreakable links between two pieces of code– Cannot be overridden
15
Can we Change the value of s in f()?(without re-implementing B.f())
public class A { public String f(String s) { return s.toUpperCase(); } }
public class B extends A { @Override public String f(String s) { s = super.f (s ); int n = g(s .length()); // do some processing h("s=" + s + " n=" + n); // send it to the output return s; }
public int g(int n) { return n*n; }
private void h(String text) { System.out.println(text); }}
public static void main(String[] args) { B b = new B(); b.f ("abc"); // Output?}
16
Delegation to the Rescue
public class B { private A a; public B(A a) { this.a = a; } public B() { this(new A()); } public String f(String s) { s = a.f(s); int n = g(s.length()); // do some processing h("s=" + s + " n=" + n); return s; } // no change in g(), h()} public static void main(String[] args) { B b = new B(new A() { @Override public String f(String s) { return "*" + s + "*"; } }); b.f("abc");}
17
• Each object interacts with few collaborators– Doing some work, but not too much– Chains to leaves are not long
• Collaborators can be specified from the outside
• => Behavior of the web can be tweaked– w/o too much subclassing- w/o reconstructing large (sub) parts of the web
- Testability leads to such a structure- (In particular, Mock-based testing)- See also: http://misko.hevery.com/code-reviewers-guide/
Ideal Web
18
Web-of-objects Building Strategies
• Hard wired “new” expression – no flexibility
• A Typed Singleton factory
• A multi-interface Typed Singleton factory
• An untyped singleton factory
• A propagating factory object
• Dependency Injection
19
Dependency Injection Containers(Java World)
• Guice– http://code.google.com/p/google-guice
• Spring– http://www.springsource.org
• Pico– http://www.picocontainer.org
20
Dependency Injection
• Sometimes called: Inversion of Control– (IOC)
• Slogan: "Don’t call us we’ll call you"– (The Hollywood principle)
• Class has only setters/constructor args– Completely unaware of a factory– Thus, it is a POJO
• Container uses reflection to initialize instances
21
Benefits of DI
• Classes can be used w/o a factory– Explicit (“manual”) injection of dependencies
• Support for multiple scopes
• Objects are not depending on a factory
• Dependencies are explicit in the signatures