...
Chapter 6: Objects and Data Structures
- Law of Demeter
- "objects that you created" is Java-specific
- distinguishing between objects that you've created and those that you depend on
- abstraction layers
- in some places, it says no more than one period.
- Train wrecks
- distinguishing between breaking abstractions through objects, and
- accessing data models directly
- Objects versus Data Structures
- Our django models have become hybrids
- What's the right pattern of having separation of concerns between persistence and the object-level abstraction?
- Should we create a new business logic layer on top of our models?
- Too many layers is not advantageous: API view -> Utils function -> .... eventually a Model
- Trade-off between making use of the framework and having abstraction layers
- If we think about the edx-platform codebase history, it seems we add more behaviors overtime, but no data structures.
- This implies perhaps we should think more procedural, rather than OO.
Chapter 7: Error Handling
- Using exceptions rather than error codes
- No brainer.
- Throwing exceptions instead of returning None
- We do this in our codebase.
- It's fine as long as we document it - we don't have a result for you.
- We do like his suggestion of having a special case object.
- Using django framework conventions
- ObjectDoesNotExist exception
- get_or_none - returns None
- first - return None
- In Java, exceptions are expensive, so they try to avoid them.
- But in Python, that's not the case.
- For example, getattr, just catches the exception and returns False/True.
- But if catching the exception is acceptable for code, then go fo it.
- By returning error codes, the callee can be assured that the caller will handle all cases.
- But then too many if statements.
- And probably end up wrapping it anyway, and throw an exception.
- If you make a mistake, and completely miss a case, then would get unnoticed.
- In some other languages, however, you have to pull out your object explicitly.
- hasattr - in case the object raises an exception other than AttributeError, later version of Python now catches it and returns False. Before, the exception was passed through.
- API wrapper mixin makes it easy to translate View exceptions to formatted HTTP error return objects.
- Some languages have @Nullable decorators to explicitly specify which functions have chosen to return Null.
- Passing Null around
- In some cases, we do want to do this - for example, Null values in Address fields, as opposed to empty strings.
- One way of thinking about this for Python: passing None for optional parameters is fine, but for non-optional parameters should be seriously vetted.
- "?." is not yet accepted into Python.
Next time: Chapters 8 and 9.