Don’t Be Fooled by Boxes and Lines (MG)

This topic contains 30 replies, has 4 voices, and was last updated by  Max Guernsey 2 years, 12 months ago.

Viewing 15 posts - 1 through 15 (of 31 total)
  • Author
    Posts
  • #28750

    Max Guernsey
    Keymaster
    #28751

    Max Guernsey
    Keymaster

    I do not like this blog, as is.
    The entire premise is that simple UMLs can lead to complex code.

    1. The design does not live in the code, it lives in the problem domain. In fact, it models the problem domain.
    2. The fact that the code is horrible is IMMEDIATELY discernible from the design, i don’t need to look a the code.
    the MessagePacker class is breaking the SRP and there is expected to look exactly how you wrote it.

    Max, in class I teach my students to ask the following questions:
    – What do you need to know? (in order to implement X)
    or
    – who do you need to consult (in order to implement X)

    If the answer has more than one element to it, you have broken SRP and need to decouple your design.

    Therefore – to answer you question:

    Does that look complex?
    The Consultant’s Answer (Yes)
    
    End of Blog

    Perhaps turning this blog into a – see-how-design-principles-predict-crappy-code blog is better?

    #28758

    Max Guernsey
    Keymaster

    I absolutely LOVE the fact that you felt the need to replace “hate” with “do not like”. Remember with whom you are conversing.

    I’ll reply with the same amount of vitriol but I’ll dilute it into a longer post.

    Amir’s #1:

    The design does not live in the code, it lives in the problem domain. In fact, it models the problem domain.

    As a fundamental truth, I don’t buy this. As a teaching or analytical tool, I think that way of thinking is really useful. Ultimately, it’s just one way of getting working, sustainable software out the door.

    The design of a product ultimately lives in the code. That you choose to have your designs line up with your model of the problem domain doesn’t change that fact. It just creates an alignment you find to be convenient and useful.

    I’d welcome some stronger arguments that demonstrate the truth of this assertion, though.

    Amir’s #2:

    The fact that the code is horrible is IMMEDIATELY discernible from the design, i don’t need to look a the code.
    the MessagePacker class is breaking the SRP and there is expected to look exactly how you wrote it.

    I’d bet everyone on this thread could tell that but not for the reasons you…believe?

    You all know me too well to think that in an article with this title, I’d be using that diagram to sell the fidelity of UML.

    Did you get that I was writing this to persuade yourself of something I thought you didn’t already know?

    If the answer has more than one element to it, you have broken SRP and need to decouple your design.

    I thought you weren’t my target audience until I read that…but maybe you are, Amir. You made an assumption – the exact assumption that this blog suggests you should avoid – that you are seeing a complete representation of the design.

    Maybe that’s just the mediator that hides all the bits and pieces with only the one responsibility of coordinating their activities. Maybe the interface is built in anticipation of variations that were discovered in ATDD but that just does a simple thing at the moment because that’s all you need.

    Neither of those are nearly so bad as the design of the code that was shown, Amir.

    I’m not sure if you envisioned the design as complete based on the UML or if your (thankfully, non-Biblical) knowledge of me gave you foresight into where I was going. The former is exactly the mistake I would want the reader to stop making. The latter puts you in an extremely limited subset of readers who can both foresee what I’m going to say and also have a misguided ideas about where design lives. 😉

    So right now, I’m not compelled by this argument but I welcome some stronger arguments, if you have them.

    In General

    If your goal is to convince me I shouldn’t post this, you are 0.0000001% of the way there. If your goal was to persuade me toward the assertions you made, you’re 0% of the way, there.

    I do respond to constructive criticism if you have any.

    #28759

    Max Guernsey
    Keymaster

    I missed your last point. It’s a good idea to write a blog like that. I don’t think that’s what this is or that they are strongly related.

    The context, here, is that I often show people two opposing diagrams for Paint. In about half my classes, maybe one out of thirty people, there is the objection that the well-factored design is simpler because it has fewer lines and boxes. That’s the guy I’m trying to persuade, not you.

    The first version of this blog entry had two competing diagrams, one factored in a sane way and one as you saw in this article. Then I asked which was more complex.

    As an aside: the code you see is the result of me taking the good design and inlining everything.

    For the reader who thinks the “cram it in” design” is simpler, I want them to reconsider their position. For the reader who said “it depends” (the correct answer) or “probably the one with more classes” (a statistically safe but not necessarily correct answer), I want to give them some tools they can use to persuade others.

    #28761

    Max Guernsey
    Keymaster

    I use UML diagrams as big pictures, not details. I suggest that teams keep high level diagrams visible on their board to show the architecture. Except for introducing UML in the OOA&D class, I don’t recommend putting that level of detail into a UML diagram.

    #28763

    Max Guernsey
    Keymaster

    I’m not sure how to convert that post into action, Ken.

    #28769

    Max Guernsey
    Keymaster

    I have read your reply Max, and I have absolutely no idea what your point is.

    That an incomplete design is not enough to show the complete design?

    I have given you my STRONGEST argument already.

    The fact that the code is horrible is IMMEDIATELY discernible from the design, i don’t need to look a the code.
    the MessagePacker class is breaking the SRP and there is expected to look exactly how you wrote it.

    The design, AS IT IS STATED in your diagram, demonstrates the breaking of SRP.
    As a result, your code would be littered with format specific code, with a switch statement (or ifs) implementing the different packers.

    If you have additional information about additional relationships between classes and you want to share them, go ahead.
    If not, then I have read your design EXACTLY as you have written it.

    Also, I have no idea what you meant by “I’d bet everyone on this thread could tell that but not for the reasons you…believe?”

    And why do you think that by the title I will think that you’re selling anything about the fidelity of UML, your title states explicitly the opposite.

    And now for the last time, EVER, I will explain why the design does not live in the code.

    The code is the implementation of the design.
    You can take the same design and implement it in multiple languages, and even with the same language, you can have multiple implementations of the same design.
    On the other hand, if your design does not mirror the problem domain, you will have issues when the problem domain evolves.
    In many cases the design choices are not really important, especially if you adopt Ken’s style of hiding primitives or if you use var/auto religiously. But even these design choices reflect your knowledge or assumptions of the problem domain. Every. Single. One.
    And remember that maintainability is a requirements from within the problem domain.

    If you were to give me an example (e.g., two class diagrams that ‘solve’ the same problem, I am willing to interpret them in domain terms.

    But, for starters, here’s a low level example:

    int count;
    short count;

    #28770

    Max Guernsey
    Keymaster

    Maybe that’s just the mediator that hides all the bits and pieces with only the one responsibility of coordinating their activities. Maybe the interface is built in anticipation of variations that were discovered in ATDD but that just does a simple thing at the moment because that’s all you need.

    What’s amazing about interacting with you, Max, is that you’re unable to answer a simple question:

    – What do you need to know? (in order to implement X)
    or
    – who do you need to consult (in order to implement X)

    If the answer is ‘1’, then I will immediately ask you – where is the rest of the design, who’s responsible for the different formats.
    If the asnwer is ‘>1’ then !SRP

    in both cases –
    </Blog>

    so, if we’re going to continue in this intercourse, please try to understand what i’m saying, and respond to the points i am actually making.

    #28776

    Max Guernsey
    Keymaster

    Amir, I’m hearing that you think I didn’t reply to the points you made. I understand and validate your feelings but not your assertion because the assertion itself is not valid.

    The idea that you could tell the code was horrible from the UML is a fiction. At best, it demonstrates a lack of imagination. The answer to your questions can be either ‘1’ or ‘>1’ for that exact UML diagram depending on the code that diagram pretends to depict.

    #28779

    Max Guernsey
    Keymaster

    No, it depends on your design. The fact that you decided to NOT depict it with lines and boxes is your choice.

    But when i ask the question I posed above, I quickly get to the essence of the matter – did you create one humongous class with multiple responsibilities or did you break these responsibilities into several classes.

    You are refusing to answer this question, which is at the crux of the matter.

    #28780

    Max Guernsey
    Keymaster

    And don’t play SJW with me, as i will start snapping. You’re triggering me already.

    #28781

    Al Test
    Participant

    Max and Amir,

    As much fun as the forum is, it seems what we have here is a failure to communicate. Would a phone or Skype call help?

    Jay

    #28782

    Max Guernsey
    Keymaster

    Not traditionally, Jay.

    Amir, I’m not worried about whether you start snapping or you are being triggered. Those are your choices. I’m just cycling through methods that have helped me connect with people in the past.

    I’m also not worried about whether or not you think I’m focusing on the crux of the matter. You’ve done nothing to move the crux from where it is: do diagrams always accurately reflect complexity?

    Consider the following code:

    public class MessagePacker
    {
      public string Package(Message message, MessageFormat format)
      {
        return format + "|" + message.Id;
      }
    }

    It has the exact same depiction in UML but it is not nearly as complex. Your belief that you could tell the code was bad (when I didn’t ask if it was bad, just complex) is totally unsubstantiated.

    Maybe what I need to do, is to add a section with the above code so I can show alternatives.

    I could also add the other diagram back in and show how it could accurately reflect the right design or it could be way more complexity than the problem actually requires.

    #28783

    Max Guernsey
    Keymaster

    Amir,

    Incidentally, the exact same point could be made by comparing the the lines and boxes with the problem rather than with the code. Another blog entry could demonstrate that.

    There’s a different point to be made by comparing the code with the problem. It’s a point we’ve made dozens, if not hundreds, of times but it might make sense for this to become a trinity of blog entries:
    – UML lies about the scope of code
    – UML lies about the scope of problems
    – The scope of code and the scope of problems should strongly overlap

    I know you feel that code should reflect design and design should be a model of the problem. You can write all the blogs on that topic you like. l(

    #28784

    Max Guernsey
    Keymaster

    Jay, it hasn’t traditionally helped. Face to face communication has sometimes gone better.

Viewing 15 posts - 1 through 15 (of 31 total)

You must be logged in to reply to this topic.