# Object Orient Programming-Course2 Week3-2: Code Smells
###### tags: `OOP` `Coursera`
<style>
.red {
color: red;
}
</style>
<style>
.blue {
color: blue;
}
</style>
<style>
.green {
color: green;
}
</style>

## Refactor
* **definition: Refactoring is the process of making changes to your code so that the <span class = "red">external behaviors of the code are not change</span>, but the internal structure is improved.**

## Anti-Pattern
* Comments: Both having no comments and having lots of comments are bad design. Having no comments make it difficult for someone like collaborative developers to understand what the codes is doing or should be doing. Having too many comments often means that you need alot of comments to cover up bad design.
* Duplicated code: Duplicated code is when you have blocks of code that are similar, but have slight differences. These blocks of code appear in multiple places in your software. Having to update it in only one location will make it easier to implement the change and reduce the chance that you are missing a block of code that nees to be updated or changed.
* Long Method: Having a long method can sometimes indicate that there is more occuring in that method than should be. Or it is more complex than it needs to be.
* Large class: also refer as "God Class", "Blob Classes", "Black Hole Classes" Mind: larger classes will have more potential to get largerXD. You need to be explicit of the purpose of a class. Keep the class **cohesive** so it does one things well.
* Small class: These are often <span class = "green">"data classes"</span>. Data class would have getter and setter method. Instead of getter and setter, you should give more responsibility to data classes.Ex:2D point class: various trasformation fucntion that move the point.
* Long parameter list: Having a long parameter list is difficult to use. <span class = "red">**Global variables are not a good solution.**</span>. You should introduce parameter object.EX: drawCircle(int x, int y, int z, int r)=>drawCircle(Circle myCircle);
* Divergent Change: The "divergent change" code smells occures when you have to change a class in many different ways, for many different reasons.Often caused by **Large class**. The principle, <span class = "green">seperation of concerns</span>, can fix these two code smells simultanously.
* Shotgun surgery: This is a commonly occuring smells. A change in one place requires to fix many other areas in the code as a result. Sometimes this smell is inevitable. You can mormally reslove the shotgun surgery smell by moving methods around.
* Feature envy: Feature envy occurs when you've got a method that is more interested in the details of a class other than the one that it's in. If it seems like two methods or classes are always talking to one another and should be together, chances are they probably should.
* Inappropriate intimacy: the issue of when two classes depend too much on one another through two way communication. To remove this cycle, you can factor out methods that both classes use into another class. This might free up some of the close communication. Exception: state pattern has cycle, sometimes this smell is inevitable.

# Capstone Assignment 2.3 – Identify and Fix Code Smells

## How to create your assignment
* Part 1

Use the given code base to identify two code smells that are described in the Anti Patterns & Code Smells lecture -- excluding Long Method.

For each of the two code smells you have identified:

1. Document them by clearly stating where the code smell is (which class, which method, etc.)
2. Which code smell from the lecture it is, and why you think the code fits the description of the code smell.
3. Give your reasoning on why each code smell is a problem and should be fixed.
4. Suggest a solution to fix the code smell.

* Part 1 Notes:

1. If the same piece of code has more than one code smell in it, all code smells will count, as long as each has their own code smell type and solution. However, identifying the same code smell twice in different parts of the code will not count.
2. We do not want you to actually fix these two code smells!
3. You should only have to write one paragraph per code smell and submit no more than 600 words for your answer.
4. If you would like you may use UML diagrams alongside your explanation to illustrate how something is a smell or how it should be fixed.

* Part 2

In this second part of the assignment, the code smell you will be fixing is Long Method.

To fix this code smell, you will Implement a validateInput() method in the following activities:

1. AddItemActivity
2. EditItemActivity
3. AddContactActivity
4. EditContactActivity

These four activities all contain “save” methods that consist of several lines of code for validating user input. The lines of code responsible for validating the input should be moved to the validateInput() method. This new method can then be called from inside the save method.

## Submission

### Code Smell 1: Duplicated code
* Location:
1. loadContacts(Context context) in class ContactList and loadItems(Context context) in class ItemList
2. saveContacts(Context context) in class ContactList and saveItems(Context context) in class ItemList
* Description:
Despite the difference of the name of the function and the class they belong, these two pairs of functions have exactly the same codes. This means that when changes made to any of these functions, the changes will have to be done two times which is error prone.
* Solution: Create a class that handles storage by taking object type and name as its members. It handles reading and storing data.

### Code Smell 2: Use too many Comments
Class EditContactActivity::saveContact(View view)
Class EditItemActivity::toggleSwitch(View view)

* Location:

1. saveContact(View view) in class EditContactActivity
2. toggleSwitch(View view) in class EditItemActivity
* Description:
In these two functions, comments are spread before and over the whole functions. By percisly arrange the name of functions, classes and variables and by using enum and reference nicely, code can be read easily without redundant explaination made by comments. Excessive use of comments can cause extra work if the code changes. Also, outdated comments often occurs and misleads developers.
* Solution:
Make variable name, method name self-explanatory. Use enumerators to define alias.