FW: bad smell in code ---lazy class

each class you create costs money to maintain and understand. Lazy class refer to the classes that does not  doing much.  the general rule is “a class that is not doing enough to pay for itself should be eliminated. one of the measurements on the laziness of a class is to see how many public members it has.

often this might be a class that used to pay its way but has been downsized along the way. Or it might be a class that was added because of changes that were planned but did not happen. either way, you let the class die with dignity. if you have  subclasses that aren’t doing enough, try to collapse them back to their base class. nearly useless class should be subject to inline class.

 

Extend that thought to component level, if a component is not doing much, we call it a lazy component  one of the measurements on the laziness of a component is to see how many class are them in a component .

 

let’s take a look at our code base on this aspect.  based on the code metrics captured on September 11^th 2013.  the following is my findings:

 

<![if !supportLists]>1.      <![endif]>among 120 projects ( components) :

<![if !supportLists]>a.      <![endif]>8 empty projects

<![if !supportLists]>b.      <![endif]>24 projects with only one types ( class or interface)

<![if !supportLists]>c.       <![endif]>11 projects with only two types ( class or interface)

<![if !supportLists]>d.      <![endif]>8 projects with only three types ( class or interface)

<![if !supportLists]>e.      <![endif]>5 projects with only four types ( class or interface)

<![if !supportLists]>f.        <![endif]>in total there are 56 projects with less than 5 members,  which makes up 28% of all projects in our code base. by any measuring, these are considered as lazy components and should be eliminated or merged.

<![if !supportLists]>2.      <![endif]>among about 4,700 Types ( class or interface)

<![if !supportLists]>a.      <![endif]>267 types  only have one member

<![if !supportLists]>b.      <![endif]>435 types  only have two members

<![if !supportLists]>c.       <![endif]>345 types  only have three members

<![if !supportLists]>d.      <![endif]>583 types only have 4 members

<![if !supportLists]>e.      <![endif]>in total there are 1630 types  (34%) with less than 5 members in them.

 

now , let you show you some example of lazy elements in our codebase:

 

Public Interface IController

        Property ctrlMain() As IController

End Interface

 

 

Public Class IndividualLienBE

        Inherits LeinBE

 

       Public Sub New()

            MyBase.New()

            LeinHolder = New CustomerIndividualBE

        End Sub

End Class

 

 

  Public Class PilotUpdateCheckBO

        Inherits BaseBO

  End Class

 

 

Public Class SupportingDocumentsBE

 

        Private mDocumentName As String

 

        <DataMember()> _

        Public Property DocumentName() As String

            Get

                Return mDocumentName

            End Get

            Set(ByVal value As String)

                mDocumentName = value

            End Set

        End Property

End Class

 

the projects below are empty projects, which would be better if we exclude them form our soultions.

 

Application\Placards\ServiceLayer\Placards.Entities

Application\Placards\ServiceLayer\Placards.Services

Application\Placards\ServiceLayer\Placards.BusinessObjects

Application\Placards\PresentationLayer\Placards.Presentation.Services

Application\Placards\PresentationLayer\Placards.Presentation.Entities

Application\ReferenceData\ServiceLayer\ReferenceData.BusinessObjects

 

 

from the information above, you could tell we do have quite a bit of lazy components and types in our code base

 

 

On the other end,  we have some very busy components and busy classes. take an example: CustomerDetailsForm has 1291 members. DataEntity project has 1920 classes in it.

 

in conclusion : there are many lazy projects and lazy types in in the codebase and at the same time, there are some huge projects and huge class in it as well. this situation presented certain difficult in continue developing and maintain the code base.

 

 

when you identify some lazy classes or lazy components,  the following are recommended actions you might want to take:

 

<![if !supportLists]>1.      <![endif]>if it is an empty one, eliminate it for sure, all empty components, classes and methods. these are doing nothing good but creating confusions. At least you want to exclude them from the solution or project.

<![if !supportLists]>2.      <![endif]>if it is not empty, you might want to consider to merge it to its close related fellows.

<![if !supportLists]>3.      <![endif]>all classes and all interfaces should at least doing something meaningful  or representing business entity meaningful to justify its existence in the code.