What do programmers think about "Fluent Interface's" ?
-
I have seldom written class along those lines, although the very useful LINQ does! One alternative I like is object initializer: var o = new MyObject { Name = "foo", ID = Guid.NewGuid(), Foo = new Bar { Snafu = true, }, };
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Thank you for the reply! :-D
-
I have researched into "Fluent Interface development", http://en.wikipedia.org/wiki/Fluent_interface[^] and would like to know what the code project community thinks about them... Do people like using them? What scenarios would you use them in? Alternatives? I use them for objects that require too many arguments or optional inputs.
ICustomerFactory c = new CustomerFluentFactory.Create()
.WithName("James")
.WithID();I use them for classes where there are logically linked discrete behaviours, such as validation. When you validate a property it is common to check multiple things on it, and a fluent interface is a nice way to do this.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
I have researched into "Fluent Interface development", http://en.wikipedia.org/wiki/Fluent_interface[^] and would like to know what the code project community thinks about them... Do people like using them? What scenarios would you use them in? Alternatives? I use them for objects that require too many arguments or optional inputs.
ICustomerFactory c = new CustomerFluentFactory.Create()
.WithName("James")
.WithID();venomation wrote:
What scenarios would you use them in?
Any place where I want to help someone who is "using" that part of the code. It makes life easier for those who need to work with it, just a good documentation or an example would.
venomation wrote:
Alternatives?
I prefer to implement the
Decoratorpattern :)I are Troll :suss:
-
I use them for classes where there are logically linked discrete behaviours, such as validation. When you validate a property it is common to check multiple things on it, and a fluent interface is a nice way to do this.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Pete O'Hanlon wrote:
such as validation
Thanks for the reply, that's a good idea I may start applying that concept also :D
-
venomation wrote:
What scenarios would you use them in?
Any place where I want to help someone who is "using" that part of the code. It makes life easier for those who need to work with it, just a good documentation or an example would.
venomation wrote:
Alternatives?
I prefer to implement the
Decoratorpattern :)I are Troll :suss:
Thanks for the comment :D
Eddy Vluggen wrote:
I prefer to implement the
Decoratorpattern :)I am familiar with that design pattern, but doesn't that seem more complicated than a simple fluent design? Or is there a way of making a fluent design also a decorator...?
-
Thanks for the comment :D
Eddy Vluggen wrote:
I prefer to implement the
Decoratorpattern :)I am familiar with that design pattern, but doesn't that seem more complicated than a simple fluent design? Or is there a way of making a fluent design also a decorator...?
venomation wrote:
I am familiar with that design pattern, but doesn't that seem more complicated than a simple fluent design?
I guess it is. A template of the pattern makes it quite easy to implement, it just takes a bit more time. Might depend on what structures you're most familiair with.
venomation wrote:
Or is there a way of making a fluent design also a decorator...?
Not that I'm aware of.
I are Troll :suss:
-
venomation wrote:
I am familiar with that design pattern, but doesn't that seem more complicated than a simple fluent design?
I guess it is. A template of the pattern makes it quite easy to implement, it just takes a bit more time. Might depend on what structures you're most familiair with.
venomation wrote:
Or is there a way of making a fluent design also a decorator...?
Not that I'm aware of.
I are Troll :suss:
Thanks again!
-
Thanks again!
-
I have researched into "Fluent Interface development", http://en.wikipedia.org/wiki/Fluent_interface[^] and would like to know what the code project community thinks about them... Do people like using them? What scenarios would you use them in? Alternatives? I use them for objects that require too many arguments or optional inputs.
ICustomerFactory c = new CustomerFluentFactory.Create()
.WithName("James")
.WithID();venomation wrote:
What scenarios would you use them in?
I doubt I would ever use them. Especially since the only touted benefit is that it makes it more 'readable' which is a subjective term that one can use to rationalize almost anything.
venomation wrote:
I use them for objects that require too many arguments or optional inputs.
I don't see that your example has "too many arguments" in the first place. But generally something that does in fact have too many arguments might have a design problem. And certainly if one sees a lot of code like that (versus say 1 out of 1000) then it would seem very likely that there are design problems.
-
I have researched into "Fluent Interface development", http://en.wikipedia.org/wiki/Fluent_interface[^] and would like to know what the code project community thinks about them... Do people like using them? What scenarios would you use them in? Alternatives? I use them for objects that require too many arguments or optional inputs.
ICustomerFactory c = new CustomerFluentFactory.Create()
.WithName("James")
.WithID();I think it has a needless apostrophe.
-
venomation wrote:
What scenarios would you use them in?
I doubt I would ever use them. Especially since the only touted benefit is that it makes it more 'readable' which is a subjective term that one can use to rationalize almost anything.
venomation wrote:
I use them for objects that require too many arguments or optional inputs.
I don't see that your example has "too many arguments" in the first place. But generally something that does in fact have too many arguments might have a design problem. And certainly if one sees a lot of code like that (versus say 1 out of 1000) then it would seem very likely that there are design problems.
jschell wrote:
might have a design problem
Thanks for the comment! :laugh: