Question about entities

[Norbert Nemes]

Hello everyone

I have a question about entities.

In the clean architecture, people say that entities should not simply be data structures. They should have behaviors as well.

And they should not be passed out to the presenters.

So here is my scenario:

Shopping app.

You get a list of products from a web API, and these would map to one or more Item classes. 

As far as I can see right now, I have no behavior to attach to these things so they are simple data structures.

I have an Item repository (gateway) that fetches the object from the API and holds on to them sin some form (array). 

I also have a cart, that holds the items the user added to the cart. 

These later objects are entities and have behaviors, but what about Items? Since they are just data structures, I was wondering if it makes sense to have interactors transform them into DisplayItem data structures that would contain the minimal amount of information that the presenter needs to display. If the client comes back wanting to display more information, not only will I have to change the structure of the presenter and view, I would also have to change the DisplayItem class as well. Is this unavoidable or am I getting this entity thing wrong?

Regards,

Norbert

[Israel Fonseca]

The problem os exposing your entity (Item) to the view directly without the data structure (DisplayItem), is that at some point in the future the entity could start to have behaviors and another attributes that doesn't matter to the view.

Adding more attributes to the DisplayItem should be trivial anyway, so I don't think that's a huge problem.

BUT, TDD says that you should stick with the more simple solution, so you could start with the same Item for everybody and refactor it later without any hassle. It would be against the architectural guideline, but I think that could be a justifiable tradeoff in the early stages of development.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Christian B]

"is that at some point in the future the entity could start to have behaviors and another attributes that doesn't matter to the view."

Never thought it that way, thanks for that :)

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Norbert Nemes]

Thank you for your reply. I see where you're going with this :).
The thing is that I would like to introduce clean architecture to my group and they asked me for a code example to show how it would work. Since, unfortunately, the example they tasked me with is very simplistic, there WILL be no behaviors on the Item class and I think creating a DisplayItem, which would essentially be a clone of Item, will raise legitimate objections. However, since they are currently using a model that they are claiming that it does not pass out underlying entities, except that it does, I guess I have no choice but to over-engineer the example to make the point.

By the way, when you create the output data structure, would you advise to put into it jut the minimum amount of information that the view will use, or every field the entity has, just in case you need it later down the line?

[Israel Fonseca]

Sorry for the late response, I was playing with Google Inbox and started to miss some emails (LOL), now it's fixed. About your last question:

Certainly the minimum amount, you would leak unnecessary information otherwise. Imagine that if you put some unnecessary fields the guy that's implementing the view could think "strange, I created the form with all the fields, but there is this funny guy called 'fooBar' here, did I miss something?"

He would probably ask someone (and that's good), but you could save him of that by just being more specific and you would write less code too.

About the over engineering I would explain to the team that this is a tradeoff, but if everything is tested no fear at all to do it later (the refactoring) if they feel better with that. :)

Bonus: There is a video in the CC: Java Case Study, that Micah and Uncle Bob talks about this replication between view and entities, and they say that even the code is duplicated, the concepts are not, so its a 'valid duplication'. I don't remember exactly, but i think thats the second or third episode, and relates to date formatting. Give a search!  :)

 

--

[Norbert Nemes]

Thanks I found it. It was episode 3 :)
I was indeed worried about the duplication part. But now that I have an explanation, I feel much better :).
Maybe it's not that bad to create that DisplayItem after all :)

Thanks!