Refining Uncle Bob’s Clean Code（二）

最新推荐文章于 2011-10-27 10:50:20 发布

LGY2001

最新推荐文章于 2011-10-27 10:50:20 发布

阅读量1.2k

点赞数

分类专栏：编程技巧文章标签： schema parsing constructor string interface delegates

编程技巧专栏收录该内容

11 篇文章 0 订阅

订阅专栏

Looking back at the Args example, i would see class Args as the root of its ‘application’, thus responsible for bringing the different parts into life and statisfying their needs. Under this view, Args is nothing more than a facade which delegates the different tasks to their collaborators:

 
import static java.util.Arrays.asList;
 
 
 
public class Args {
 
    ...
 
 
 
    private Marshalers argumentMarshalers = null;
 
 
 
    public Args( String schema, String[] args) throws ArgsException {
 
        argumentMarshalers = Marshallers.Factory.getMarshalersFor( schema );
 
        ArgumentPopulator.distribute( asList(args) ).to( argumentMarshalers );
 
      }
 
 
 
     ...
 
 
 
}

As you can see, the result of the schema parsing (that is the found ArgumentMarshalers by Marshallers.Factory, each responsible for every single found argumentId) acts as input for the parsing / population of the arguments. Therefore, this second action only needs to know about the current arguments and the responsible Marshalers which will receive the related argument values they have to convert.

Boundaries

As you may have seen in the above piece of code, we no longer rely on a Map when handling ArgumentMarshalers. Like said in Chapter 8 ‘Boundaries‘, Provider of third party packages ‘strive for broad applicability. Users on the other side are looking for an interface that’s focussed on their particular needs‘.

Further on, Ron Jeffries mentioned in Chapter 1, that most programs include handling collections (the marshalers in our case). He also suggested to come up with an own collection type for specific items, so that you’re able to provide a ‘domain specific’ interface, related to the specific needs of usage.
That said, we could encapsulate the Set of responsible Marshalers in an own collection (say Marshalers), only providing domain specific Methods (like isMarshallerAvailabeFor( String argumentId )), but prohibit the possibility to clear the collection for example:

 
import java.util.ArrayList;
 
import java.util.HashMap;
 
import java.util.List;
 
import java.util.Map;
 
 
 
public class Marshalers {
 
 
 
    private Map<String,ArgumentMarshaler> argumentIdMarshalers = null;
 
 
 
    private Marshalers( List<ArgumentMarshaler> marshalers ){
 
 
 
        this.argumentIdMarshalers = new HashMap<String, ArgumentMarshaler>();
 
 
 
        for( ArgumentMarshaler marshaler : marshalers ){
 
            argumentIdMarshalers.put( marshaler.getArgumentId(), marshaler );
 
        }
 
    }
 
 
 
    public boolean isMarshalerAvailabeFor( String argumentId ){
 
        return argumentIdMarshalers.containsKey( argumentId );
 
    }
 
 
 
    public ArgumentMarshaler getMarshalerFor( String argumentId ) throws ArgsException{
 
        return argumentIdMarshalers.get( argumentId );
 
    }
 
 
 
    public int size(){
 
        return argumentIdMarshalers.size();
 
    }
 
}

As you can see, java.util.Map is now nothing more than an implementation detail, not showing up at the interface of the Marshalerscollection.

Power to the ArgumentMarshaler

One thing that surprised me most, is the if/else if/else chain within method parseSchemaElement() in order to select an appropriate ArgumentMarshaler for a given argumentId (schema element).
Again, i wonder if Args should be responsible to bound a specific argumentId to a specific ArgumentMarshaler, or if this shouldn’t be in the responsibility of the single Marshaler.

I would rather like to have the possibility of asking a Marshaler, if he’s able to handle a given schema element, so that the Marshaler can decide of its own if he wants to accept a given schema element. This would mean, that we could get rid of the if/else if/else chain by only iterating the registered Marshalers until there’s a Marshaler found that feels responsible for the given element (replacing conditional with polymorphism).
Furthermore, parsing and separating the single schema elements (knowledge about the schema notation) and the ‘selection’ of an appropriate Marshaler is cleanly separated.

Since we already moved the accordant logic to Marshalers.Factory, let’s take a closer look at the new mechanism on how to identify an appropriate ArgumentMarshaler for a given schema element:

 
public class Marshalers {
 
 
 
    ...   
 
 
 
    public static class Factory{
 
 
 
        private static final List<ArgumentMarshaler> registeredMarshalers =
 
                new ArrayList<ArgumentMarshaler>();
 
 
 
        public static void register( ArgumentMarshaler marshaler ){
 
            registeredMarshalers.add( marshaler );
 
        }
 
 
 
        public static Marshalers getMarshalersFor( String schema ) throws ArgsException{
 
            List<ArgumentMarshaler> marshalers = new ArrayList<ArgumentMarshaler>();
 
 
 
            for( String element : schema.split( "," ) ) {
 
                  if( element.length() > 0 ) {
 
                      marshalers.add( marshalerFor( element.trim() ) );
 
                  }
 
            }
 
            return new Marshalers( marshalers );
 
        }
 
 
 
        private static ArgumentMarshaler marshalerFor( String element ) throws ArgsException {
 
 
 
            for( ArgumentMarshaler marshaler : registeredMarshalers ){           
 
 
 
                if( marshaler.canHandle( element ) ){
 
                    return marshaler.newInstanceFor( element );
 
                }
 
            }
 
            throw new ArgsException( ArgsException.ErrorCode.INVALID_FORMAT, element, element );
 
        }
 
    }
 
}

As you might see, we shifted some of the responsibility to ArgumentMarshaler. Now each Marshaler knows for himself, if he wants to handle a specific schema element. You might say, that the argument type postfix (like ‘*’ or ‘#’) now is hidden inside of each single Marshaler, but that’s only a question of configuration. As you will see, it would be easy to come up with a slide variation, where the argument type postfix could be passed as a constructor argument to each single marshaler implementation (that kind of configuration would fall in the responsibility of class Args, since it is responsible for the Setup like mentioned before).

Another point worth to mention: Factory is an inner class within Marshalers, so that it’s able to access the private constructor ofMarshalers for returning a new instance. Since the constructor is private, the only way to receive an instance of Marshalers is viaMarshalers.Factory.getMarshalersFor( String schema ).