Closed theo-damiani closed 3 years ago
Hey @theo-damiani!
So after our meeting today and the concerns that you pointed out about the multiple adapters, I have been giving it a thought and I have come up with this proposal:
* The `Database` interface should be an abstract API for storing the objects that our app knows (e.g. `Task` instances). This means that the interface should have methods like: * `putTask(Task task)` * `getTask(int taskId)` * ... * The specific database implementations should take care of the logic underneath the object storage. This means that, for example, the `VolatileDatabase` can serialize the objects and store them in a `HashMap`. The `FirebaseDatabase` that I'm working on will do something else. But the key here is that all of them share the same API (the one defined by `Database`), and each implementation takes care of the details (just like if they were "drivers" for using a specific database backend).
The main upside that I see here is that we no longer need adapters, and every time we create a new kind of object (like TODO lists, notes...) we only have to define the new methods in the
Database
interface and their corresponding implementations.I would love to know your thoughts on this, what do you think?
Thanks for your thoughts @YagoGG !
I think it will be great to keep one "main" adapter so we can split the database implementation to the task/todo/.... And so maybe in the future if we add a cached database or whatever you want, related to the database we only have to add a "layer". So we have a Decorator pattern. And if we want to add voice notes we just need to create the class and add methods in the main adapter.
Personally, I will go for this. I think it's more modular and we can work independently. Tell me if you think it's good. But it's what you said. We just keep one big adapter.
here a small drawing to maybe better understand:
Thanks for the drawing and the detailed explanation, @theo-damiani! :)
So if I understood correctly, the MainAdapter
's job would be to serialize & deserialize the objects, and then store them in the corresponding database?
The issue that I see in that case is that each database has a different implementation, and not all of them require serialization. To give you an example:
VolatileDatabase
can store the objects directly without serialization, e.g. HashMap<Integer taskId, Task task>
.FirebaseDatabase
will serialize the objects indeed, but using its own format (probably JSON).That's why I think that the actual logic to convert the object to whatever accepts the database should depend on the Database
implementation itself, instead of using serialization and assuming that allDatabase
s will store serialized objects in key-value pairs. Makes sense?
Ok! I see, I missed the point on serialization and the fact that it might be different. You write I will follow your first explanation: one database interface with methods (putTodo, put....) and no adapters.
I will change and commit today the Database Interface so you can work on your own firebase implementation.
There's no rush at all, this is not blocking me for now as I am now working on some tests. Take all the time you need. :)
Cheers!
Hey @theo-damiani!
So after our meeting today and the concerns that you pointed out about the multiple adapters, I have been giving it a thought and I have come up with this proposal:
Database
interface should be an abstract API for storing the objects that our app knows (e.g.Task
instances).This means that the interface should have methods like:
putTask(Task task)
getTask(int taskId)
VolatileDatabase
can serialize the objects and store them in aHashMap
. TheFirebaseDatabase
that I'm working on will do something else. But the key here is that all of them share the same API (the one defined byDatabase
), and each implementation takes care of the details (just like if they were "drivers" for using a specific database backend).The main upside that I see here is that we no longer need adapters, and every time we create a new kind of object (like TODO lists, notes...) we only have to define the new methods in the
Database
interface and their corresponding implementations.I would love to know your thoughts on this, what do you think?