Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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?
    Yegor Bugayenko
    @yegor256
    no, interfaces is a separate thing
    David said that classes were invented just to get rid of copy-paste problem
    but they should not exist in OOP, as concepts
    maybe that's why inheritance is a "bad" idea... I'm just thinking out loud
    SJTsai
    @SJTsai
    They're types, but you have to realize that an interface is simply a set of messages that can be sent
    Yegor Bugayenko
    @yegor256
    yeah, interfaces are types, I agree
    we can say that "Lucy" is a an object of type "Dog"
    type "Dog" requires everybody to be able to "walk()"
    "Lucy" walks this way: print "I am walking"
    so, there is no place for a class in this story so far
    we just say:
    Lucy = new {
      walk() { print "I am walking"; }
    }