Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Yegor Bugayenko
    @yegor256
    just found this review of Elegant Objects, decided to share with you: http://www.renaudpradenc.com/?p=504
    Fabricio Cabral
    @fabriciofx
    @yegor256 "In its current state, it looks a lot like a manifesto: it strongly tells what the author is against, but not enough what can be done instead. I wished the author had better explained alternatives that he uses, like the Decorator design pattern, or how he passes dependencies around the application, for example when they are shared resources."
    @yegor256 what do you think about it?
    Yegor Bugayenko
    @yegor256
    @fabriciofx it's not the first time I hear that comment
    in the second volume I'm trying to give more examples/recommendations
    Fabricio Cabral
    @fabriciofx
    @yegor256 IMHO, your ideas are very good, but we (the people that read your blog/book) need more examples. Mainly because the ideas are against all we see around in books, sites or courses. The projects in your github account area good start, but an medium-size complex project is welcome to illustrate your ideas, specially the anti-ORM and anti-MVC ideas.
    Yegor Bugayenko
    @yegor256
    @fabriciofx yeah, I realize that, more examples would be helpful. working on them!
    Fabricio Cabral
    @fabriciofx
    @yegor256 very good to know it! Thanks! :smile:
    Silas Reinagel
    @SilasReinagel
    @yegor256 I read through your book this weekend. It's a very powerful paradigm. I have a couple of questions.
    Why the insistence on checked exceptions instead of exceptions? This differs from what Robert Martin teaches. It seems to make the code more verbose and unwieldy
    As long as the strategy is to wrap and rethrow, what is gained by having exceptions be checked?
    Yegor Bugayenko
    @yegor256
    @TheoConfidor you have to be more specific :) your question is too broad. start with this article: http://www.yegor256.com/2015/07/28/checked-vs-unchecked-exceptions.html
    Andrew DiLosa
    @adilosa
    @TheoConfidor Compiler enforcement. Checked exceptions force error cases to be considered and handled, or the compiler will complain. Also explicitness. It declares to other code/developers that this behavior may fail. Wouldn't want to hide that fact behind unchecked exceptions. And with Yegor's suggestion of only one Exception type, it is not so verbose.
    Silas Reinagel
    @SilasReinagel
    @adilosa, so the primary benefit is that it communicates that fact explicitly to other developers?
    Andrew DiLosa
    @adilosa
    @TheoConfidor Yeah, I think so. The computer will make developers aware of this however it can: API contracts, generated documentation, compile errors, test coverage, etc. Unchecked exceptions allows errors not caught by devs, docs, compilers, or tests, but may occur at runtime - sometimes. This class of errors is hard to debug and entirely preventable, so it seems like poor design not to do so.
    Silas Reinagel
    @SilasReinagel
    Thank you for your insight into that.
    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.