Learning more on Design Patterns

So for this week I have decided to read “Brief Introductions to Design Patterns” from the Technical Blog by Future Processing. The reason I have chosen this blog is because I want to have a simple, clear understanding of the design patterns. It will help in which pattern should I utilize mostly for the rest of the patterns to implement easily after using it.

This blog post basically goes over selected patterns using the division that was proposed by the Gang of Four. The division goes from Creational patterns, Structural patterns, and Behavioral patterns. For creational patterns, they are supposed to prevent from occurring problems and introduce more control over creating objects. The three selected patterns from Creational are Singleton, Factory Method, and Abstract Factory. Singleton provides global access to at most one given class references, Factory Method provide an interface to generate objects, and Abstract Factory provides an interface for creating groups of objects without exact implementation. For Behavioral patterns, they are meant to introduce flexibility to solutions connected with inter-objects communication. The two selected patterns from Behavioral are Observer and Strategy. Observer is used to inform the group of objects to change the state of another specific object while Strategy is used to isolate algorithms, encapsulate them, and make them interchangeable. Structural patterns are to facilitate the operation and design applications through finding an easy way to realize dependencies between entities. The two selected patterns from Structural are Facade and Adapter. Facade is a simple pattern that makes code more legible and comfortable to use by stitching intricate references. Adapter seems similar to Facade, but is to introduce a new interface that hides the previous one.

Based on the contents of this blog, I would say this was a very intriguing read on the take of the design patterns. The author provided some UML diagrams and code written in a variety of programming languages to show each of the differences from the patterns. It was simple and easy to follow once looked closely. What I did before to understand the design patterns was that I tried to stick with only one programming language which was Java and implement each pattern in a way to utilize in future practice. It has helped me understood some of the patterns that was confusing at first with glance of the UML diagrams.

What I learned from this blog about certain design patterns is that the Singleton pattern should not be used too carelessly as it breaks two principles of SOLID and is problematic when implementing in multi-threaded environment. The idea I got from this blog is that while Singleton Pattern might be helpful in some ways, it is not what should be used every time before utilizing the other patterns.  For future practice, I shall try to use the Façade Pattern more often as it will help in making better designed API and will give a better start that the other patterns can be utilized easily.


Link to the blog: https://www.future-processing.pl/blog/design-patterns/


The Five Principles of Object Oriented Design

So for this week, I have decided to read about “The SOLID principles in real life” from the Infragistics blog. The reason I have chosen this blog is because while I do get the concept for each of them that which will guide me to writing clean code, I need a better grasp to put these principles into practice and not be limited that is just following a set of rules. This relates towards in making design patterns that which by using these practices, design patterns become a lot easier to implement.

For this blog post, it basically goes over the five principles of object oriented programming that which makes the acronym SOLID with real life analogs by the author.  For the first letter of the acronym S, this stands for Single Responsibility Principle. It asserts that a class or module should do one thing only. The purpose with this principle is to fight complexity while developing an application’s logic. For the second of the acronym O, this stands for Open/Closed Principle. It states that code entities should be open for extensions like extending certain behaviors but closed for modifications to achieve a flexible system architecture which is the purpose. The next letter of the acronym, L, stands for Liskov Subsitution Principle. This principle basically asserts that parent instances should be replaceable for the child instance without creating unexpecting behavioral problems. The fourth letter of the acronym, I, stands for Interface Segregation Principle. It states that main instances or classes should be segregated into smaller classes to use methods that is needed.  Lastly but not least, D stands for Dependency Inversion Principle. It encourages user to write code that depends upon abstractions than concrete details to give flexibility in it.

Based on the contents of this blog post, I would say that this was very good to read. Purposes of each principle was straightforward and easy to pick up upon while reading it. That is because the author uses real life analogs to give clear visualizations how the principles work in an effective way.  For my experience with the concepts of SOLID, I would try to use sample design patterns and go by each of the principle to gain a bit of practice in implementing clean codes.

From this blog about the SOLID principles, what I learned is that the Interface Segregation and Dependency Inversion should be the ones to take mostly into account. The ideas that I have been taught is that it will avoid having the code to re-compile with annoying frequency and swapping in anything that conforms to the abstraction will be easier. Learning the ideas from this blog shows me that for future practice, I should be trying to visualize the SOLID principles with real life perspectives as it will help in the logic of building system architecture and design patterns. I hope that with this knowledge, achievement of an extendable codebase is possible.

-Dennis Tran


Link to the blog: https://www.infragistics.com/community/blogs/erikdietrich/archive/2016/01/26/the-solid-principles-in-real-life.aspx

Seven Hints of Design Smells

This week I have decided to read about “Design Smells” from Bartek’s Coding Blog. So, while   this blog is rather short, the reason why I have chosen this one in particular is because recently in my studies, my biggest question that how do people figure out the errors of a design without testing or even refactoring. I want to understand the logical thinking in recognizing the errors that point to a wrong design.

This blog post basically goes over seven hints of design smells that points to places that the code is not going as intended. These seven hints are rigidity, fragility, immobility, viscosity, needlessly complexity, needlessly complexity, and opacity.  For rigidity and fragility, they point to the belief of a simple change will fix everything but other unexpected things can happen and the code can fall into pieces. Immobility and viscosity, on the other hand, point to “moving” and using codes to be improving the design but preserving it while implementing new features might be difficult. Needlessly complexity and repetition are easy to understand. They point to implementing something complex and copy and paste that is not needed at all. As for the last hint, Opacity, points to making a code clear and easy to understand.

So, based on the blog post with the insights I find behind it, I would say this was a simple but interesting blog to read. The author explained each of the seven hints with a simple take of every day programming work while giving the literal term along with it. From my experience in finding something wrong in a design, it’s usually testing which takes a considerable amount of time depending on how much writing there is into it. If there are unrelated errors occurring within testing, then it would be where I will try to figure out which part of it is the source of the problem and then try to debug it as much as possible.

From this blog about design smells, what I learned is that to avoid conflicted attention described by the hints, there should be consideration always in preserving the original design codes. The ideas that I have been taught is while it might be inconsistent to use the codes like that, there is no need to be “afraid” in both using general codes for future reference and bending the original design a little to improve the programming process. Learning the ideas from this blog shows me that for future practice, I should try to find features implemented in designs and trace down codes that give a complexity on the urge of repeating itself. That way, I can try to get the simple thinking of identifying problems without having to recreating codes like that. With this knowledge, I hope to assist others with great analyzing and fix codes better than I used to.

-Dennis Tran


Link to blog: http://www.bfilipek.com/2012/11/design-smells.html

The basis from Refactoring (Revised)


In the world of computing, many computer users have been in a state of cleaning up code whenever it is a task, a project, or even just for the sake of the product. So for this first week of blog development, I have chosen to read “Refactoring is About Features” from Code Simplicity. The reason that I have chosen this blog post because as a programmer, my question is how does “refactoring” come into the ideals of coding. I wanted to know more on how the concept of refactoring and the ideas around it.

This blog post basically goes over the ideas of refactoring and principles of having to refactor. So, refactoring by the words of the author, is an organizational process that you go through in order to make production possible. When it comes to refactoring, you want to be sure the service from it is really making progress and not just for the sake of fixing it, otherwise variety of problems will occur. On the other hand, if a system was produced and reorganizing was never done or considered, production for the final product becomes difficult or impossible. In order for the product to be produced quickly while having the system be effectively organized, both of these tasks have to be done in a reliable way with the principles. The principles are to have the system be in better condition and not worry about being “perfect” but better designed for an intended purpose. If organization is left out, the product is not as envisioned, and if production is left out, then the reason for doing refactoring is not even there anymore.

So, based on the content the blog post provided with analogies of the real-world experience, I would say this was great to read. The author provided some ideas of knowing when to refactor while handling the issues that does deny from doing it and giving tips that shows cleaning development directly and indirectly. From my mindset when it comes to cleaning up coding, it would be writing down a bit of documentation with just the implied codes that needed clarity and go from there.

From this blog about refactoring, I learned is that always be aware to change the design for the current purpose it serves as it leads to greater productivity and less redundancy. The idea that I have been taught is that while it might be great for the design to serve previous purposes, we can’t judge whether the design is acceptable without the purpose it does serve now. Learning the ideas from this blog gives me the realization that for myself, I should be trying to restrain from fixing codes that seems “wrong” in my eyes. This will allow me to apply future practice on implementing features and make good judgement in fixing it. So, I hope with this knowledge, I can build upon it to be flexible within my skills in coding.

-Dennis Tran

Link to the blog: http://www.codesimplicity.com/post/refactoring-is-about-features/