From bc36f120bdfd6fc18d5d34486c9cbb580e670910 Mon Sep 17 00:00:00 2001 From: Julian T Date: Mon, 11 Jan 2021 17:20:37 +0100 Subject: Added notes for OOP and NET --- sem5/oop/eksamnen/noter.md | 324 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 324 insertions(+) create mode 100644 sem5/oop/eksamnen/noter.md (limited to 'sem5/oop') diff --git a/sem5/oop/eksamnen/noter.md b/sem5/oop/eksamnen/noter.md new file mode 100644 index 0000000..bf6f774 --- /dev/null +++ b/sem5/oop/eksamnen/noter.md @@ -0,0 +1,324 @@ +# 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. -- cgit v1.2.3