Skip to main content

Timeline for Design Patterns for creating tasks

Current License: CC BY-SA 3.0

5 events
when toggle format what by license comment
Jun 28, 2014 at 10:26 comment added Marjan Venema Oh and using observer would make your observer of the Entity certainly non-anemic... Your Entity class still may or may not be anemic, but the observer certainly won't. The desire not to have anemic classes is very good, but you should still not put code in a class just to make it non-anemic. The code to instantiate the Task indeed does not belong in Entity as it would introduce unwanted (and unwarranted) coupling. Any code added to Entity should be related to Entity.
Jun 28, 2014 at 10:19 comment added Marjan Venema Perhaps your confusion stems from treating design patterns as code examples. A design pattern may have a code example to explain it, but it is never limited to that example. Design patterns are much more than just code examples. Design patterns are ways of talking about code and talking about general solutions to common problems. It is up to the developer to apply a design pattern to his/her specific problem by amending the explanatory example to his/her specific case.
Jun 28, 2014 at 10:16 comment added Marjan Venema Whether your classes are anemic has nothing to do with using or not using Observer. Furthermore the Observer pattern is not restricted to passing along just "simple" parameters. The observed can pass along anything you need to the observer. So you could simply pass along the Entity instance that was changed and the observer can pick whatever it needs.
Jun 28, 2014 at 0:47 comment added Fernando Mondo I have not thought about use the observer pattern because I thought would still anemic. Furthermore, I tried to make the example simple but, actually, for create a task I use many properties of my Entity. e.g. new Task("description", entity.PropertyA, entity.PropertyB, entity.PropertyC);
Jun 27, 2014 at 17:57 history answered Marjan Venema CC BY-SA 3.0