Koah Hamachatz Forum

1. Koah Hamachatz Forum Vladislav Smolensky Itamar Ben Zaken Shiran Alush Ido Bercovich Tamir Zur Barak Agiv

2. Table of Contents • System’s Architecture • Use Case Diagram, System Overview, Class Diagram • Design Patterns (we’ve used) • Refactorings (we’ve used)

3. Use Case Diagram

4. System Overview

5. Class Diagram

6. Design Patterns used in WsepForum • Façade • Adapter • Factory Method • Singleton • Proxy

7. Facade Design Pattern The Forum System is composed of several modules. A need for a single point of management was needed to control all modules. The Façade design-pattern was used in order to supply a higher-level interface (SessionFacade) to a set of modules (Logger,ForumSystem…) that makes them easier to use.

8. Adapter Design Pattern At first, the forum used a search engine that was developed by our team and used a specific interface. Later on, the team was required to use an external search engine called Compass. Now we were supposed to stay with the originalinterface and adapt it to the new implementation. The most suitable design-pattern for this purpose was the Adapter design-pattern.

9. Factory Method Design Pattern The core domain classes (post, forum, member, etc) contain public Factory Methods instead of public constructors. The reason is that their creation is not merely instantiating a new object. Primarily, there are two cases where we need to create core objects - when the object is new to the system, and when the object represents an entity that was already persisted to the database. Therefore, each such core class has two methods - createNew() and fetchBy...(). Secondly, creating a fresh object means also creating a database record for it, and fetching an object from the database means issuing an SQL query and constructing a new object from it.Given the extra-work needed to create new objects, we chose to use Factory Methods.

10. Singleton Design Pattern The DBAuthority and IDAuthority are Singletons.For IDAuthority, the motivation is that there should be only one entity in charge of assigning unique identification strings. Otherwise, two entities might assign the same ID to some object. In fact, we chose UUID as identification strings so even if two "authorities" assigned IDs, they would not assign identical IDs.For DBAuthority, the motivation is that all objects that need to, connect to the same database. Letting each object individually decide how to connect to the database and which database to connect to results in duplicated code and inconsistencies. Also, the mechanism to connect to the database should be available application-wide. Given that, the Singleton DP was a reasonable choice.

11. Proxy Design Pattern The Proxy design-pattern was used to control access to the Facade remotely. The "problem" was that the client cannot hold a real facade object since the facade objects are created in the server process and are tied to other objects in the server's memory space. The solution was to create a remote-proxy in the client and a stub in the server process. The two interact over a protocol we defined (over TCP) and the stub passes the requests to the real facade in the server process.The remote proxy, as well as the façade itself, implements the SessionFaçade interface.

12. Refactorings used in WsepForum • Extract Class • Renaming • Extract Method • Pull up method

13. Extract Class: At first, almost each class in the domain layer contained a field which held the next ID that will be given to a new instance. This functionality could be done by a new class so it was extracted into a new class called IDAuthority that gave each domain layer class a unique ID. Before: Class Member { private static int nextID = 1; private int ID; … public Member() { this.ID = nextID++; } … } After: public class IDAuthority { private IDAuthority() { } public static synchronized String newID() { UUID id = UUID.randomUUID(); return id.toString(); } }

14. Renaming: Throughout the development of the project class names, variable names, etc, were refined and adjusted to better describe the program elements.

15. Extract Method: Some class methods contained the same code pieces. This code duplication was handled by extracting the same code pieces into one method.Before:public class ShowStatButton { … public void onClick (Map pageData) { … • String [] ymd = s.split("/"); • int year = Integer.parseInt(ymd[0]); • int month = Integer.parseInt(ymd[1]) - 1; • int date = Integer.parseInt(ymd[2]); • Calendar calendar = Calendar.getInstance(); • calendar.set(year, month, date);Date ans = calendar.getTime(); • …} } • After:public class ShowStatButton { • public void onClick (Map pageData) { … Date ans = stringToDate(someRelevantString); • … } private Date stringToDate(String s){ • String [] ymd = s.split("/"); • int year = Integer.parseInt(ymd[0]); • int month = Integer.parseInt(ymd[1]) - 1; • int date = Integer.parseInt(ymd[2]); • Calendar calendar = Calendar.getInstance(); • calendar.set(year, month, date); • Date ans = calendar.getTime(); • return ans; }}

16. Pull Up Method: Methods that were used by several siblings of the same hierarchy were moved to the superclass (“pulled up” the hierarchy). • Before:public class PostView extends WSEPPage { … String getURLParameters(String param) { …… } String getForumID() { return getURLParameters(“fid”); } • … } • After:public class WSEPPage { • … String getURLParameters(String param) { …… } … }