11 Replies Latest reply on Dec 13, 2008 3:26 PM by Ronald van Kuijk

    task component interface comments

    Tom Baeyens Master

      Hi Alejandro,

      1) i'ld like to make the user provided taskId optional. so i think it would be good to have an extra method

      TaskService.newTask()


      that creates a new task without id. upon saving such a task, the command will detect this and automatically assign an id based on the DB primary key that has been generated by the DB after saving it. That way you don't force users to think of how they are going to obtain a unique id if they just want to add a task.

      2) all the setters in the task could return the task itself. also a save method could be added to the task that delegates to the saveTask of the service it came from. then you could get shorter, more readable task creations like this:

      taskService.newTask()
       .setName("Do laundry")
       .setDueDate(tomorrow)
       .setAssignee("johndoe")
       .save();


      WDYT ?

        • 1. Re: task component interface comments
          Joram Barrez Master

          1) Definitely agreed!

          2) You really like fluent interfaces ;-)
          I like the idea, but I shouldn't (mis)use the getters for this purpose (ie not following the JavaBean spec).

          • 2. Re: task component interface comments
            Tom Baeyens Master

             

            "jbarrez" wrote:
            2) You really like fluent interfaces ;-)
            I like the idea, but I shouldn't (mis)use the getters for this purpose (ie not following the JavaBean spec).


            i didn't think of violating javabean spec. but is that actually a problem ?


            • 3. Re: task component interface comments
              Joram Barrez Master

              I don't think it is a real 'problem', but my for my feeling it seems wrong.

              Isn't this 'more clean':

              taskService.newTask()
              .withName("TestTask")
              .withDueDate(someDay)
              .withActor("Joram");

              This way you can have the fluent interface (which I agree is nice to have) and the setters. Downside is that that withXXX() methods are almost the same as the setters.

              Ofc, this is just my opinion, perhaps I'm completely wrong on this one.

              • 4. Re: task component interface comments
                Tom Baeyens Master

                good idea, but i still like the setters more. as the setters can also be used in the normal way:

                Task task = taskService.newTask();
                task.setName();
                task.setDueDate(someDay);
                task.setAssignee("johndoe");
                task.save();


                that would be harder with the 'withXxx' methods

                • 5. Re: task component interface comments
                  Alejandro Guizar Master

                  Creating tasks without a user-provided ID is a must for usability. The generated ID will be the database ID converted to string.

                  As for task creation, I concur with Joram that (ab-)using the setters for a fluent interface goes against the JavaBeans design principles. Introducing a set of methods called withXXX to the Task interface is also a no-go because they mostly duplicate the setXXX methods.

                  I propose introducing a TaskBuilder buildTask() method to the TaskService, and move the withXXX methods to TaskBuilder. Actually I'd prefer to drop the "with" prefix, as follows.

                  Task task = taskService.buildTask()
                   .name("test")
                   .dueDate(today)
                   .asignee(me)
                   .done();

                  TaskBuilder does not even have to be an interface, because it simply delegates to methods in the Task interface.

                  • 6. Re: task component interface comments
                    Bernd Ruecker Master

                    Why so complicated? The setter with a return value doesn't break anything if you don't use the return value!

                    Why stick to conventions without benefit and introducing additonal components to come around with it?

                    I would vote for the setXXX with returning the object approach proposed by Tom...

                    • 7. Re: task component interface comments
                      Ronald van Kuijk Master

                       

                      The setter with a return value doesn't break anything if you don't use the return value!
                      Is that still the case with all these reflection-using frameworks? If so I'm in favour as well

                      • 8. Re: task component interface comments
                        Bernd Ruecker Master

                        I think the return value is not part of the method signature, or is it?

                        • 9. Re: task component interface comments
                          Tom Baeyens Master

                          TaskBuilder is definitely not good.

                          Task with setter is the way to go.

                          If we would not like the Task return value on the setters, then we should make them void and disable the fluent interface.

                          But that brings me to the point that I didn't see a good argument against return Task from the setters. the JavaBean spec and reflection frameworks arguments don't make sense in my opinion.

                          But it is not a big deal. Alejandro, you take your pick of the return values for the setters.

                          • 10. Re: task component interface comments
                            Alejandro Guizar Master

                            Beyond the usual conventions, there are two things I dislike about returning Task from the setters:

                            1. the "set" prefix prevents a true "fluent" method chain. Compare the method chains with and without the TaskBuilder.
                            2. what if I want to add comments, subtasks, etc? the task interface does not have methods for that, you have to go back to the task service. The task builder can "remember" the task service that created it and invoke it internally.

                            task = taskService.buildTask()
                             .name("report expenses")
                             .due(today)
                             .subTask()
                             .name("gather receipts")
                             .due(beforeLunch)
                             .subTask()
                             .name("capture amounts")
                             .due(beforeLeaving)
                             .done();


                            TaskBuilder is definitely not good. Task with setter is the way to go.

                            I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different?

                            • 11. Re: task component interface comments
                              Ronald van Kuijk Master

                               

                              I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different?


                              You got a point there...