# Topic 1 ## Four OOP principles Abstraction : Objects can hide implementation details, as with interfaces. Encapsulation : Hide internal information from outside, like with getters and setters. Inheritance : Classes can extend other classes, inheriting their methods. Polymorphism : Speficying interfaces which multiple classes can implement. # Topic 2 ## Class composition ``` A - B ``` B er en del af A, og B vil ikke kunne fungere alene. A ejer B. ## Class aggregation ``` A <>- B ``` A har B, men B kan også stå alene. A bruger B ## Association ``` A --> B ``` A does something with B. ## Exception vs Error Errors are unrecoverable. # Topic 3 1. Use cases Shows interfaction between things. 2. Domain model 3. Interaction diagrams Shows more detailed interactions as a sequence diagram. 4. Design class diagrams This repeats multiple times as the requirements may change under development. This is because unanticipated things might occur. ## Use case These are pretty much as always, but here are some important words. Actor : Who performs operations; a person, organization or computer system. Scenario : What are the required interactions required. Alternate scenario : What happens if something goes wrong. What can go wrong. ## Requirements These diagrams are used to get the following requirements. - Functionality: what should the system do? - Usability: what kind of UI is needed? - Performance - Implementation constraints Domain rules : Additional external constraints such as laws etc. ## Domain model Not a part of design but analysis. Uses conceptual classes, which are real things not functions or data. Uses vocabulary of the current domain. Has associations like, class diagram and are interactions between these real objects. Examples: - A is part of B, or is contained in B - A is a description of B - A is used by B - A is owned by B - A is owned by B - A is an event affecting B Only include important association, as this is not a specification. Can include class attributes, but should not contain complex information. So a Flight maybe has a destination. # Topic 5 ## GUI Are: - Asynchronous - Components are in containers which are in a layout. # Topic 8 Interaction and Classes Creating a design from analysis. ## Mapping objects Object can be mapped from the interaction design, borrowing names as much as possible. Objects can have to main responsibilities: - Doing things Often methods, ex: Cashier has `scanItem()`. - Knowing things ## Patterns Patterns are solution which fit multiple problems, such as having a `Listener`. ### Grasp patterns General Responsibility Assignment Software Patterns. Main patterns: - Information expert: Assign a task to the class which has the most information about it. - Creator: B should create an object if it contains, records, uses, or has information about object. - Low coupling: Uses encapsulation to define simple interfaces between classes, and passing data using standard formats. - High cohesion: Create focused objects, instead of `god` objects. This can be done by keeping responsabilities related. - Controller: Handles system input events, to seperate the interface from the main system. Coupling and cohesion manage class complexity. Strike a balance between object size and complexity. ### Visibility Who can see what. Should avoid global visibility as much as possible. Achieved using *information hiding*. # Topic 9 Design Patterns Common language between developers. Always code using interfaces and not classes, always accept interfaces. Prefer object composition instead of inheritance (why use OOP then). Patterns can be used when designing, following types: - Creational: Creates new objects, hiding the creation process - Structural: Patterns concerning class composition - Behavioral: Communication between classes - Anti-patterns: Design features known to create problems ## Factories Create objects without exposing creation logic. Eases polymorphism is the factory decides which type to create, and then cast to interface when returning. ## Singleton An object which is only created once. Useful when dealing with drivers or sockets. 1. Object A requests singleton C 2. C is creates as it does not exist, and is returned to A 3. B requests C 4. Existing C is returned to B Special care must be taken when doing multithreading, and testing is also harder. ## Builder Construct object in the same way as factories. Implements a `Builder` interface which is run then the product is needed. One can then build objects without worrying about complex constructor parameters. ## Adapter Bridge between two incompatible interfaces. Should be kept as a minimum as deep layering can complicate design. ## Filter pattern Implements searching. ## Composite Contains other instances of the same type. Useful for creating trees. ## Observer pattern Listens for events and notifies client. Often used in gui's. ## Publish subscribe Publishers publish messages, and subscribers can subscribe on specific events. This is orchestrated by a central broker. ## Some anti patterns - *God object* with too many responsibilities - Sequential coupling: methods that must be called in order - Object orgy: unrestricted access to internal variables - Yo-yo problem: too many layers of inheritance - Spaghetti code: too many ad-hoc fixes - Error hiding - Object cesspool: reusing objects with unpredictable state # Topic 10 What happens after first iteration, so first system has been developed. Clients may want more features. Here a good domain model can help, as it will facilitate new features easily. Interfaces can often help implement new features, as only the implementation must be replaced. ## Maintanance The implementation after a changed design model. Much easier with a low coupling. Should be done on a production branch. # Topic 11 Talking to databases in java happens with the JDBC api. ## ACID - Atomicity - Consistency - Isolation - Durability ## Testing Static testing : Reviewing code. Dynamic testing : Unit test, integration test and acceptance test. ### Code review Single or as a team. Walk through the code, and become familiar with code. Often af good way to ensure correct documentation and code style. ### White box testing Testing with knowledge of implementation. Path testing : Does the program reach the correct statements Data flow testing : Do variables have expected values at times Fault injection : How do methods handle invalid input Condition/decision testing : Have all possible outcomes been tested using above #### Intergration testing Test modules together, are there any problems. Bottom-up : Start with classes, then modules and end at a full program Top-down : Start from main method, and gradually add components ### Black box Should not use knowledge of the implementation. #### Acceptance testing Test the different use-cases, from the perspektive of the user. Often done by external testers. #### Automated unit test Run through testcases which run small parts of program. This is done in java using the j-unit testing framework.