utility-method

Closed . This question is opinion-based. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it can be answered with facts and citations by editing this post . Here's an example of a utility method: public static Long getFileSize(String fileString) { File file = new File(fileString); if (file == null || !file.isFile()) return null; return file.length(); } Is it a good practise to pass a String rather than a File to a method like this? In general what reasoning should be applied when making utility methods of this style? This is my preferred

I realise this question has been asked many times, but I am still unable to completely understand this concept. In my application, I am using a static utility class to keep common methods (like showing error dialogs) Here is how my static class looks like: public class GlobalMethods { //To show error messages public static final void showSimpleAlertDialog(final Activity activity, String message, final boolean shouldFinishActivity) { if (!activity.isFinishing()) { AlertDialog.Builder builder = new AlertDialog.Builder(activity, AlertDialog.THEME_HOLO_DARK); builder.setCancelable(true).setMessage

I got a list of files and directories List<string> pathes . Now I'd like to calculate the deepest common branch every path is sharing with each other. We can assume that they all share a common path, but this is unknown in the beginning. Let's say I have the following three entries: C:/Hello/World/This/Is/An/Example/Bla.cs C:/Hello/World/This/Is/Not/An/Example/ C:/Hello/Earth/Bla/Bla/Bla This should get the result: C:/Hello/ as Earth is breaking this "chain" of subdirectories. Second example: C:/Hello/World/This/Is/An/Example/Bla.cs C:/Hello/World/This/Is/Not/An/Example/ -> C:/Hello/World/This

This question already has an answer here: Java 8: Interface with static methods instead of static util class 4 answers For the past decade or so, I've been using the pattern below for my Java utility classes. The class contains only static methods and fields, is declared final so it can't be extended, and has a private constructor so it can't be instantiated. public final class SomeUtilityClass { public static final String SOME_CONSTANT = "Some constant"; private SomeUtilityClass() {} public static Object someUtilityMethod(Object someParameter) { /* ... */ return null; } } Now, with the

I wrote this method to apply a void function to a value and return the value. public inline fun <T> T.apply(f: (T) -> Unit): T { f(this) return this } This is useful in reducing something like this: return values.map { var other = it.toOther() doStuff(other) return other } To something like this: return values.map { it.toOther().apply({ doStuff(it) }) } Is there a language feature or method like this already build in to Kotlin? I ran into the same problem. My solution is basicly the same as yours with a small refinement: inline fun <T> T.apply(f: T.() -> Any): T { this.f() return this } Note,

This question already has an answer here: Java: Static Class? 7 answers I want to create a class with utility methods, for example public class Util { public static void f (int i) {...} public static int g (int i, int j) {...} } Which is the best method to create an utility class? Should I use a private constructor? Should I make the utility class for abstract class? Should I do nothing? initramfs For a completely stateless utility class in Java, I suggest the class be declared public and final , and have a private constructor to prevent instantiation. The final keyword prevents sub-classing

I generally live by the rule that Global variables / functions are evil and that every piece of code should live in the class to which it pertains. This is a very easy rule to follow, and I believe that I haven't ever run into an issue with this rule until now. Today, however, I need to add a function to my assembly rather than to a specific class. That is, almost all of my classes could have a use for this particular function. Where should I put this function (+1 overload)? If I put it in a "Utilities" class, I feel dirty. If I tack it on to a semi-related class, and let other classes call it