[opensuse-buildservice] Proposal to use service objects in models
Hi all, I'd like to start using service objects as a way of reducing the number of lines in the model classes. Please see this PR as an example: https://github.com/openSUSE/open-build-service/pull/2794 At the moment the way the models are organized seems to be done with the thinking that "if the code is related to the Repository class then put it in the Repository class" but I think it would be helpful to start organizing our code in a more structured way because many of the classes are just too big and hard to follow IMO. Here is a good article about ways in which this can be done. Some of these patterns we already have in the app i.e. decorators and policy objects. http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activere... Of course I'm open to alternative ideas or maybe you don't think that this is necessary at all and its fine the way it is? Let me know what you think. Thanks, Evan. -- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.03.2017 10:00, Evan Rolfe wrote:
Hi all, I'd like to start using service objects as a way of reducing the number of lines in the model classes. Please see this PR as an example:
https://github.com/openSUSE/open-build-service/pull/2794
At the moment the way the models are organized seems to be done with the thinking that
I don't understand Henne's comment - we use service classes all over. E.g. 8c53bce40f113487afbe29cd08fee98b9767d2ad is 3 years old. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hey, On 10.03.2017 14:45, Stephan Kulow wrote:
On 10.03.2017 10:00, Evan Rolfe wrote:
Hi all, I'd like to start using service objects as a way of reducing the number of lines in the model classes. Please see this PR as an example:
https://github.com/openSUSE/open-build-service/pull/2794
At the moment the way the models are organized seems to be done with the thinking that
I don't understand Henne's comment - we use service classes all over. E.g. 8c53bce40f113487afbe29cd08fee98b9767d2ad is 3 years old.
This is about what the current group of developers wants to use. Not about patterns that are already in the code-base, if we would follow that than everything would be okay ;-) Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hey, On 10.03.2017 10:00, Evan Rolfe wrote:
I think it would be helpful to start organizing our code in a more structured way because many of the classes are just too big and hard to follow IMO. Here is a good article about ways in which this can be done.
Some of these patterns we already have in the app i.e. decorators and policy objects.
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activere...
What we should decide together is not *if* we need to introduce a OO pattern to make code more manageable but *which*. I would like to avoid to have all patterns, depending on who, at times, likes which more. This I find equally confusing that stuffing everything into the model. So which of the patterns do we prefer and why? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
The only alternative I can think of for this particular problem is to use concerns but I don't like that idea because concerns do not address the fact that the class has too many responsibilities to begin with. They just split the class into multiple files. Can anybody think of an alternative pattern we could use here to better organise the code in the models? Or maybe somebody prefers to use concerns over service objects? On 14/03/17 12:19, Henne Vogelsang wrote:
Hey,
On 10.03.2017 10:00, Evan Rolfe wrote:
I think it would be helpful to start organizing our code in a more structured way because many of the classes are just too big and hard to follow IMO. Here is a good article about ways in which this can be done.
Some of these patterns we already have in the app i.e. decorators and policy objects.
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activere...
What we should decide together is not *if* we need to introduce a OO pattern to make code more manageable but *which*. I would like to avoid to have all patterns, depending on who, at times, likes which more. This I find equally confusing that stuffing everything into the model.
So which of the patterns do we prefer and why?
Henne
-- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Hey, On 14.03.2017 13:49, Evan Rolfe wrote:
On 14/03/17 12:19, Henne Vogelsang wrote:
On 10.03.2017 10:00, Evan Rolfe wrote:
I think it would be helpful to start organizing our code in a more structured way
What we should decide together is not *if* we need to introduce a OO pattern to make code more manageable but *which*.
So which of the patterns do we prefer and why?
The only alternative I can think of for this particular problem is to use concerns but I don't like that idea because concerns do not address the fact that the class has too many responsibilities to begin with. They just split the class into multiple files. Can anybody think of an alternative pattern we could use here to better organise the code in the models? Or maybe somebody prefers to use concerns over service objects?
I do prefer the interactor pattern over general service objects for the same reason that I prefer them over concerns: single-purpose code... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 14/03/17 13:14, Henne Vogelsang wrote:
I do prefer the interactor pattern over general service objects for the same reason that I prefer them over concerns: single-purpose code...
Henne
Do you have any links to articles that explain the interactor pattern for those of us who are not familiar with it? Also you say that you prefer them to service objects and concerns because "single-purpose code.."? Can explain what that means please? -- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hey, On 14.03.2017 14:25, Evan Rolfe wrote:
On 14/03/17 13:14, Henne Vogelsang wrote:
I do prefer the interactor pattern over general service objects for the same reason that I prefer them over concerns: single-purpose code...
Do you have any links to articles that explain the interactor pattern for those of us who are not familiar with it?
https://semaphoreci.com/community/tutorials/how-to-reduce-controller-bloat-w... https://mkdev.me/en/posts/a-couple-of-words-about-interactors-in-rails https://github.com/collectiveidea/interactor
Also you say that you prefer them to service objects and concerns because "single-purpose code.."? Can explain what that means please?
Well service objects tend to grow to have many responsibilities, while interactors are by definition limited to one responsibility. This means they are harder to extract but people do not end up "just" moving code around to make complexity metrics happy. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 14/03/17 13:45, Henne Vogelsang wrote:
https://semaphoreci.com/community/tutorials/how-to-reduce-controller-bloat-w...
https://mkdev.me/en/posts/a-couple-of-words-about-interactors-in-rails
https://github.com/collectiveidea/interactor
Well service objects tend to grow to have many responsibilities, while interactors are by definition limited to one responsibility. This means they are harder to extract but people do not end up "just" moving code around to make complexity metrics happy.
Henne
"while interactors are by definition limited to one responsibility" This is not true, there is nothing to stop you putting too many responsibilities in one interactor. Take a look at the code for the interactor class, its just a service object which uses an Openstruct for the arguments and includes a hooks module: https://github.com/collectiveidea/interactor/blob/master/lib/interactor.rb I think we are comparing apples and oranges here. The interactor gem uses service objects as a way of organising code but gives you a few extra things like context objects and hooks. So I think we have two questions now in the discussion: 1. Do we want to use service objects? 2. Do we want to use a gem to organise our service objects and potentially other kinds objects? My answer to #1 is of course yes. As for #2 I think thats also a yes but I would say there are several other gems that give you more structure to your rails app which we should consider. For example the rectify gem looks good to me as well, it includes 3 other design patterns too: https://github.com/andypike/rectify A third gem which offers a structure to organise code is TrailBlazer. Its quite a bit more radical in its approach than interactor and rectify though.. https://github.com/trailblazer/trailblazer Though maybe question #2 should be done in a seperate discussion? Keep in mind that the service object I coded can be easily turned into an interactor object or and rectify command object should we choose to use one of those gems. I've never used any of these gems myself though, does anybody have any experience using something like this? -- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Here is a survey to vote about this decision: https://goo.gl/forms/8HeBcM9f8DcIXUX33 -- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hey, On 14.03.2017 16:23, Evan Rolfe wrote:
Though maybe question #2 should be done in a seperate discussion?
Alright. Fine with me :-) Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Ok so in regards to using service objects - is everybody okay with that? We can start using service objects now and then look at using a gem to give us a more defined structure to use in another discussion? If its okay to use service objects I would like to merge that PR sooner rather than later incase any code conflicts get introduced while we wait. On 16/03/17 15:18, Henne Vogelsang wrote:
Hey,
On 14.03.2017 16:23, Evan Rolfe wrote:
Though maybe question #2 should be done in a seperate discussion?
Alright. Fine with me :-)
Henne
-- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
El jue, 16-03-2017 a las 15:32 +0000, Evan Rolfe escribió:
Ok so in regards to using service objects - is everybody okay with that?
I'm ok with that :D
We can start using service objects now and then look at using a gem to give us a more defined structure to use in another discussion? If its okay to use service objects I would like to merge that PR sooner rather than later incase any code conflicts get introduced while we wait.
On 16/03/17 15:18, Henne Vogelsang wrote:
Hey,
On 14.03.2017 16:23, Evan Rolfe wrote:
Though maybe question #2 should be done in a seperate discussion?
Alright. Fine with me :-)
Henne
-- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 03/16/2017 05:21 PM, mdeniz wrote:
El jue, 16-03-2017 a las 15:32 +0000, Evan Rolfe escribió:
Ok so in regards to using service objects - is everybody okay with that? I'm ok with that :D Me too :)
We can start using service objects now and then look at using a gem to give us a more defined structure to use in another discussion? If its okay to use service objects I would like to merge that PR sooner rather than later incase any code conflicts get introduced while we wait.
On 16/03/17 15:18, Henne Vogelsang wrote:
Hey,
On 14.03.2017 16:23, Evan Rolfe wrote:
Though maybe question #2 should be done in a seperate discussion? Alright. Fine with me :-)
Henne
-- Evan Rolfe Full Stack Web Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
David Kang
participants (5)
-
David Kang -
Evan Rolfe -
Henne Vogelsang -
mdeniz -
Stephan Kulow