005Dikshant / MidTerm6491

GNU Lesser General Public License v2.1
0 stars 0 forks source link

Type Checking Refactoring in IntermediateAbstractRenderer.java #4

Open 005Dikshant opened 6 months ago

005Dikshant commented 6 months ago

Package: org.jfree.chart.renderer className: IntermediateAbstractRenderer

Now duplicate code refactoring is done, I see the drawMarkerExtracted() in IntermediateAbstractRenderer.java, Have some if and else if blocks that are being executed when the Marker object is either of ValueMarker or IntervalMarker.

Clone: Type 2 Clone In both sections of the clone, the code validates whether the marker is either a ValueMarker or an IntervalMarker using instanceof checks. However, the subsequent actions taken for each type differ significantly.

For instance:

  1. When dealing with a ValueMarker, the code computes the marker's position and draws a line accordingly. It also handles label rendering.
  2. Conversely, for an IntervalMarker, the code determines the start and end values, draws a corresponding rectangle, and manages the outline and label rendering differently.

Despite these distinctions in behavior, the underlying structure and approach remain consistent, showcasing a Type-2 clone where the code follows a similar pattern but diverges in the details of execution based on the marker type encountered

005Dikshant commented 6 months ago

To implement the TypeChecking refactoring, I examined the refactored method drawMarkerExtracted resulting from the previous duplicate code refinement #3. I noticed that it contained if and else blocks, each handling logic based on whether the Marker object was an instance of ValueMarker or IntervalMarker. To address this, I followed these steps:

  1. I abstracted the if block into a separate function and relocated it to ValueMarker.java, naming the extracted function getConcreteMarker.
  2. A challenge arose when attempting to call marker.getConcreteMarker(), as the Marker object did not recognize the function. To resolve this, I introduced a default empty method into Marker.java, allowing access to getConcreteMarker across all concrete classes derived from Marker.
  3. I streamlined parameter usage by simplifying access to the marker object using the 'this' keyword.
  4. I replicated these steps for the else if block, extracting the method into IntervalMarker.java with the same name, getConcreteMarker.
  5. Finally, I streamlined the invocation of drawMarkerExtracted by simply calling marker.getConcreteMarker(), allowing runtime determination of the marker's type, whether IntervalMarker or ValueMarker.