1. Chapter 6 - Solving really big problems
1.1. Break it indo small pieces, then use the same principles as earlier in the book.
1.1.1. Three steps to great software
1.1.1.1. Functionality
1.1.1.2. Flexibility
1.1.1.3. Reusability and maintainability
1.1.2. Make it easy to change, extend and do what the customer wants
1.1.3. Encapsulate what varies
1.1.4. Code to the interface instead of the implementation
1.1.5. Understand what the system does, in order to get good requirements
1.1.6. Analyse to ensure real-world performance
1.2. Commonality
1.3. Variability
1.4. Feature
1.4.1. Feature to requirement(s)
1.5. Defer details as long as you can
1.6. Use Case Diagrams over Use Cases for big picture
1.6.1. Use Case Diagrams and Features
1.7. Domain analysis
1.8. Design patterns
1.8.1. Confused about design patterns?
1.9. OOA&D Toolbox
1.10. Bullet points
2. Chapter 7 - Architecture
2.1. Architecture
2.2. The three Q's of architecture
2.2.1. The essence is the basics of the system without all the bells and whistles the marketing department threw in.
2.2.2. They are mostly a judgement call
2.3. Scenarios give many advantages of use cases without all the details we don't need early on.
2.3.1. A Scenario is just ONE way through a Use Case, if you only used scenarios you might miss a Use Case opportunity.
3. Chapter 8 - Design Principles
3.1. Design principles
3.2. Open-Closed Principle (OCP)
3.3. Don't Repeat Yourself (DRY)
3.4. Singe Responsibility Principle (SRP)
3.5. Liskov Substition Principle (LSP)
3.5.1. When to use delegation
3.6. Composition
3.6.1. Composition vs. Aggregation
3.7. Inheritance, aggregation, composition and delegation
3.8. Bullet points
3.9. OOA&D Toolbox
4. Chapter 9 - Iterating and testing
4.1. Bullet points
4.2. OOA&D Toolbox
5. Chapter 10 - The OOA&D Lifecycle
5.1. The OOA&D Lifecycle
6. Objectville
6.1. UML - Class Diagram
6.1.1. Definition
6.1.1.1. Unified Modeling Language: A language used to communicate just the details about your code and application's structure that other developers and customers need, without getting details that aren't necessary
6.1.2. Klasse eksempel ud fra UML
6.2. Inheritance
6.2.1. Inheritance lets you build classes based on other classes and avoid duplicating and repeating code.
6.3. Pool puzzle
6.4. Polymorphism
6.4.1. Polymorphism is when a subclass "stands in" for its superclass
6.5. Encapsulation (Access modifiers)
6.5.1. Definition
6.5.1.1. The process of enclosing programming elements inside larger, more abstract entities. AKA information hiding or seperation of concerns.
6.5.2. Encapsulation is about separating information from other parts of your application that shouldn't mess with that information.
7. Chapter 1
7.1. Delegation
7.1.1. Definition
7.1.1.1. The act of one object forwarding an operation to another object, to be performed on the behalf of the first object.
7.1.2. Delegation makes your application more reusable. It also lets each object worry about it's own functionality, instead of spreading the code that handles a single object's behaviour all throughout your application.
7.1.3. Delegation shields your objects from changes to other objects of the application
7.1.4. One of the most common examples of delegation in java is the equals() method, which call equal on an object and passes in another, in order to compare them and return a true or false value.
7.2. Loosely coupled
7.2.1. Loosely coupled is when the objects of an application each have only one specific job to do, and do them really well.
7.3. The three steps of OOA&D
7.3.1. Functionality
7.3.1.1. Make sure your software does what the customer wants it to do.
7.3.1.2. Rick's guitar shop
7.3.1.2.1. We fixed functionality problems with Rick's application
7.3.1.2.2. We added functionality so that the search returns a list of guitars (instead of just one)
7.3.2. Flexibility
7.3.2.1. Apply basic object-oriented principles to add flexibility.
7.3.2.2. Rick's guitar shop
7.3.2.2.1. While adding new functionality we made sure to adhere to the correct design principles.
7.3.3. Maintainable, reusable design
7.3.3.1. Strive for a maintainable and reusable design
7.3.3.2. Rick's guitar shop
7.3.3.2.1. We encapsulated the guitar specs and made sure new new properties could be added to the app easily.
7.3.3.2.2. We added delegation so our objects are less dependent on each other and can be reused easily.
7.4. Customers are satisfied when:
7.4.1. Their apps work
7.4.1.1. Chapter 2
7.4.2. Their apps keep working
7.4.2.1. We've seen how fragile apps are in chapter 1
7.4.3. Their apps can be upgraded easily
7.4.3.1. Chapter 5 and 8 (delegation, composition and aggregation)
7.5. Programmers are satisfied when:
7.5.1. Their apps can be reused
7.5.1.1. Chapter 8
7.5.2. Their apps are flexible
7.5.2.1. Chapter 6 and 7
8. Chapter 2
8.1. Use cases
8.1.1. Requirement
8.1.1.1. Definition
8.1.1.1.1. A requirement is a singular need detailing what a product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering.
8.1.1.2. A good set of requirements goes beyond just what the customer wants, to make sure that the system also works in unusual or unexpected circumstances.
8.1.1.3. Example
8.1.2. Three steps to a good use case
8.1.2.1. Clear value
8.1.2.2. Start and stop
8.1.2.3. External initiator
8.1.3. Use case vs. Use case diagram
8.1.4. Use case vs. requirements
8.1.5. Main and alternate path
8.1.5.1. The main path in a use case is the one where everything just works.
8.1.5.2. The alternate path is when something goes wrong, and you have to write som sub-points in the main path to handle it.
9. Chapter 3 - Requirements change
9.1. Scenario
9.1.1. A complete path through a use case from start to stop is called a scenario
9.1.2. Use cases can have several scenarios, but they always share the same user goal.
9.2. OO design principle 1: Encapsulate what varies.
10. Chapter 4 - Analysis
10.1. UML Asterisk
10.2. Use cases and textual analysis
10.2.1. The things (usually the nouns) in the use case let you know roughly which classes to create.
10.2.2. The verbs let you know which methods to consider making
10.3. UML Class Diagram extended
10.3.1. Multiplicity
10.3.1.1. Describes how many of a specific type can be stored in an attribute of a class
10.3.1.1.1. Example: The door attribute stores a single DogDoor
10.3.2. Attribute = method
10.3.3. Association
10.3.3.1. Visually shows that one class has a relation to another, usually through an attribute.
10.3.4. Operation = member variable
11. Chapter 5 - Good design = Flexible software
11.1. Part 1
11.1.1. OO design principle 3: Each class in your application should have only one reason to change.
11.1.2. OO design principle 2: Code to an interface rather than to an implementation.
11.1.3. UML Extended 2
11.1.3.1. Abstract class
11.1.3.1.1. An abstract class defines some basic behaviour, but it's really the subclasses of the abstract class that add the implementation of those behaviours.
11.1.3.1.2. Typed in italics
11.1.3.2. Aggregation
11.1.3.2.1. Aggregation is a special form of association, and means that one thing is made up (in part) of another thing.
11.1.3.3. Generalisation
11.1.3.3.1. A line with an arrow that isn't colored in means generalisation. You use generalisation to indicate that one class extends and inherits behaviour from a more generalised class.
11.1.3.4. UML Cheat sheet
11.1.3.5. Interface
11.1.3.6. Encapsulation extended
11.2. Part 2
11.2.1. Cohesion (AKA SRP - Chapter 8)
11.2.2. OOA&D toolbox extended