Code Smells

Today I am doing another smells blog post but this one is going to about code instead of design. This article that I am doing it on contains many of the code smells and I will be being writing about some of the things I learned from them. First, code smells within codes:

Comments – I learned to remember that comments should be written for people, not the machines. I will also try to refactor my code as possible to avoid to comments for example better method names and cleaner code, so it would be easier to understand and follow.

Long Method – I learned that shorter method is better than longer method because it is easier to read, understand, and maintain. I will always try to minimize the size of my method as small as possible to be more efficient.

Long parameter list – I learned a great to limit the number of parameters by using a object to combine it if I actually need the values of the parameters because the more parameters there is, the more complex it is.

Duplicated Code – never have code that duplicated.

Conditional complexity – don’t have large conditional logic block, use design patterns to avoid this problem.

Combinatorial explosion – I learned that this is when we have lots of code perform the same operation but have a little difference. I think the best way to avoid this is to make a method for the operation.

Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.

Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.

Also, Code smells between classes:

Data class – I learned to avoid class that only data because a class should have data but should have method to manipulate the data.

Lazy class – this just means that every class should be important enough to be a class.

Shotgun surgery – this means that you should avoid making a class that effect other classed when making an update.

Solution Sprawl – this is when you have need multiple class to do one thing, it’s better off to simplify the code.

All in all, this article has All in all, this article has code smells and I learned a lot from them. I now know how to avoid these smells and how to deal with them after reading this.


What Causes Design Smells?

Hello, every and welcome to another blog post by Phan CS. Today topic is about to be about design smells. According to this article “design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality”.  Design smells affect the software quality and the organization in a negatively way. The organization will be affected because the presence of the smells in the framework will be used by clients and depending of the feed back which is usually going to be negative, the whole community is going to feel the same and it’s also hard to fix design in the API when the API is already in use. There are many causes of design smells. First, when a class has multiple responsibilities this would consider a violation of design principles which they named multifaceted abstraction smell because abstraction should be unique. They had an example of this problem in the article which explains that calendar class in the java.util package support date-related functionality which it is supposed to but also supports time-related functionality as well which is a violation of design principles. Second, inappropriate use of design patterns which is when programmers try to apply design pattern because they are pressure into using them by don’t fully understand how use them and this result of too many classes. Next, is language limitations, this when two methods that support different primitive types belong to the same class and its java does support primitive types which result in it’s impossible to remove duplicate code. Also, when programmers mistakenly think classes are doing things instead of being things, this can cause problems that can result in design smells. Finally, design smell is usually created when a programmer is in a rush and is hacking the code because it requires less time and effort to do it this way. When the environment is following practice usually other programmers will so the same. All in all, design smell should be avoided because it bad for product. I thought this was interesting in many ways. This change the way I code because I will be thinking about what I am doing more.

solid, grasp, and other basic principles of object-oriented design

Today’s topic for blog 6 is solid, grasp, and other basic principles of object-oriented design. This article teaches you about basic about solid and grasp languages. First, code should have the following qualities maintainability, extensibility, and modularity. These qualities are usually in code that are easy to maintain, extend, and modularize over its lifetime. This article has many examples written in java and c#. These are the principle that the article goes through:

Single responsibility principle which states that a class should have only one responsibility and a class a fulfills its responsibilities by using its functions.

Open-closed principle which states a software module (class or method) should be open for extension but for modification.

Liskov substitution principle which states derived classes must be substitutable for their base classes. What this basically means is that abstraction should be enough for a client.

Interface segregation principle which states clients should not be forced to depend upon the interfaces that they do not use.

Dependency inversion principle which states program to an interface, not to an implementation.

Hollywood principle which helps prevent dependency rot. It states that a high-level component can dictate low-level components in a manner so that neither one is dependent upon the other.

Polymorphism which they say it is a design principle.

Information expert which helps you to give responsibilities to classes.

Creator which is a grasp principle that helps decide which class should be responsible for instantiating a class.

Pure fabrication which reduces the cohesiveness of the domain classes.

Controller which is a design principle that helps minimizing the dependency between gui components and the domain model classes.

And favor composition over inheritance and indirection.

All these topics were provided examples and it was very easy to understand. I thought this article was very informative. I think it provides the basic main idea of these principles. After reading this article I changed the way I work because I now know how to apply these principles to improve my code. I agree with everything in this article but if I would to improve it, I would say to break up grasp and solid to separate articles. All In all, this article was  very useful in learning the basic about different principles and how to apply them.


Hey everyone, welcome back to phan’s cs where I discuss my recent 343 CS course related topics that I’m currently learning. Today I’m using Edureka blog about object-oriented programming for my resource which can be found on Java OOPS concepts which stands for object-oriented programming is a programming style that includes concepts like class, abstraction, object etc. The core of oriented-oriented programming involves these four concepts inheritance, encapsulation, abstraction, and polymorphism. First, the concept of inheritance is where the properties of one class can be inherited by the other. A great analogy is a parent and child, where the child inherited properties from the parent. In programming, this would be called a parent class which is a super class and a child class which is known as a sub class a sub class. There are classified into 4 types single, multilevel, hierarchical, and hybrid. Second, encapsulation, this means to hide your data to prevent any modifications. This can be done by two ways, first, declare the variables of a class as private and constructing public setter and getter methods to get or change the variable. Next, abstraction which is basically hiding the details and providing the vital things. A good example cell phone that they provide in this blog is a cell phone which a user can make calls, take pictures, etc. and there’s a lot of code that runs in the background that the users doesn’t have to worry about. Finally, there is polymorphism, which many forms. This when you can have multiple implementations for an interface or method. All in all, object-oriented programming is a programming style which involves these four concepts inheritance, encapsulation, abstraction, and polymorphism. The reason why I choose this topic is because I wanted to review the main objective of OOPS. I think this article is very informative and provides many analogy and examples of the concepts which made it easier for me to understand the material. I agree with many of materials that it provides and think it was very accurate. After reading this blog, I think it change the way I work because I now have a better understanding of Java OOPS.


Today blog is about a brief introduction on angular. This article starts off explaining what a scope is. This was not new to me because I have a little background in programming but I assuming this part of the blog is for people who is just started programming and pursued angular as the focused. The definition of angular in this article “a structural framework for dynamic web applications, made in pure JavaScript.” What does structural framework mean? I didn’t know at first, but this article explains well, it’s states that “angular is a structural framework because it allows us to use HTML as a template language and extend its syntax to express the components of the applications in a cleaner and simpler way.” Basically, I think its take complex syntax like HTML and converts it to a simpler format. AngularJS uses MVC where whatever is changed in the controller is updated in the view. It’s appropriate to use AngularJS when the it is a large application, when you need a good structure, when you need a robustness, and when the application is complex. The controller is a tool that Angular provides. A controller acts as the middleman between various views and models. The web view or mobile view is the user interface, it’s what the user sees, and the model is the database. A module is a gives structure to an application because it acts as “a container for controllers, services, filters, directives.” I learned that it reusable and doesn’t require to run in any specific order because it can slow down the execution time and it great for unit testing. There are also two types of service, Factory and Service. They both services are ways to create an object. After reading this blog I learned a little more about Angular. This article was helpful but didn’t have much example of the topic which I would like because some topics I wanted to know what its visual look like. All in all, this article was helpful, and it changed the way I look about this topic Angular because it seems more complex which I will research further but for now this is all.

Flyweight Design Pattern

Today blog is about Flyweight Design Pattern. Flyweight design pattern a structural design pattern like the adapter pattern that we learned in class and decorator pattern in home work two. Flyweight design pattern is applied in a situation when we need to instantiate a large number of objects of a class. It reduces the amount of memory consumed and execution time by sharing objects that similar in some way. Flyweight objects can’t be modified once they have been constructed which means in short, it’s immutable. HashMap is used in flyweight pattern to reference of the created objects. The Object property are also divided into two properties intrinsic and extrinsic. “Intrinsic properties make the object unique whereas extrinsic properties are set by client code and used to perform different operations.”. An example of Intrinsic state is that if there a Shape object that already created we don’t have to create another color feature because every shape has a color related instead we can just use the already created object. The extrinsic state is the size of the shape which is different for many objects. To return the shared objects we have to create a flyweight factory which is used by the client programs to create the object. All in all, this design pattern is used to speed up the speed of the program by sharing objects instead of creating new ones. I think this design pattern is complex. I don’t see this pattern used often unless the program is creating insanely number of objects. During this tutorial, I learned a lot about this design pattern, they used a shape example which shows the result of flyweight design pattern. I thought this was interesting, but I couldn’t think of many other situations that this design pattern can applied to. The tutorial was straight forward so I didn’t disagree with everything. This design pattern is complex so the I had trouble understanding it but when I actually implemented and ran the code I had a better understanding of this design pattern. This content did change the way I think because I now know there is many ways to increase the performance of my code.

factory design pattern

This week blog post is going to be about one of the creational design patterns, Factory Pattern. Factory pattern has many advantages:

  1. “Factory design pattern provides approach to code for interface rather than implementation.
  2. “Factory design pattern removes the instantiation of actual implementation classes from client code. Factory pattern makes our code more robust, less coupled and easy to extend. For example, we can easily change PC class implementation because client program is unaware of this.
  3. “Factory pattern provides abstraction between implementation and client classes through inheritance.

When we have a super class, which can be an (interface, abstract class, and concrete class) with many sub classes and we want to return one of the subclasses based on a specific input, this can be done with Factory Design. The benefit of factory design is that we don’t have to instantiate a class every time we want to use a class instead we can just call the Factory class.

For example, if we had an interface named Game System and we created more than one sub class that implements it (ps4, Xbox, and pc) and then we wanted to use one of those objects in a test class, we would have instantiated one of the sub class every time we created an object from the class. This way is very tedious, that’s why Factory design is so helpful. Instead creating a object every time, we can create an Game system factory which allows us to input for example enter a string name “ps4” and create a ps4 class instead creating for example GameSystem gs = new ps4(); every time.

I think factory design pattern should be used mostly every time if there are more than one sub classes just because it removes clutter and simplify the code to be more readable. From my personally experience I think factory design patter help me think more about organization when coding. I always think of ways to make my code more reusable after reading this article. All in all, Factory design pattern is very helpful and is an important method when it comes to Object oriented programming.