Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Silas Reinagel
    @SilasReinagel
    It may a limitation of the Java language, but I'm not sure how to reconcile that fact that "safe" methods can throw unchecked exceptions. This feels like venturing into the realm of defensive programming, which Yegor seems very opposed to.
    For example, even in a perfect application, a user could pass in "null" as an argument, which would throw a Runtime NullPointerException.
    Doesn't that mean that in Java there are no safe methods, if they use non-primitives (Objects)?
    Andrew DiLosa
    @adilosa
    I think safe methods are still possible. NullPointerException should be avoided by writing code without null.Then many String methods should always work (length(), toLowerCase(), trim(), etc), most .equals() methods should work, and probably some more.
    Andrew DiLosa
    @adilosa

    That said, right in Java API we find absolutely unsafe methods masquerading as safe. Like ArrayList.add(Object), which declares no checked exceptions but documents IndexOutOfBoundsException. It may also throw NegativeSizeException, or NullPointerException. Or if used wrong, ArrayStoreException. This leads to a lot of unknowingly broken code and fails spectacularly in production. To say nothing of arrays/Strings, or dates and time, or Collections. What should be basic stuff!

    All these broken "safe" methods do make it hard to write good safe code. I think this can only be because they are badly designed. Half of this could be cleared right up with some "throws Exception". At least then the authors and users of this code would think harder about failure in their designs, and the computer would be able to help for the rest.

    Silas Reinagel
    @SilasReinagel
    Yeah. I think that makes sense. It's such a paradigm shift to conceptualize a pure OO language with pure OO code. Some elements of it are hard to do perfectly with our current languages and basic APIs.
    Glusk2
    @Glusk2
    I don't know how kindly programmers would react to:
    try {
        list.add(new Object());
    } catch(Exception e) {}
    Andrew DiLosa
    @adilosa
    @TheoConfidor I agree. Although it does seem more practical than I first thought. I think much of the problem is my own difficulty decomposing problems in an OO way :)
    Silas Reinagel
    @SilasReinagel
    @Glusk2 I think if generics were correctly implemented (no Type Erasure) then there shouldn't be any reason why adding a value to a list with mutable contents should ever throw an exception.
    Andrew DiLosa
    @adilosa
    @Glusk2 Yeah, probably not. That should have been a clue to the designers. Had they had to put throws Exceptioneverywhere then maybe they would have noticed. I would much rather list.add() be designed to be safe and never throw, than just not handle errors and pretend like they'll never happen.
    vivek poddar
    @vivekimsit
    @yegor256 any thoughts on my question? because I remember you tell that ifs are not good
    Silas Reinagel
    @SilasReinagel
    @yegor256 So, I'm trying to figure out a good way to provide access to some (typically static) URIs without using static. Is this a good way to encapsulate this data? http://pastebin.com/XVEqismC
    Andrew DiLosa
    @adilosa
    interface Uri {
        String uri();
    }
    
    class APIUri implements Uri {
        String uri() {
            return "/api/notification";
        }
    }
    
    class NotifyAPIEndpoint implements Uri {
        Uri uri; 
        public NotifyEndpoint(Uri uri) {
             this.uri = uri;
        }
    
        String uri() {
            return uri.uri() + "/notify";
        }
    }
    
    ...
    Silas Reinagel
    @SilasReinagel
    Interesting. Encapsulate every single value as an object.
    Does it feel awkward that you have to write 'uri.uri()' ?
    Andrew DiLosa
    @adilosa
    A little, but not so much if Uri is either named differently or a more complex object.
    I think in your pastebin, it is not so different from public static literals (private static literals + getter methods), for which there is an article: http://www.yegor256.com/2015/07/06/public-static-literals.html
    Silas Reinagel
    @SilasReinagel
    What is a better way to reconceptualize this interface? How can I treat this as a living object instead of a simple imperative servant?
    public interface INotifier
    {
        void send(final Notification notification);
    }
    Konstantin Gukov
    @gukoff
    @TheoConfidor well, a notification should be able to be sent on its own. Simply move the save method to Notification's interface.
    Andrew DiLosa
    @adilosa
    Yegor suggested a Source/Target naming for the Observer pattern. Perhaps that will work here.
    Silas Reinagel
    @SilasReinagel
    Hmmm. I like the idea of a Notification being able to send itself. That raises two further questions. 1) How do I handle dependency injection for the Notification object, since most notification users want a very simple API? 2) What should I name the simple data structure that gets sent across the wire using RPC (currently it is called Notification, and contains three fields)?
    Andrew DiLosa
    @adilosa
    1) Interfaces
    2) Notification seems fine to me. Probably RPCNotification that implements Notification interface
    @yegor256 Will the David West interview still be published today?
    Yegor Bugayenko
    @yegor256
    @adilosa hope so, almost done...
    Yegor Bugayenko
    @yegor256
    hey all, I'm trying to write a few words about inheritance and can't. I don't know whether it's a bad thing, an OK thing or a good thing... what do you think?
    I'm using it, but I find it in almost all places easy to replace with something else. some people say it's a bad thing. Allen Holub for example: http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html
    Allen says: "You should avoid implementation inheritance whenever possible". this is what bothers me - this "whatever possible" part. does it mean that sometimes we need inheritance?
    SJTsai
    @SJTsai
    I guess there's Liskov's that you can refer to. Don't know if that helps though
    Yegor Bugayenko
    @yegor256
    please, don't say that inheritance is usually bad, we all know that, there are tons of articles about it
    my question: can we just say that inheritance is a mistake in OOP? David West thinks so, by the way
    if it's not a mistake than what is the rule of using it? when it's acceptable and when it's a bad idea?
    Yegor Bugayenko
    @yegor256
    and I'm talking about "implementation inheritance": class Foo extends Bar
    Silas Reinagel
    @SilasReinagel
    A heuristic that I heard from several experience engineers is: One level of inheritance is acceptable, but never more.
    Yegor Bugayenko
    @yegor256
    @TheoConfidor that sounds like a rule, thanks
    Silas Reinagel
    @SilasReinagel
    Personally, I only use inheritance for abstract classes, at this point. Template Method Pattern is very useful.
    SJTsai
    @SJTsai
    Like you Yegor, I've found that anything done with inheritance can be done with composition
    So I'm not really sure
    It'd be nice to understand what Alan Kay is trying to say in the link though
    Yegor Bugayenko
    @yegor256
    David West said in the interview (to be published soon) that inheritance was invented in order to re-use functionality and it's a terrible mistake
    Foo extends Bar is a what doesn't exist in real world
    and I can't say I agree with that
    in real world a Dog definitely inherits many qualities from a Wolf
    and a Chair definitely inherits a lot from a Furniture Element
    JP
    @nqafield
    @yegor256 Do you see "qualities" as anything like "behaviour"? Could you say a dog does some of the same things as a wolf?
    Yegor Bugayenko
    @yegor256
    I guess..
    but David West says that the idea of a "class" is also wrong. it must not exist in OOP
    if we remove classes, we definitely won't have inheritance
    but then I don't know how everything will work :)
    JP
    @nqafield
    Are interfaces classes?