Refactor The Concept

Try to refactor the concept and not only the code. Refactoring to remove duplicate code leads to OnceAndOnlyOnce. But if not done properly, it might lead to more complex code. So when you refactor, step back and look at the concept. May be the concept also has to be refactored to make the system more simple to understand. I have found refactoring or changing the concept make the system much more simpler and flexible.
Sound advice

On very rapid (say 1-8 weeks) on-site web development projects, this approach is invaluable: write a spec, code the system, and as you go along, ascertain which aspects of the spec are either too much effort for too little results, or which can't be done in the time schedule, and also factor in anything the client "just thought of". At the end, refactor the original specification into a RetrospectiveRequirement? and as long as the client's happy with the product, job done. Doing it this way not only makes for solid code, but also gets rid of any fluff that was originally thought of as a WouldBeNice?, but as it turns out, isn't necessary. Of course, this is just my ad hoc way of implementing DoTheSimplestThingThatCouldPossiblyWork. -- DarrenIrvine


Could we get an example of code that needs its concepts refactored?


Suppose we have a requirement to validate the parameters passed to a controller class. Then we have the interface

    public interface InputValidator() {
        public boolean validate();
    }

public interface Controller() { public void setInputValidator(InputValidator validator); public void executeReq(); // It will call validator.validate() before processing the request. }

And the code that calls is
    public class MyServlet extends HttpServlet {
        public void doGet(HttpServletRequest req, HttpServletResponse res) {
            ...
            Controller usrContrl = new UserController();
            usrContrl.setInputValidator(new UserInputValidator(req));
            usrContrl.executeReq();
        }
    }

Now, a functionality is required by the client so that they can execute their own code with this Web Application. We can implement it as Executor. The controllers take a list of executors and execute them one by one. The list is configurable.

    public interface Executor {
        public boolean execute();
    }

public interface Controller() { public void setInputValidator(InputValidator validator); public void setExecutors(Executors[] execs); public void executeReq(); // Now it will call both validator and executors before processing the request. }

public class MyServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) { ... Controller usrContrl = new UserController(); usrContrl.setInputValidator(new UserInputValidator(req)); // No need for this. Use Executor instead. Executor[] execs = config.getExecs("UserController"); usrContrl.executeReq(); } }
Here we can simplify the concept by removing Validator concept and implementing that code as an Executor. So instead of 2 concepts, we have only one concept. -- VhIndukumar


CategoryRefactoring

EditText of this page (last edited March 20, 2006) or FindPage with title or text search