A concrete approach to abstractions

Abstractions make things appear simple. This is one of the main concepts behind OOP. So what is it?! This talk provides some guidelines on how to achieve scalable abstractions and demystify some of the confusion around it. One could say, I'll try to abstract the abstraction itself :)

Transcript

1. A concrete approach to abstractions. with Terry Yanchynskyy
2. CONTENT Definition Examples Features and approach
3. is the concept of moving the focus from details and concrete implementation of things to the features that are relevant for a specific purpose, with a more general and abstract approach. Abstraction - from Latin abstractio(n-), from the verb abstrahere ‘draw away’
4. Objects, weather, traffic, navigation, human behaviour Arbitrary examples
5. Objects, weather, traffic, navigation, human behaviour Arbitrary examples Protocols: HTTP, TCP, UTD
6. Objects, weather, traffic, navigation, human behaviour Arbitrary examples Protocols: HTTP, TCP, UTD Django ORM (or any object-relational mapping for that matter) PostgreSQL MySQL SQLite Oracle other ORM Structured Query Language
7. Objects, weather, traffic, navigation, human behaviour Arbitrary examples Protocols: HTTP, TCP, UTD Django ORM (or any object-relational mapping for that matter) list(), str(), dict(), set(), tuple(), ...
8. Objects, weather, traffic, navigation, human behaviour Arbitrary examples Protocols: HTTP, TCP, UTD Django ORM (or any object-relational mapping for that matter) list(), str(), dict(), set(), tuple(), ... Python
9. Objects, weather, traffic, navigation, human behaviour Arbitrary examples Protocols: HTTP, TCP, UTD Django ORM (or any object-relational mapping for that matter) list(), str(), dict(), set(), tuple(), ... Python Your favorite web framework
10. 01010000 01111001 01110100 01101000 01101111 01101110 list(), str(), dict(), set(), tuple(), ... Python Model Controller View MVC model (MTV in Django) Resource Model Resource View Resource Controller x n App Some app
11. 01010000 01111001 01110100 01101000 01101111 01101110 list(), str(), dict(), set(), tuple(), ... Python Model Controller View MVC model (MTV in Django) Resource Model Resource View Resource Controller x n App Some app Interface Service Domain abstractions Implementation abstractions x n
12. 01010000 01111001 01110100 01101000 01101111 01101110 list(), str(), dict(), set(), tuple(), ... Python Model Controller View MVC model (MTV in Django) Resource Model Resource View Resource Controller x n App Some app Interface Service Domain abstractions Implementation abstractions Distributed system x n x n
13. 0. != Encapsulation • No comment
14. def user_view(request): user = request.user permission = Permission.objects.get(slug='view_profile') user_permission = UserPermission.objects.get(permission=permission, user=user) if user_permission.status === 'active' && user.is_active && user_permission: profile = UserProfile.objects.get(user=user) return Response(dict(first_name=profile.first_name, last_name=profile.last_name, avatar_url=profile.avatar) return Response(status_code=404) def user_view(request): user = request.user if user.has_permission('view_self’): return Response(ProfilePresenter(user.profile).data) return Response(status_code=404) User as an abstraction Has permission (feature) Has profile (an abstract child) Presenter abstraction
15. 1. Abstract application design. • Each component of the application knows what it's supposed to do. • It is isolated, provides only necessary details to the upper-level abstractions. • Example: Data validator, TCP connection handler, ORM
16. 2. Domain abstractions • Abstract domain design separately from your application design. • Example: ◦ BusinessOwner (domain abstraction) != User (application abstraction) • Reasons: ◦ two different abstractions ◦ domain-driven design ◦ clear separation ◦ domain logic is more prone to change ◦ easy to maintain ◦ easy to scale the abstractions
17. 3. Abstraction boundaries. • is a concrete set of states, behaviours, and functionality that the abstraction has. In other words, it's set in stone. • What are we abstracting and for what purpose? • For example, if we're trying to abstract a Bicycle, there's a question - who are we abstracting it for: a rider (consumer), a repair shop, a manufacturer, a designer, an advertising agency. Depending on the answer, the abstracted "bicycle" can have completely different set of properties and functionality, hence the implementation. • Scaling the abstraction often means extending its properties and functionality.
18. 4. Abstraction level and view. • is the entry point to the abstraction. • If we take the previous example, any of the cases can fit into one abstraction "tree", but on different levels and different view. • Question to ask: what is the level of my abstraction? • We can always scale the abstraction.
19. 5. Evolution • Abstractions do not break, they evolve. • It’s ok to go with new abstraction with changing requirements if our needs go outside of the previously defined boundaries. • “New” does not necessary mean discarding the old one and doing all the work all over again. • Scale the abstraction vertically.
20. 6. A ship will sail the way you name it • Name it, for what it is, not what it does. • It should be evident. • If you can guess what it’s about without looking into documentation or the implementation - it is a good name. • Unambiguous
21. 7. Scan for leaks and plug it. • Exception handling • Data isolation • Clear pre-requirements and interface
22. 8. DRY abstractions • Layer abstractions in such a way it’s abstracted (and implemented) only once • Consistent • Ready to scale
23. n. Sanity check. • Show it to a colleague and see if they understand and ask if they’d use it. • Would you be able to understand and use your abstract implementation year from now if you come across the same problem? • Abstractions are for people.
24. Thank you!