//****************************************************************************//
//********* Domain Models (cont.) and RDD - September 22nd, 2017 ************//
//**************************************************************************//
- Google speaker on Monday coming to talk about development practices - come one, come all!
- Test 1 on Wednesday - you CAN bring a cheat sheet! Anything you can fit on an 8.5"x11" piece of paper
- Practice test on T-Square - some questions are outdated (e.g. we aren't teaching "Use Cases" this semester, haven't gotten to UML diagrams yet), but most of them are good!
- "Any questions I ask about Gradle or Git will be GENERAL questions like 'What is Gradle?', 'What is it used for?', 'Why do we use it?', etc.; I WILL NOT ASK YOU TO MEMORIZE COMMANDS!"
- Rundown of test topics:
- Conceptual questions (no actual coding or command knowledge, just principles)
- Git , Gradle, Zenhub, Android
- Design Topics
- Basic Agile concepts (time-boxing, backlogs, sprints)
- OOA - Context Diagram and External Actor ID, User Stories, Domain Modeling and class identification,
- SRP and Info Expert principle, Singleton and Facade design patterns (not coding, but what they do), RDD and RDD Stereotypes, Model-View-Controller (philosophy and how Android maps into this architectural style).
- Facade just means that an application provides a simplified external API to other parts of the system (the "Facade"), abstracting away any internal details
--------------------------------------------------
- So, we were talking about Entity vs Value objects - these are ESPECIALLY important when making databases later on, as the "Entity" objects will make up the actual tables, while the "value" objects are what often make up the database's columns
- Now, one thing we have to be aware of are "BOUNDED CONTEXTS" - a term in one part of the domain can mean something different between different users
- One example is the word "policy" for insurance companies
- Underwriters think of "policy' as evaluating risks and premium calculations
- Inspectors think of "policy" as establishing the value of a property
- Claim-handlers think of "policy" as handling requests for payment
- Instead of creating 3 classes w/ names like "claimPolicy", etc., we just create 3 separate models for "Policy" that we keep within the relevant sub-domain
- For UML, to show multiplicity, you write on the line connecting two things the # of things that can belong to the other thing, e.g.
"|Player|--- 1 ---- owns ---- 0...8---|Pieces|"
- This means that 1 "Player" can own 0-8 "Pieces"
- Things to be careful about when working w/ domain models:
- Trying to make an application WITHOUT a domain model
- "If you're REALLY familiar with what you're working in, great! BUT, if you're developing a finance application, and you don't know anything about finance, then you need to understand enough about the domain to know what they need"
- Losing the connection between the domain model and code
- "While we've focused on keeping the domain model understandable for the customer, remember that you still need the domain to be reasonably codable; it can't be COMPLETELY pie-in-the-sky"
- Trying to have too much of a "pure" analysis model
- "Here, in the academic world, we tell you that you should never have implementation classes at this stage, etc... in the real world, sometimes it'll make sense to have those details in the domain model, or to explain those things to the customer. It doesn't have to be theoretically perfect."
- Architecture-wise, these domain objects sit between the Infrastructure layer and the "Application" layer; they
- Now, let's talk about "Responsibility-Driven Design" - RDD
- "When OO first started, there were a lot of discussions about how objects should be designed - and RDD was one of the big winners, especially over Data-Driven Design"
- Let's say we're designing a horse - an Object-Oriented horse!
- In Data-Driven Design, we'd think about the "data" that makes up a horse, like its:
- Color
- Name
- Weight
- Height
- etc.,
- Then, we'd come up with some of the things horses could DO:
- gallop()
- move()
- eat()
- sleep()
- etc.,
- EVENT-DRIVEN Design is where we think about what CAUSES things to happen - "this is especially popular in simulations"
- if the horse is "hungry", it'll cause it to "eat()"
- spurred -> run()
- tired -> sleep()
- etc.
- Now, RDD asks, "What is the repsonsibility of the horse in OUR design?"
- e.g. let's say our application is a transportation simulation, where we're moving things from one place to another. SO, for our horse, the data we'd need to know is:
- Current location
- Current speed
- Max cargo capacity
- etc.
- Then, the relevant methods would be:
- loadCargo()
- unloadCargo()
- move()
- etc.
- This way, we're LIMITING our design to only what we ACTUALLY NEED!
- Now, we'll be getting into design principles later on, but two important ones for right now (that *might* just be on your test):
- The SINGLE-RESPONSIBILITY principle - Every class/object should have only ONE reason to change/one responsibility
- By "responsibility", we mean a high-level, overall "goal" of the object/class in our design. It does NOT mean having 1 method on a class (that'd defeat the point of OO!); it means giving each class a scope of what their responsibilities are
- The INFORMATION EXPERT principle - When assigning a responsibility, assign it to a class that has all the data needed to complete that task
- Some typical roles in RDD:
- "Information holders" - hold information needed by other classes
- "Service Providers" - these actually do things
- "Structurer" - organizes things
- "Interfacer" - adapts one part of a system to be used by another
- "Coordinators" - they pass events to other objects, but don't do any of the processing themselves
- "Controllers" - These make intelligent decisions about what operations should go where
- Kinda similar to coordinators, but think of a traffic light - the light itself is a "coordinator", and just turns on/off every 3 minutes without any decision making. A CONTROLLER, on the other hand, is like a traffic cop, where he can make decisions about "hey, there are 40 cars on this side of the road but only 6 on the other, so I'll let them through first". Controllers are generally more powerful, but sometimes are overkill/more complex than needed.
- A concrete example: an ATM machine!
- Customer is an INFORMATION HOLDER - mainly responsible for knowing things about customer (name, balance, account #, etc.)
- TransactionProcessor is a SERVICE PROVIDER - mainly responsible for processing deposits and withdrawals from ATM
- AtmMachine is a STRUCTURER - organizes the objects for the different parts of the ATM into a cohesive whole
- DataStore is an INTERFACER - responsible for interfacing the ATM system with the bank's database
- FrontController is a COORDINATOR - retrieves message from the ATM and relays them to correct part of system for processing based on unchanging rules
- AdaptiveMessageQueue is a CONTROLLER - obtains messages from the bank network, routes them to other parts of the system based on current workload and network status
- To add things to the Domain Model, we add a stereotype/category to each class by adding this above each class name in the UML diagram:
<<name of stereotype>>
- e.g.
_________________________
| <<info. holder>> |
| Person |
|_______________________|
| |
| |
| |
| |
|_______________________|
- Each class should have only ONE stereotype, but it's okay if it needs to branch out a little bit and do extra things to make your life easier. The stereotype describes the OVERALL, PRIMARY goal of the class - it should be taken seriously, but it's a guideline, not set in stone