Many times, when coding, we use different data structures: stacks, queues, trees.
These structures have the elements linked between them, allowing parsing and searching.
Usually when we start coding such a structure we consider a unidirectional link between the elements, mostly to save memory.
Let's consider the following class:
Saturday, January 30, 2016
Friday, January 29, 2016
Refactoring - Introduce new method
Consider you have a function that perform an activity on an object a certain class in multiple places across the class and the project.
Sometimes, it makes sense to add that functionality directly to the class.
Swift makes this very simple using extensions. They allow to add new functionality to an existing class, structure or enumeration even if you do not have access to its code.
Let's take the following example:
Sometimes, it makes sense to add that functionality directly to the class.
Swift makes this very simple using extensions. They allow to add new functionality to an existing class, structure or enumeration even if you do not have access to its code.
Let's take the following example:
Thursday, January 28, 2016
Refactoring - Inline temp
This refactoring is the reverse of the Explaining variable.
You added a new variable to make the code clearer. But after few changes the variable is not really useful.
Consider the following piece of code:
You added a new variable to make the code clearer. But after few changes the variable is not really useful.
Consider the following piece of code:
Wednesday, January 27, 2016
Refactoring in Swift - Inline class
This method of refactoring is just the opposite of Extract class.
Think of a class that became so small and so unused that it does not justify its existence.
Consider an application that has the following classes:
Think of a class that became so small and so unused that it does not justify its existence.
Consider an application that has the following classes:
Tuesday, January 26, 2016
Refactoring in Swift - Replace Array with an Object
This refactoring applies to the case when different kinds of information are stored in an array.
For example, we have an array storing the first name, the last name and the age as follows:
For example, we have an array storing the first name, the last name and the age as follows:
Monday, January 25, 2016
Refactoring in Swift - substitute algorithm
In previous post (Simplify nested conditionals with returns) we arrived at the following code:
func bonusForSalary(salary:Float, numberOfKids: Int) -> Float {
if numberOfKids == 0 {
return salary * 0.2
}
if numberOfKids == 1 {
return salary * 0.3
}
if numberOfKids == 2 {
return salary * 0.4
}
if numberOfKids == 3 {
return salary * 0.5
}
return salary * 0.6
}
Refactoring in Swift - simplify nested conditionals with returns
Consider the case when a function needs to calculate the result using a complicated set of logic statements based on the input.
We would need to store the result in a variable and return it at the end. Or do we?
We would need to store the result in a variable and return it at the end. Or do we?
Friday, January 22, 2016
Refactoring in Swift - Extract class
According to the Single Responsibility Principle, one class should do one thing. Also it needs to know the least amount of information to do its job.
In time though, all the classes evolve by accumulating more and more properties and functions. That is why refactoring is needed to simplify them and restrict their area of action.
One of the methods is extract class method. When a class becomes too big, extract part of it as another class.
Consider the following User class:
In time though, all the classes evolve by accumulating more and more properties and functions. That is why refactoring is needed to simplify them and restrict their area of action.
One of the methods is extract class method. When a class becomes too big, extract part of it as another class.
Consider the following User class:
Wednesday, January 20, 2016
Refactoring in Swift - Move method
"Yesterday, I froze some water."
While this is possible (I took some water, put it in a container, and in the freezer), it sounds funny. Of course, I did not froze the water, because I don't do that. I am not a freezer. The freezer freezes water, that is why it is called a freezer.
"As it snowed today, I will blow the snow."
While this is possible (I took some water, put it in a container, and in the freezer), it sounds funny. Of course, I did not froze the water, because I don't do that. I am not a freezer. The freezer freezes water, that is why it is called a freezer.
"As it snowed today, I will blow the snow."
Tuesday, January 19, 2016
Learn how to build apps
Are you interested in learning how to build apps for iPhone and iPad?
You don’t know where to start?
Let me know and I will help you to the best of my knowledge and my time.
There is no cost involved.
I love building apps and if I can help you get started and get you to love it too,
that will be enough payment.
You don’t know where to start?
Let me know and I will help you to the best of my knowledge and my time.
There is no cost involved.
I love building apps and if I can help you get started and get you to love it too,
that will be enough payment.
Monday, January 18, 2016
Refactoring in Swift - move field
Imagine classes as families. They should hold inside only what makes sense.
One does not invite neighbours to live with them, does he? Invite them to visit, maybe, but move in, no way!
So are classes. They should hold only the fields that make sense.
One does not invite neighbours to live with them, does he? Invite them to visit, maybe, but move in, no way!
So are classes. They should hold only the fields that make sense.
Friday, January 15, 2016
Refactoring in Swift - Replace method with method object
Let's continue with the same game as in Explaining Variable refactoring method.
We still have the two ships, each of them defined as a rectangle (CGRect) but today they start shooting at each other.
So other than the ships we have two projectiles, also defined as rectangles.
We also have a number of functions to manage the game.
We still have the two ships, each of them defined as a rectangle (CGRect) but today they start shooting at each other.
So other than the ships we have two projectiles, also defined as rectangles.
We also have a number of functions to manage the game.
Thursday, January 14, 2016
Refactoring in Swift - explaining variable
Swift theory
In case you are not a Swift programmer, CGRect is a structure that defines a rectangle by setting its origin and size.
For example, a CGRect of value (10, 20, 100, 150) represents a rectangle with origin at x = 10 and y = 20 and with a size of width = 100 and height = 150.
Refactoring
Now, let's build a game. Or at least a very small part of the game.
In case you are not a Swift programmer, CGRect is a structure that defines a rectangle by setting its origin and size.
For example, a CGRect of value (10, 20, 100, 150) represents a rectangle with origin at x = 10 and y = 20 and with a size of width = 100 and height = 150.
Refactoring
Now, let's build a game. Or at least a very small part of the game.
Wednesday, January 13, 2016
Refactoring in Swift - Inline function
Refactoring by inline function is the opposite of the
Extract function we analyzed in a previous post.
In this case, a function is so short and it is used only in one or two spots that is it not worth having it separately.
This refactoring is done by removing the function and replacing each call with its content.
In this case, a function is so short and it is used only in one or two spots that is it not worth having it separately.
This refactoring is done by removing the function and replacing each call with its content.
Thursday, January 7, 2016
Refactoring in Swift - Extract function
The simplest method of refactoring and maybe the most used is performed by moving the code around.
We can move it from one function to another, from one class to another or create a new entity, in our case, a new function.
Consider the following function to validate three fields: first name, last name and address. Each variable needs to have a value.
var firstName, lastName, address : String?
firstName = "John"
lastName = "Smith"
address = "20 New Way St."
func validateForm() -> Bool {
var valid = true
if (firstName == nil) || (firstName!.characters.count == 0) {
valid = false
}
if (lastName == nil) || (lastName!.characters.count == 0) {
valid = false
}
if (address == nil) || (lastName!.characters.count == 0) {
valid = false
}
return valid
}
Tuesday, January 5, 2016
A Little Architecture by Uncle Bob
I want to become a Software Architect.
That's a fine goal for a young software developer.
I want to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.
Oh. Well, then you don't want to become a Software Architect after all.
read more
That's a fine goal for a young software developer.
I want to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.
Oh. Well, then you don't want to become a Software Architect after all.
read more
Monday, January 4, 2016
Refactoring in Swift
Definition
Refactoring is the activity of cleaning the code, improving the design, after the code is written.
Refactoring is not changing the functionality of the code. If it does, it is called maintenance. [Thank you Max]
You can say that it is corresponding to the design phase, but after some piece of code was written.
While a developer can plan for the code to be nicely written, in time, the code gets messier so cleaning is required.
Just like the house cleaning, the more often the code is cleaned, the easier and more effective it is.
Refactoring does not bring any benefit right away. The functionality is not changed during this activity so there is no change for the user. The real benefit is when new features are added.
We’ll start today a series of refactoring tips in Swift, most of them adapted/stolen from Martin Fowler’s “Refactoring - Improving the design of existing code” book.
Refactoring is the activity of cleaning the code, improving the design, after the code is written.
Refactoring is not changing the functionality of the code. If it does, it is called maintenance. [Thank you Max]
You can say that it is corresponding to the design phase, but after some piece of code was written.
While a developer can plan for the code to be nicely written, in time, the code gets messier so cleaning is required.
Just like the house cleaning, the more often the code is cleaned, the easier and more effective it is.
Refactoring does not bring any benefit right away. The functionality is not changed during this activity so there is no change for the user. The real benefit is when new features are added.
We’ll start today a series of refactoring tips in Swift, most of them adapted/stolen from Martin Fowler’s “Refactoring - Improving the design of existing code” book.
Subscribe to:
Posts (Atom)