The Myth ...O Is For Object (Part 2)

/**
     * The result of a myth
     */
    public class UrbanLegend
    {
        public String string;
        
        private String one;
        private String another;
        private Calendar date;
        private boolean status;

        public UrbanLegend(String one, String another, Calendar date, boolean status)
        {
            DateFormat dateFormat = new SimpleDateFormat("ddMMyyyy");
            StringBuilder builder = new StringBuilder();
            
            if(status)
            {
                builder.append(one);
                builder.append(another);
            }
            else
            {
                builder.append(another);
                builder.append(one);
            }
        
            builder.append(dateFormat.format(date.getTime()));
            String string = builder.toString();
            
            this.one = one;
            this.another = another;
            this.date = date;
            this.status = status;
            this.string = string;
        }

        public int tell(int type, String string) throws Exception
        {
            DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");

            String oneName = null;
            String anotherName = null;
            
            if(one == "EDI"){
                oneName = "edinburgh";
            }
            else if(one =="LON"){
                oneName = "london";
            }
            
            if(another == "EDI"){
                anotherName = "edinburgh";
            }
            else if(another =="LON"){
                anotherName = "london";
            }        

            String from = null;
            String to = null;
            
            if(status)
            {
                from = oneName;
                to = anotherName;
            }
            else
            {
                from = anotherName;
                to = oneName;            
            }
            
            switch (type)
            {
            case 0:                    
                System.out.println("Walking down to " + to + " from " + from);
                return 0;
            case 1:
                System.out.println("Flying down to " + to + " from " + from + " in " + string + " class on " + dateFormat.format(date.getTime()));
                
                if(string == "economy")
                {
                    return 200;
                }
                else if(string == "business")
                {
                    return 500;
                }
            default:
                throw new Exception("Invalid type " + type);
            }        
        }
    }

    /**
     * You have to live with it
     */
    public class UrbanLegendTest
    {
        private static final DateFormat dateFormat = new SimpleDateFormat("ddMMyyyy");  
        private static final Calendar now = Calendar.getInstance(); 
        private static final String STRING = 
            String.format("%s%s%s", 
                    Destination.EDINBURGH.code(), 
                    Destination.LONDON.code(),
                    dateFormat.format(now.getTime()));

        @Test
        public void tell() throws Exception
        {
            boolean status = true; //making a choice!
            String string = "business"; //making a choice!
            int type = 1; //making a choice!
            String one = "EDI";
            String another = "LON";
            Calendar date = Calendar.getInstance();

            UrbanLegend myth = new UrbanLegend(one, another, date, status);
            
            Assert.assertEquals(STRING, myth.string);
            Assert.assertEquals(500, myth.tell(type, string));
        }
    }

Though the code is fictional its characteristics unfortunately aren’t. You’ve most likely encountered code like this before plenty of times. In your code base, over at github in startups and large corporations. It has no boundaries. You most likely wrote something like this yourself in the past. Why do you keep writing it?

You struggle as you make an effort to understand it. Align with it as you go back and forth. Trying to digest it all at once. Don’t blame you. This code is hard to follow. The fact that you don’t know the problem is trying to solve doesn’t make it any easier. Can you even tell what the business domain is?

How much time did it take you to write it? Go back and read it again. Can you tell now? Again. How much time did it take you to understand it? Now go away and come back tomorrow. Read it again. Do you still remember what it does? How much time in total do you think it takes everyone reading that code to understand it? How much time will it take you to extend it? To maintain it? To test it. Can you test it? It will only get messy. You want to throw it away. How much time will it take you to write it again? How much time have you wasted?

Ask yourself. What’s wrong with it? It must be something really great this code is doing. Why else would it look that horrible?

Code doesn’t have to look like that.

This isn’t about not knowing what problem is trying to solve. Nor how complicated it might be.

What does

    int type = 1;

even mean? How is this related (if so) to

    String string = "business";

All you can tell is that 1 leads to

    case 1:
        System.out.println("Flying down to " + to + " from " + from + " in " + string + " class on " + dateFormat.format(date.getTime()));

You have to follow all that code down to switch just to find out what it means. Looking back, you knew right there when you made the choice, you don’t need that switch! But there is only that much you can do with an int in an OO world.

Like that string. With a no clear cut relationship between that and the type. Will changing one break the other? Is it relevant? How do you enforce their relationship?

What about all that unrelated code that you have to move out of the way to get a clear picture of what this is all about?

Writing code isn’t subjective. It’s about software design.

Source

Software Engineer

The Myth ...O Is For Object (Part 2)