Multiple methods vs Single method with enum
-
Harley L. Pebley wrote:
Any opinions?
There are bigger problems to worry about would be my thought.
Other problems, of course. Relative size is a matter of opinion. :-) In this case, the API is the primary way for users to access the rest of the product. It's pretty important.
-
According to Robert C. Martin's Clean Code, use different functions: the function names give you additional information on the purpose, thus making the code better readable.
Thanks for the pointer to Clean Code. I obviously need to go reread that as I'd quite forgotten RCM had discussed this topic.
-
Interesting. How do you see multiple methods violating DRY?
-
Interesting. How do you see multiple methods violating DRY?
Harley L. Pebley wrote:
How do you see multiple methods violating DRY?
Multiple methods do not violate the principle. Repeating a specific value in a methodname, while you have declared an enum that holds the same information would; aight, granted, DRY does not directly apply to method-names. It is as effective as copying sprocs to a slightly different name and changing a single integer that's updated. Even if you do not copy the sproc-body, you'd still end up with more securables and more failure-points. The compiler will also not warn about missing methods when someone extends the enum. The biggest difference is that it makes it impossible to use the method in a loop, passing all the enum-values (and that might be a good thing) From another perspective; A boolean can be viewed as an enum with two values. I can see the value of methodnames like "Hide" and "Show", even with the existence of the Visible-property. That's propably because their semantics add value; it wouldn't if those methods were called "VisibleTrue" and "VisibleFalse" - that's just a crappy way of saying "Visible = false". ..then again, I upvoted jschell; the compiler will accept both, and there is no "one true way" of doing things. Anything that helps one to maintain the code is welcome.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Harley L. Pebley wrote:
How do you see multiple methods violating DRY?
Multiple methods do not violate the principle. Repeating a specific value in a methodname, while you have declared an enum that holds the same information would; aight, granted, DRY does not directly apply to method-names. It is as effective as copying sprocs to a slightly different name and changing a single integer that's updated. Even if you do not copy the sproc-body, you'd still end up with more securables and more failure-points. The compiler will also not warn about missing methods when someone extends the enum. The biggest difference is that it makes it impossible to use the method in a loop, passing all the enum-values (and that might be a good thing) From another perspective; A boolean can be viewed as an enum with two values. I can see the value of methodnames like "Hide" and "Show", even with the existence of the Visible-property. That's propably because their semantics add value; it wouldn't if those methods were called "VisibleTrue" and "VisibleFalse" - that's just a crappy way of saying "Visible = false". ..then again, I upvoted jschell; the compiler will accept both, and there is no "one true way" of doing things. Anything that helps one to maintain the code is welcome.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
Repeating a specific value in a method name, while you have declared an enum that holds the same information would;
Ah, right. I agree, it would be pretty confusing to have the name and an enum both. Sorry, I guess in my original post I didn't make it clear that I intended those to be mutually exclusive options. Thanks.
-
Other problems, of course. Relative size is a matter of opinion. :-) In this case, the API is the primary way for users to access the rest of the product. It's pretty important.
Harley L. Pebley wrote:
It's pretty important.
No it isn't. Which is obvious based on your experience. Both exist and both are used. Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'. And it is possible that one or the other is better based on specific usage (class and how it will be used.) And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
-
Eddy Vluggen wrote:
Repeating a specific value in a method name, while you have declared an enum that holds the same information would;
Ah, right. I agree, it would be pretty confusing to have the name and an enum both. Sorry, I guess in my original post I didn't make it clear that I intended those to be mutually exclusive options. Thanks.
-
Harley L. Pebley wrote:
It's pretty important.
No it isn't. Which is obvious based on your experience. Both exist and both are used. Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'. And it is possible that one or the other is better based on specific usage (class and how it will be used.) And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
jschell wrote:
No it isn't. Which is obvious based on your experience.
LOL. Pretty condescending statement, don't you think?
jschell wrote:
Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'.
Sure, that's one way to measure 'better.' And there are two sides to that bug count: the users' and the implementers'. But there are other measurements of 'better' too: ease of discover-ability, semantic clarity, ease of use and ease of implementation among them. It's these more subjective qualities that I was looking for feedback and opinion on.
jschell wrote:
And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
Sorry, I don't understand the relevance of this question. Are you still trying to make the point that this isn't important? If so, that's fine. I simply disagree. The floorplan and architecture of a house is just as important as the quality of materials and workmanship in framing, plumbing and electrical work. If any of it sucks, home buyers will look elsewhere. The API of a public library is as important as the private implementation. If either one sucks, users will look for alternatives.
-
jschell wrote:
No it isn't. Which is obvious based on your experience.
LOL. Pretty condescending statement, don't you think?
jschell wrote:
Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'.
Sure, that's one way to measure 'better.' And there are two sides to that bug count: the users' and the implementers'. But there are other measurements of 'better' too: ease of discover-ability, semantic clarity, ease of use and ease of implementation among them. It's these more subjective qualities that I was looking for feedback and opinion on.
jschell wrote:
And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
Sorry, I don't understand the relevance of this question. Are you still trying to make the point that this isn't important? If so, that's fine. I simply disagree. The floorplan and architecture of a house is just as important as the quality of materials and workmanship in framing, plumbing and electrical work. If any of it sucks, home buyers will look elsewhere. The API of a public library is as important as the private implementation. If either one sucks, users will look for alternatives.
Harley L. Pebley wrote:
LOL. Pretty condescending statement, don't you think?
Not sure I understand that. Perhaps you misunderstood what I was saying. You already pointed out that you have seen both used AND that it is unclear to you that either is better. Those two things together represent your "experience" and it is that to which I was referring.
Harley L. Pebley wrote:
But there are other measurements
I doubt it. Especially the "ease of implementation". But if you know of a way to measure (some objective process that arrives at a numerical result) then I would certainly like to hear about. Of course someone might just like it better, but that isn't the same.
Harley L. Pebley wrote:
Sorry, I don't understand the relevance of this question.
The answer to the original question is not relevant unless you can show that the number of problems caused by this are significant. That can only occur if either your application has a very low number of bugs caused by the things I mentioned (which is where I see most bugs occur) or because, in fact, this idiom causes a massive number of bugs in your application (overriding the other type.) If that isn't your situation then focusing on reducing the other types of bugs is more effective.
-
Harley L. Pebley wrote:
LOL. Pretty condescending statement, don't you think?
Not sure I understand that. Perhaps you misunderstood what I was saying. You already pointed out that you have seen both used AND that it is unclear to you that either is better. Those two things together represent your "experience" and it is that to which I was referring.
Harley L. Pebley wrote:
But there are other measurements
I doubt it. Especially the "ease of implementation". But if you know of a way to measure (some objective process that arrives at a numerical result) then I would certainly like to hear about. Of course someone might just like it better, but that isn't the same.
Harley L. Pebley wrote:
Sorry, I don't understand the relevance of this question.
The answer to the original question is not relevant unless you can show that the number of problems caused by this are significant. That can only occur if either your application has a very low number of bugs caused by the things I mentioned (which is where I see most bugs occur) or because, in fact, this idiom causes a massive number of bugs in your application (overriding the other type.) If that isn't your situation then focusing on reducing the other types of bugs is more effective.
jschell wrote:
Perhaps you misunderstood what I was saying.
Perhaps so. Typically when I hear people refer to "in my (your) experience" they are referring broadly to the sum total of all experiences, not narrowly to the one under discussion. I apologize. As to the rest of our conversation, we're going meta into the importance/relevance of the question relative to other things and away from my original question. I think we view things through different lenses and just disagree, which is cool. Different perspectives provide food for thought. Thanks for the feedback.
-
Over the years I seem to go back and forth over what I prefer regarding multiple method names vs a single method with a discrimination parameter. Sometimes I prefer multiple, similar methods:
LogError(sometext) LogWarning(sometext)And other times I see it more as a single method with an enumerated parameter:
Log(type, sometext)It seems pretty subjective as to what conveys intent best and makes using the class easier. Any opinions? (Particularly interested in thoughts that contain an objective reason. I already have subjective thoughts that keep varying over time. :-D ) Thanks.
In Java I use the log.Log(Level.type, message) and In C# I use the log.LogWarning(message) or another. I find it pretty annoying in Java. They clearly made this better choice - better choice in relation to design e.g extensibility and maintainability. However, I need to work more with the Editor when writing this (more choices and Level import). In this case I would do as Java does, but also add most common usages e.g. LogDebug, LogWarning, LogError, etc. I guess it also is worth to consider how many options the enum will represent. The answer to this question might not be the same for "small" enums and "large" enums. I like this question btw. Another question, is whether to use enums or classes as arguments, but ... that is another question ;)
-
In Java I use the log.Log(Level.type, message) and In C# I use the log.LogWarning(message) or another. I find it pretty annoying in Java. They clearly made this better choice - better choice in relation to design e.g extensibility and maintainability. However, I need to work more with the Editor when writing this (more choices and Level import). In this case I would do as Java does, but also add most common usages e.g. LogDebug, LogWarning, LogError, etc. I guess it also is worth to consider how many options the enum will represent. The answer to this question might not be the same for "small" enums and "large" enums. I like this question btw. Another question, is whether to use enums or classes as arguments, but ... that is another question ;)
Thanks for sharing your experience using both approaches in two different environments.
Keld Ølykke wrote:
I find it pretty annoying in Java. They clearly made this better choice...
These two statements seem to conflict with each other. If the one approach is "pretty annoying" is it really "better?" And this is reason I raise the question: I have the same conflict internally. Which approach is "better" seems to come down to where you approach the problem from. One day I look at the problem from one perspective and one way seems "better." The next day I look at the code and say "How crappy! This way is better!" What I optimize for changes the context enough to change the answer.
Keld Ølykke wrote:
Another question, is whether to use enums or classes as arguments, but ... that is another question ;)
Yes. Yes it is. :-D