More from Santosh K.



  • Note quite worthy of the front page, but still:

      class DataUtil {
    public static void doStuff(int value) {
    System.out.println("DataUtil.Doing stuff: "+value);
    }
    }

    class DbUtil {
    public static void dbStuff(int value) {
    System.out.println("DbUtil.db stuff: "+value);
    }
    }

    private void handler(Method utilMethod, Method dbMethod) throws Exception {
    utilMethod.invoke(new DataUtil(),new Object[]{1});
    dbMethod.invoke( new DbUtil(), new Object[]{2});
    }

    public Handler() throws Exception {
    Class clzData = DataUtil.class;
    Method doStuff = clzData.getMethod("doStuff", new Class[]{int.class});
    Class clzDb = DbUtil.class;
    Method dbStuff = clzDb.getMethod( "dbStuff", new Class[]{int.class});
    handler(doStuff, dbStuff);
    }

    ...because just calling a static method on a class where it's needed is too easy.

    And no, there is no other context.


  • Discourse touched me in a no-no place

    @snoofle said:

    And no, there is no other context.

    None needed. The glow of incompetence shines through without it.



  • @snoofle said:

    ...because just calling a static method on a class where it's needed is too easy.

    Plus, this way round, you could write:

        handler(dbStuff, doStuff);

    Try getting that past a static compile-time type check!

     



  • Well, the reflection API can be used to great advantage to do stuff not otherwise possible. But at the same time it can also be used to obfuscate code to the point of unrecognizability. This is a perfect example of the latter.


  • Discourse touched me in a no-no place

    @snoofle said:

    Note quite worthy of the front page, but still:

      class DataUtil {
    public static void doStuff(int value) {
    System.out.println("DataUtil.Doing stuff: "+value);
    }
    }

    class DbUtil {
    public static void dbStuff(int value) {
    System.out.println("DbUtil.db stuff: "+value);
    }
    }

    private void handler(Method utilMethod, Method dbMethod) throws Exception {
    utilMethod.invoke(new DataUtil(),new Object[{1});
    dbMethod.invoke( new DbUtil(), new Object[{2});
    }

    public Handler() throws Exception {
    Class clzData = DataUtil.class;
    Method doStuff = clzData.getMethod("doStuff", new Class[{int.class});
    Class clzDb = DbUtil.class;
    Method dbStuff = clzDb.getMethod( "dbStuff", new Class[{int.class});
    handler(doStuff, dbStuff);
    }

    ...because just calling a static method on a class where it's needed is too easy.

    And no, there is no other context.

    Why is he creating new instances of classes he's about to invoke static methods on, in handler()?

    Also, what's this new xx[{...}) stuff?  Typo, or some feature I'm not aware of?


  • Considered Harmful

    @FrostCat said:

    Typo, or some feature I'm not aware of?

    A feature of Community Server you're not aware of.



  •  The closest thing I can think of that would make sense would be a stub... but it doesn't have a superclass. It also looks something like an abstract class written by someone who doesn't know what an abstract class is.



  • @FrostCat said:

    what's this new xx[{...}) stuff?  Typo, or some feature I'm not aware of?
    Typo (I have a broken thumb and the splint keeps getting in the way when I try to type....)

    In Java, the syntax: new SomeType{...}  intializes a list


  • Discourse touched me in a no-no place

    @snoofle said:

    @FrostCat said:

    what's this new xx[{...}) stuff?  Typo, or some feature I'm not aware of?
    Typo (I have a broken thumb and the splint keeps getting in the way when I try to type....)

    In Java, the syntax: new SomeType{...}  intializes a list

     Ah.



  • This Santosh guy is amazing. It's like he's been thrown into the deep end of Java and is forced to implement things in the most complex way possible.

    Yes, the fact that he actually constructs instances of the classes to pass into invoke() is even more hilarious. With static methods, I'm pretty sure you can pass in null. But I'm not absolutely sure because - guess what - I've never done anything so stupid.

    Next thing you know, he'll be constructing instances using class.newInstance().



  •  In our school it was taught that always use a static class unless not necessary to do so.

     



  •  Did they teach a reason why?

    Interesting to know the reasoning behind that lesson.


  • Discourse touched me in a no-no place

    @LoremIpsumDolorSitAmet said:

    Next thing you know, he'll be constructing instances using class.newInstance().
    Hah! Highly unlikely. There are far more complicated ways to do it.

    I'm waiting for the StringConstructionFactoryStrategyBuilder to encounter Santosh K. Architecture astronautics plus the power of low-level anti-clue? What's not to like?



  • @Nagesh said:

    In our school it was taught that always use a static class unless not necessary to do so.
     

    Is that some roundabout way of saying you should use regular instantiated classes unless it's necessary to use static classes? That doesn't make much sense.

    Pedantic dickweed time: the only static classes in Java are the ones that are declared as such because they're defined within another class, as opposed to nested classes. Classes containing only static methods are typically called 'helper classes' or 'utility classes'.

    Regarding the original quote, there's never any time when it's necessary to use static methods. They're just there for convenience.

     


Log in to reply