#method parameters

1 messages · Page 1 of 1 (latest)

small dewBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#

lf does not use any other properties or methods of ClassA, then it might be more appropriate to change the parameter type to List<String> instead. This way, the method will only depend on the list itself and not on the entire ClassA object.

Here's an updated version of the method using List<String> as the parameter type:

public void doSomething(List<String> list) {
  // Your logic here
}

By doing this, you make the method more flexible and reusable since it can now accept any list of strings, regardless of whether it comes from a ClassA object or any other source.

humble whale
#

It should only take the list imo

junior knoll
#

depends on the context though imo

#

but yea most of the times it should take the List only

idle kiln
#

that's what i do most of the time as well. would you pass an instance of a class if it's using more than one thing from the class?

#

ive been hearing about things called value objects and instead of using something like string for email they create an email class which wraps a string

junior knoll
#

yeah but that isnt related to the question though Thinkfused

#

but if you need to use more than one getter it makes sense to have the Class as an parameter, to reduce clutter etc

#

and its more user friendly imo

idle kiln
#

yeah not exactly related but if i have a method that takes in an email and i have an email class that wraps a string i would pass in public void useEmail(Email email) instead of public void useEmail(String email) even though my useEmail class only needs a string

junior knoll
#

Here you would use Email instead

#

Because a String can literally represent everything

#

And thus you create a class to represent an E-mail

idle kiln
#

my example is way to generic so whether i pass in an instance of a class or a List will depend on the context but my reasoning of considering passing ClassA is because List<String> could come from anywhere but i need specifically the List<String> from ClassA

amber field
#

but i need specifically the List<String> from ClassA

#

that shouldn't be the case

#

a method does something with input

#

it shouldn't care about where that input comes from

#

show the actual code instead of describing it if you want good help though
having no context makes this hard to answer properly

idle kiln
#

i don't have a code. i would always take in a List<String> btw. it was just a thought i had recently

amber field
#

right

#

well it depends entirely on the context

idle kiln
#

ive been hearing about value classes which made think about something like this. like the email example

amber field
#

it always helps to describe what a method does in a sentence

#

e.g. for the email example that would be set the email something uses, it would be reasonable for it to take an Email class, (although a String would also work I think)

#

for a method join a list of strings into one string for example it would not make sense to give it a ClassA parameter, that class is unrelated (even when you can get a list of strings from that instance)

#

That would just limit where/how you can use the method

#

But I don't think you'll come across this really? I'm sure if you think about what your methods are actually supposed to do, this 'issue' won't happen