Web Applications – Design 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

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. 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

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

22. Injection Kinds • Constructor • Setter • Field • Lookup key • Type • Name