Please enable JavaScript.
Coggle requires JavaScript to display documents.
Abstraction (the many meaning) (Hide details simplify (The process…
Abstraction (the many
meaning)
Hide details
simplify
The process (steps) to do something (function)
The choice of representation (data abstraction, polymorphism ?) - but in the end, these are the functions to perform in the data that counts - constraints on a type
Interconnexion (mediator abstracts this)
The choice of implementation (which concrete class,
how to do something)
The process of building something (Monoid, Cat)
The process of sequencing something (Monad)
The generalized process (data, ast, interpreter) - interpreter is just specific kind of function... data IN, effect OUT
Select relevant info
Monoid... how things are built
AST keeps info (transformation) vs
Money map erase info (abstraction)
Whether or not it is good depends on what you erase (erasing the components of an average... aggregates of flow... not good to erase USER data)
Pick some characteristics as relevant
of an implementation or some data... ignore others
https://gamedevelopment.tutsplus.com/tutorials/quick-tip-the-oop-principle-of-abstraction--gamedev-2386
Example
: on my color I only care about it being à Monoid in this specific case (defining Monoid for image), to define the image though, I need to know nothing...
Stepanov
(math to gen programming): two steps for algorithms, first make them work, then figure out on what kind of stuff they work (abstraction)
Organizing
Layers ...
Horizontal ...
Point of connection
An abstraction defines a concept
Which any model that satisfies can plug to
Like a hole to accept à given shape
The shape also contains properties (it is mostly not about the syntax... name args, but about the constraints)
So more like graph (and à DI
framework is a way to assemble
the graph)
Leaks
Assumptions broken: example Monoid color
Something not really hidden
Weak abstraction
(interface/ concept /
point of connection)
Look at the filtered characteristics (relevant) and therefore the number of constraints imposed
The more constraints, the less model there are
Most abstraction are in fact directly pointing at an implementation (example of virtual getters returning const&)
The more constraints, the less models, the more power they offer, the more difficult to grasp they are
Easy to add superfluous constraints. Stay simple, with idiomatic Data structure for instance, minimize constraints for the user, and leads to better benefit over cost for user (bad example : unneeded inheritance - ex of data for mig step - custom vector wrapper - types non regular...)
Program to abstraction
Do not care about layer....
State your dependencies (constraints) - the relevant parts - minimal
Later something assembles the pieces
About point of connection...
:question:
Let you select one point of connection for a concept:
below it you can unify a lot of models
you rarely program with the point of connection (wrappers)
basically, reduce the graph to a point to build a new forest on it
example of iterators, foldable... dfs allows to put the graph in it but you rarely program with barre iterator, you build range and algo
Forms of abstraction
& selection of abstraction
Functions (hide details), classes, type parameters (holes with or without constraints) or data (recipe, as code is).
Each way to encode an abstraction has its implications on how to use it... and it depends on what you abstract.
Are there two meaning?
cause dev think
virtual... they think dynamically switchable
point of connection
follows
from the fact we reduced the selected characteristics
the process of taking away info
the resulting abstraction
The abstraction is a reduction of information, a selection of the information needed to handle a task. Language constructs allow to reify these in the form of requirements, arguments to a function, etc.
The mechanism of the language are based on some things, primarily names. They imply a way to signal something comply with an abstraction: arguments to pass, interface to implement, members to contain...
So the
other side
is how to
comply to an abstraction,
and the incentive to comply to abstractions to make for instance a type à Monoid in order to profit from the rich set of tools available on it.
Depend on language
.
This defines a
point of connection
. Anything that complies can plug into it. Call with right arguments, support some interface, obey these laws...
Means of abstraction
Data is powerful abstraction: Abstract how it is used (Spec vs how), when it is used (stored), allows inspection, is very easy to understand (but is not supported in Typed Lang)
Parametric polymorphism (no knowledge required)
Ad-hoc polymorphism (knowledge required)
Functions, HOF (better than adhoc for flexibility - but less practical when you need type associated to fct - example of à tree with typeclasses for routing)
examples
Indexing into a container... should work for map or vector... abstraction for something that can be indexed (with index type being a dpdt type... not like Haskell, but like Clojure)
RGBA color... abstract way to encode the color... make it generic and only ask for constraints upon use cases... leads to types pretty empty... behaviors on them is what counts
Graph and DFS... foldable or iterable... depends on the idiomatic usage of the language