Transcript l12web-apps-issues

1
Web Applications –
Design Issues
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)
3
Distributed Environment
• Two Languages, Two processes
• No pointers
• Speaking in IDs
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
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?
}
15
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
Ideal Web
• 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/
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
Dependency Injection Containers
(Java World)
• Guice
– http://code.google.com/p/google-guice
• Spring
– http://www.springsource.org
• Pico
– http://www.picocontainer.org
19
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
22
Injection Kinds
• Constructor
• Setter
• Field
• Lookup key
– Type
– Name