The fact that you cannot give your classes names better than
"...Utils" or "...Helper" is a strong indication that you have not
assigned responsibilities among your classes very well. Your classes
should represent kinds of *things* in the domain, the methods should
represent ways that those kinds of things interact in the domain.

--Nat

On 11/01/2008, Zheng <zhengzwang@(protected):
>   > Our experience is that breaking up complicated objects leads to more
>   > maintainable designs, the essential complexity won't go away but
>   > it'll be in pieces that are easier to see and change. That's why we
>   > develop the way we do and why jMock is the way it is. If you look at
>   > the underlying implementation of jMock itself, you'll find it
>   > consists of small, focussed objects plugged together.
>
>   There are not only complicated objects, but also complicated methods. You
> can have one 'simple' object with only one complicated method in it. In this
> case, you break up the complicated method, and no matter where you put the
> resulting methods, you may get one invocation chain that does not deserve
> multiple classes. Look at the resulting method invocation tree I anticipated:
>
>      createWebServiceEar     // this method is in class BizManager
>         constructModuleZip       // ***
>           zipUtils.unzipToDirectory
>           metadataUtils.createModuleFile
>           metadataUtils.createProjectFile
>           createExportAndImportFilesRecursively // ***
>              wsdlUtils.parseWSDLFileToGetPortInfo
>              filterPortInfo   // ***
>              metadataUtils.createExportFile
>              metadataUtils.createImportFile
>           zipUtils.createZipFileFromDirectory
>         deployUtils.generateDeployCodeOutOfModuleZip
>   All the 'leaf' methods are already on hand before I implement the
> createWebServiceEar method. But there is one invocation chain I mark using ***.
>   According to your logic, I will get another three classes A, B, and C.
> A.constructModuleZip invokes B.createExportAndImportFilesRecursively which again
> invokes C.filterPortInfo. These three classes exist simply because they must
> satisfy the createWebServiceEar method, yet none of them can be reused. Then how
> will you name these classes? BizManagerHelperA, BizManagerHelperB and
> BizManagerHelperC, or something else?
>   According to my logic, I will not get another class. All the methods in that
> chain reside in BizManager.
>   I do not think your logic will lead to more maintainable designs than mine.
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

  http://xircles.codehaus.org/manage_email