People and technology
RSS Feed

Articles

  • What I do for DSP17

    I’ve joined DSP17 almost a month ago.

    Read More »

  • HTTPS for GitHub pages

    So I’m still getting used to DSP. First push has been made, I’ve discovered my dev muscles rusted. Well, that’s why I’m doing that in a first place, but in between I’m finishing setup of the blog :) Thanks to Michał (yet again :) Thank you!), this blog setup is being polished. This time let’s look at HTTPS.

    Read More »

  • Hello DSP

    Hello Daj się poznać! (DSP) So I’m joining the Daj się poznać initiative. What it is, you may ask, especially if you don’t have the super power of speaking Polish What is yours

    Read More »

  • It's alive

    Hi from the other side :) Some of you were here two years ago, when I was writing, some of you are new to this blog. Well, if you’re new, it does not matter, everything changed, Panta Rhei.

    Important thing for me, I’m going to write, again.

    You may wonder about several things, I’ll try to answer about two:

    1. What (I’m going to write about)
    2. Why (I’m writing again)

    So let me start with why question as it’s easier :) Well, knowledge sharing is cool! I talked about it for the whole year at various places (JDD, Devoxx, Boiling Frogs…). I want to share, and mentioned that each talk for 2 years. What I needed thou was someone/something to push me, and I had two of those. First was Ted Neward second one Bartosz Mazurek.

    During Devoxx Ted had discussion about his session (more about it in next post) which moved me enough to commit (yeah, I’m corp all over :/) to blogging again

    With Bartosz it is less obvious about motivator. He’s writing a lot and I’m reviewing some of the drafts, which is making me feel guilty of not writing on my own :)

    Now about What part?

    In last two years my focused changed a lot. I’m still going to dev conferences, I still do JUG, but on daily basis I work with people, not with code.

    Expect more of following topics:

    • Leadership
    • Team building
    • Soft skills
    • Agile ( :O )

    but there will be something about code as well, mostly craftsmanship topics as my mission is to promote good best practices ;)

    We’re also going to dive into basics also, as it took me ten years to understand OO, SOLID, TDD and others with their principles.

    So see you all soon! :)

    Read More »

  • Horror of impl classes

    If you've checked me on Twitter, you may have noticed My Twitter profilemy profile (screenshoot on right) and tag (?) line "Problem solver and father of many impl classes (not to proud about it).

    That (not to proud about it) part is the reason why I'm writing this blog post. I've received a very long question regarding that part: "Why?". In follow up discussion I've agreed to share why I hate xxxImpl classes so much, even thou I've had written so many of 'em in my life.

    Impl ==> no idea of what I'm doing

    Let's start first from that Impl suffix implies that we have properly named interface (at least something ;)). Going to basics, what an interface is? By wiki definition

    Interface: In object-oriented programming, a protocol or interface is a common means for unrelated objects to communicate with each other.

    In my own words, it's a contract between client and class that's realizing the interface, it's also a one foundation of OO which allows us to do a polymorphism and realize encapsulation. We can leave encapsulation and go straight to polymorphism, which is why we do Java, OO and everything else ;)

    Interface is just a contract, way in which it's going to be realized is totally dependant on implementation and there may be more than one (and even should!). Having just one implementation is not necessary wrong, and may have sense, however the biggest fail of 'em all is if that one implementation is called sthImpl. Why? Because it does not tell us anything at all (!) about how contract is being realized. In order to check it, we need to dive into code and figure it out.

    We could do so much better! Let's take for example my project, and something I've been doing a week ago (while waiting for plane on lovely Munich airport).

    We're extracting part of system functionality into a set of new projects which will be deployed on many servers. We needed a configuration module, however we could not decide about how we should realize that in distributed environment.

    For first implementation I've decided to go with property files, tied close to implementation (please don't judge, has nothing to do with this post). So step one was to create a contract

    public interface Configuration {
        public Optional<String> get(String key);
    }

    and follow it with first implementation

    public class LocalPropertyFileConfiguration implements Configuration {
    
         //Constructor
    
         public Optional<String> get(String key){/*reading in .properties file*/};
    
    }

    We already consider to use ZooKeeper or some other 3rd party service for config, and it will be as simple as adding additional class (ZookeeperConfiguration ?:)) implementing our configuration interface. We may leave first implementation so it can be used in tests or just discard it, does not matter. What matters is that it has proper name.

    True, but what comes with proper name is fact that if I ever decide to add more functionality or modify existing one, the name of the class itself will tell me if the change I want to introduce really fits the class. And if I need to expand responsibilities, then it's super easy to rename the class. Additional bonus: if new name is too cumbersome to say, maybe it's a good time to split it into couple classes?

    So in this example if I'd see anything related to networking inside LocalPropertyFileConfiguration class, then I would start looking what the heck is happening right away, even if I'd see the class for first time. Impl does not give you that benefit.

     

    There is also additional code smell coming from the fact we're missing proper name: no one knows what is exactly the responsibility of the implementation. From vague names often comes God Classes to life. If anyone seen any xxxDaoImpl or xxxManagerImpl then you know what I'm taking about. That is also somewhat related to bad name of interface and not clear enough contract, however Impl classes tend to make things worse.

    Also please think about Strategy pattern. It's really simple to just avoid creating new classes and instead add conditional statements inside one and only Impl. Proper name encourages you to write more classes instead of expanding existing one.

    Takeaway

    Please always consider what your class is doing, and name it after something specific to the class, even if it's as stupid as UserJpaDao instead of UserDaoImpl. More importantly, please consider if you need interface at all, if there is going to be just that impl class. Extracting interfaces using IDE is really simple! It's around 6 keystrokes away at any point of time!

    Also don't sweat too much over names. I've come up with names in this post while writing that (c's I don't remember what are actual names in code), and IMHO it's good enough. Remember, improving naming later on is usually super easy :)

    So have a nice day and make life better for everyone from Monday with not putting impls in your code.

    Read More »

Michal Gruca
Michal Gruca

Manager by title, developer at heart

Twitter Email

TOC