code is emotional
Giovanni Montano wrote:I am wondering which design pattern I should use to do that to avoid duplications
...
1)REALLY BAD. Repeat all the code every time writing consecutive methods as
Junilu Lacar wrote:
Giovanni Montano wrote:I am wondering which design pattern I should use to do that to avoid duplications
...
1)REALLY BAD. Repeat all the code every time writing consecutive methods as
I doubt there's a named design pattern specifically for something like this. It's good you recognize that the above code is bad though. I'm guessing you saw a "pattern" of repetition in the names and thought "Well, this is bad because I'd have to duplicate a lot of code each time there was another point in time I need to insert."
Junilu Lacar wrote:
When I see this kind of duplication, I immediately think "objectify and parameterize it."
To "objectify", I'd think in terms of what object would be responsible and what the conversation with that object might look like. To "parameterize", I'd look at the differences in the names and represent that as one or more parameters instead. Of course, I'd take care to limit the number of parameters to about three or four max. If there are more than four parameters, that's when I turn to the Parameter Object pattern.
Junilu Lacar wrote:
I might start with something like this:
(Edit: accidentally clicked "Submit" instead of "Preview")
That seems pretty decent. Now I have a MyCalendar object to which I can say "Insert this event at this time and date". Through testing and carefully reading and considering the semantics of such code, I might think "Well, it's not clear whether the Calendar will reference the same event or not. Is it copying the event I pass in or just keeping a reference to the original object? Will any change to the event object outside the calendar be reflected in all the entries I inserted before? What behavior would be the least surprising? How can I design this API to make the semantics clearer?"
Junilu Lacar wrote:
Then I'd probably experiment with something like this:
With this code in front of me, I'd ask the same questions I asked before, always going back to the fundamental questions of "Does this code make sense? Can someone read it and easily understand what's going on?" Then I just keep experimenting and refactoring until I can answer those questions satisfactorily.
myCal.insert(event);
myCal.insert(new Event(event, now.plusHours(15)));
code is emotional
Giovanni Montano wrote:so I want one class that does one thing, so want to get rid of the calendar business logic away from the view, and building a class `MyCalendar` looks nice to me as you suggest.As consequence I do not need to copy the event but just pass a reference to make my view class semantically clearer because more short and with one only responsibility, namely showing the user interface (1).
So I am going to build a class `MyCalendar` with all the needed android imports
and this class will have a method called insert( Event event, LocalDataTime moment){} (2)
Junilu Lacar wrote:
Giovanni Montano wrote:so I want one class that does one thing, so want to get rid of the calendar business logic away from the view, and building a class `MyCalendar` looks nice to me as you suggest.As consequence I do not need to copy the event but just pass a reference to make my view class semantically clearer because more short and with one only responsibility, namely showing the user interface (1).
So I am going to build a class `MyCalendar` with all the needed android imports
and this class will have a method called insert( Event event, LocalDataTime moment){} (2)
The statement marked (1) is contradictory to (2) -- If the responsibility is to simply show the user interface, then why do you have method that changes the internal state of the Calendar? Managing state seems like it's the responsibility of a Model layer class, not a View/Presentation layer class. The view/presentation simply handles the visual representation of the model. I would imagine you'd have at least two classes: Calendar and CalendarView.
A)Create a MyEvent class for representing the subset of events you want to create (e.g. year, month, day, starthr, startmin, endhr, endmin, title, etc.).
B)Change your InsertCalendarEvent() to take a MyEvent as argument: so this function becomes general purpose.
C)reate an InsertCalendarEvents() method with a Collection of MyEvents as argument. This method would just iterate through the collection (using an iterator) and call InsertCalendarEvent().
D)When you need to insert the events, you would just have to generate a collection of MyEvents (for example an ArrayList) and invoke InsertCalendarEvents().
(Here, MyEvent plays a passive DTO role. But you could also opt for an active record approach and let MyEvent save itself to the calendar (in this case you should sore the ID returned in the URI in case the event should be modified later on).)
code is emotional
code is emotional
code is emotional
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |