Scribd
Upload
42 views26 pages

Pemrograman Lanjut: Code Smells: Bloater

Code smells refer to characteristics in code that indicate deeper problems. This document discusses the "bloater" code smell and provides examples. It defines long methods as methods with more than 10 lines of code. Long parameter lists are those with more than 3-4 parameters. Data clumps are identical groups of variables across code. Primitive obsession is the overuse of primitives instead of objects. Large classes become bloated over time. The document provides refactoring techniques for each smell.

Uploaded by

Indra Ayudya Dwi Prasetya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views26 pages

Pemrograman Lanjut: Code Smells: Bloater

Code smells refer to characteristics in code that indicate deeper problems. This document discusses the "bloater" code smell and provides examples. It defines long methods as methods with more than 10 lines of code. Long parameter lists are those with more than 3-4 parameters. Data clumps are identical groups of variables across code. Primitive obsession is the overuse of primitives instead of objects. Large classes become bloated over time. The document provides refactoring techniques for each smell.

Uploaded by

Indra Ayudya Dwi Prasetya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

PEMROGRAMAN LANJUT

Code Smells: Bloater


Oleh
Tri Hadiah Muliawati
Politeknik Elektronika Negeri Surabaya
2021
Bloater
Code, methods and classes that have increased to
such gargantuan proportions that they’re hard to work with.
Bloater
• Long Method
• Long Parameter List
• Data Clump
• Primitive Obsession
• Large Class
Long Method
• A method contains too many lines
of code. Generally, any method
longer than ten lines should make
you start asking questions.
• If you feel the need to comment on
something inside a method, you
should take this code and put it in
a new method.
Long Method: Refactoring
• Extract Method: To reduce the length of method body.
• Replace Temp with Query, Introduce Parameter Object, Preserve
Whole Object: If local variables and parameters interfere with
extracting a method.
• Replace Method with Method Object: the local variables in long
method are so intertwined that you can’t apply extract method.
• Conditional operators and loops are a good clue that code can be
moved to a separate method.
The original method (doManagerJob()) consists of
more than 10 Line of Code (LoC)
Long Parameter List
• More than three or four
parameters for a method.
Long Parameter List: Refactoring
• Preserve Whole Object: Instead of passing a group of data received
from another object as parameters, pass the object itself to the
method.
• Introduce Parameter Object: If there are several unrelated data
elements, sometimes you can merge them into a single parameter
object.
• Replace Parameter with Method Call: If some of the arguments are
just results of method calls of another object. Place object in the field
of its own class or passed it as a method parameter.
Parameter seasonDiscount and fees can be
placed inside discountedPrice() method.

We can also move method calls


(getSeasonalDiscount() and getFees())
into discountedPrice() method.
Data Clumps
• Sometimes different parts of the
code contain identical groups of
variables (such as parameters for
connecting to a database).
• These clumps should be turned
into their own classes.
Data Clumps: Refactoring
• Extract Class: If repeating data comprises the fields of a class, move
them to their own class.
• Introduce Parameter Object: If the same data clumps are passed in
the parameters of methods.
• Preserve Whole Object: If some of the data is passed to other
methods, think about passing the entire data object to the method
instead of just individual fields.
Primitive Obsession
• Use of primitives instead of small objects for simple tasks (such as
currency, ranges, special strings for phone numbers, etc.)
• Use of constants for coding information (such as a constant
USER_ADMIN_ROLE = 1 for referring to users with administrator
rights.)
• Use of string constants as field names for use in data arrays.
Primitive Obsession: Refactoring
• Replace Value with Object: If you have a large variety of primitive
fields, it may be possible to logically group some of them into their
own class.
• Introduce Parameter Object or Preserve Whole Object: If the values
of primitive fields are used in method parameters.
• Replace Array with Object: If there are arrays among the variables.
• Replace Type Code with Class, Replace Type Code with Subclasses or
Replace Type Code with State/Strategy: If complicated data is coded
in variables.
customer field has its own behavior and associated
data. Thus, it is better to turn it into class.
Large Class
• Classes usually start small. But over
time, they get bloated as the
program grows.
Large Class: Refactoring
• Extract Class: if part of the behavior of the large class can be spun off
into a separate component.
• Extract Subclass: if part of the behavior of the large class can be
implemented in different ways or is used in rare cases.
• Extract Interface: if it’s necessary to have a list of the operations and
behaviors that the client can use.
• If a large class is responsible for the graphical interface, you may try
to move some of its data and behavior to a separate domain object.
References
• Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship.
Pearson. 2008.
• Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-
Wesley Professional, 1999.
• https://refactoring.guru/
• Putra, F. Z. P., 2019. Rancang Bangun Pustaka untuk Refactoring Otomatis
terhadap Long Method Code Smell.

You might also like