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 - 16 through 30 (of 31 total)
  • Author
    Posts
  • #28787

    Max Guernsey
    Keymaster
    #28793

    Max Guernsey
    Keymaster

    For those that don’t quite get the joke –

    Snapping (fingers) and being triggered are concepts that belong to the ever beloved SJW/Feminism/BLM domain. Which is where Max’s comment about ‘I understand and validate (my) feelings’ comes from.

    Max and me are as thick skinned as an elephant wearing another elephant’s skin.

    If anyone feels the need for a Safe Place where communications can be conducted without Max and I poking each other with burning spears, please let Scott know.

    #28794

    Max Guernsey
    Keymaster

    You gave the following example:

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

    In your class diagram you have indicated a dependency between MessagePacker and the enumeration.
    There is no such dependency in your code, which makes your code

      not

    implement your design

    #28795

    Max Guernsey
    Keymaster

    You gave the following example:

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

    In your class diagram you have indicated a dependency between MessagePacker and the enumeration.
    There is no such dependency in your code, which makes your code

      not

    implement your design

    #28796

    Max Guernsey
    Keymaster

    You gave the following example:

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

    In your class diagram you have indicated a dependency between MessagePacker and the enumeration.
    There is no such dependency in your code, which makes your code NOT implement your design

    #28797

    Max Guernsey
    Keymaster

    You gave the following example:

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

    In your class diagram you have indicated a dependency between MessagePacker and the enumeration.
    There is no such dependency in your code, which makes your code NOT implement your design.

    #28798

    Max Guernsey
    Keymaster

    I’ll admit I didn’t get the snapping thing, actually. I imagine I’ll start to get more up to date with all the SJW terms in about five years, though hardly because I want to learn them.

    I second that, though.

    Don’t worry about Amir and I hurting each other’s feelings. It’s extremely improbable and our own problem, should in the unlikely event that it happened.

    #28799

    Max Guernsey
    Keymaster

    If you type that one more time while looking into a mirror, I’ll appear behind you when you turn off the lights.

    That said, look again, Grasshopper.

    #28800

    Max Guernsey
    Keymaster

    Max and me are as thick skinned as an elephant wearing another elephant’s skin.

    Man I wish I had the skills to create an elephant Buffalo Bill animation and set it to Goodbye, Horses, right now.

    You’ll all just have to imagine it. Go on, imagine it!

    #28801

    Max Guernsey
    Keymaster

    I will write these blogs when I will have the time and will to do so.
    You asked for comment on your blog.
    I feel the entire premise of the blog, whether the design sits in the code or not, is flawed.

    If you have an incomplete design in UML you cannot depend on that UML diagram.

    The point I am trying to make, and that you are painfully evading, is that just by looking at the (perhaps) incomplete design diagram, I can tell whether the diagram is complete or not. I do that by asking the simple questions I outlined above. I told you what the conclusion is given the two possible answers, and how I can tell whether the code would be horrible or not.

    Instead of trying this technique out, or ask me for clarification, you keep telling me what I am saying is irrelevant.

    So – to this end, I feel that I am wasting your time, Max. Please publish your posts at your pleasure.

    Peace out.

    #28802

    Max Guernsey
    Keymaster

    You may or may not have wasted your own time but you have not wasted mine. I think that version 3 (linked in a previous post) of this blog entry is a lot stronger as a result of this debate. You forced me to demonstrate the ambiguity not as a result of surprise but as a result of two alternative (and equally valid) interpretations of the same diagram.

    I actually didn’t say what you said was irrelevant. I said the answer wasn’t something you could detect from a diagram. Then I supplied you concrete evidence to support that claim: two bodies of code that both fit the diagram (as “completely” as possible in their respective cases).

    My point is that you can only have an incomplete design in UML. The incompleteness is what actually gives it its power – it allows us to pick and choose what matters in a particular context.

    Now, as a result of the debate, I’m rethinking the whole article – much as happened with another entry in a conversation with Scott before I opened conversation up to the wider audience.

    Maybe I don’t want to be Admiral Ackbar, here. Maybe I want to lead with “here’s a way that diagrams are really powerful” and end with “but there’s a trap into which you might fall.

    I’ll have to think about that over the weekend.

    #28803

    Max Guernsey
    Keymaster

    I am glad it was useful.

    The one big problem i see is that ypu think the short bit of code ypu put in this thread matches the design, when I proved it does not.

    #28804

    Max Guernsey
    Keymaster

    You have a tendency to think you’ve proved something when all you have done is said it.

    Your claim was that there wasn’t a dependency on the enumeration and that somehow invalidated the argument. If that were true, it still wouldn’t invalidate the argument, which is that diagrams (like all documentation) lie.

    However, the fact that it is not true – that there is dependency as depicted – makes me wonder why you think you “proved” it.

    #28805

    Max Guernsey
    Keymaster

    …hence my earlier reply:

    “…look again, Grasshopper.”

    #28806

    Max Guernsey
    Keymaster

    Because what the class diagram says and what the code says are not the same.

    The uml says there is a dependency on the enumeration. Your code does not have it.

    By this logic you can add anything to the uml and ignore it in the code. For example, i will add an encryptor strategy, a happy meal builder, a bridge, and sixteen visitors on a hierarchy rooted with an abstract message packer.

    And here is the code:

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

    Because if we ignore the uml, lets go all out.

Viewing 15 posts - 16 through 30 (of 31 total)

You must be logged in to reply to this topic.