Understanding Inversion of Control

So for this week I have decided to read “Inversion of Control- An Introduction with Examples in .NET” from the joelabrahamsson website. The reason I chose this article is because with the subject of automatic testing, Inversion of Control and Dependency Injection is what I do not get mostly. It is usually a topic that I do not hear that much, so I believe this will help in understanding on the purpose of using both principles.

This article basically by the title goes over Inversion of Control from the definition to the ways of using it. So Inversion of Control is essentially a way to the invert the flow of control in comparison to procedural programming. It means that every module can focus on what is it designed for and ensures clarity with little complications. The benefits in using Inversion of Control is that when changing the interface of a particular class uses in runtime, that class can no longer be dependent on another class and the code can be decoupled. This means that the class is provided the ability to swap dependency implementations in different environments and allows a component be tested through mocking of dependencies. When having to apply Inversion of Control and getting the instance, there are two ways to get it without having to know about any concrete implementations. These ways are Dependency Injection and Service Locator. Dependency Injection injects an instance by using construction injection or property injection while Service Locator injects an instance based on the configurations of the concrete class. Dependency Injection is mostly used than that of Service Locator, but Service Locator can be used when there are situations Dependency Injection seems impractical.

Based on the content of this article, I would say that it was a good overview about the ideas of Inversion of Control. The author was able to give a few examples of using it and have the UML diagrams to back up with the codes provided. What I did before to understand Inversion of Control was to envision real life scenarios to compare without and with it. The concept is that without it, there is limited options for a software consumer. But by implementing Inversion of Control, there are more options over the software. With that in mind, it made envisioning scenarios easier than it seems.

What I learned from this article is that Inversion of Control shall not be used in all cases because of program flow. The idea is that while it is a useful way to design methods when writing a library that will be reused, it is only critical if there are many cross-cutting concerns. For future practice, I shall try to use Inversion of Control when it is necessary to change a small part of code. This is because it is a practical way of reducing code duplication and it is strong for coding against interfaces instead of implementations.

 

Link to the article: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

 

The Different types of UML diagrams

For this week with my spare time, I have decided to read “Process Modeling (UML Diagrams)” from the mohamedelgendy blog. The reason I have decided to read this one is because it is crucial to understand the benefits of each UML diagram. It will help in understanding modeling and the cases from it.

This blog post goes over eight types of UML diagrams and how each diagram is used for modeling. So basically, UML is a set of standardized (Unified) diagrams that offers different views of the same system from construction (front elevation, electrical diagram, floor plan, etc.). The first and simplest one is the class diagram and it describes the structure of a system by showing the system’s classes, their attributes and the relationships among these classes. It is also a static structure which shows what interacts but not what happens when the classes interact. Second and third one is the component and deployment diagrams. Both diagrams in many cases are combined into one as component diagrams depict how the various components of a system and show the dependencies among them and then deployment diagrams show how they interact. For package diagram, it can be used to obtain an overview of a large system and the choose to display the individual classes inside the packages. Next is the state diagram which describes the behavior of a system where it shows all the possible states an object can get into. The sixth one, object diagram, is a static snapshot of a dynamic view that depicts a complete or partial view of the system at a specific time. For sequence diagram, it displays the sequence of events between entities of the system to show the dynamic view of the system. Finally, for the activity diagram, it is used to describe the sequencing of activities, actions, choices and system’s logic and will help with complexity.

Based on the contents of this blog, I would say that it was worth to read about. The author was on point with giving introductions to what is an UML diagram, definitions that are basic and good reminders to each diagram, and showing the implications when it is essential to know. What I try to understand the UML diagrams before is using the diagrams I do know such as flow charts. Using the diagrams, I would try to solve construction problems for example from the logic of it.

What I learned from this blog of UML diagrams is that while each of the diagrams has its uses, only use one style for something specific. The idea I got from this blog is that developers should try to find the right UML diagram that is essential to the design and not cause confusion from it.  For future practice, I should try to use the sequence diagram a lot more than the other seven diagrams because it benefits in organization for the overall structure and has a flow that is easy to understand.

Link to the blog: http://mohamedelgendy.com/blog/business-analysis/business-process-modeling.html

3 Principles that makes a developer’s life easier

So for this week, I have decided to read another blog and that is “3 Principles to simplify your life as a developer” from the iTexico Blog. The reason I have chosen to read this blog is because I usually do not get a clear grasp of these kinds of principles. With getting a clear understanding of these principles, they will help in applying code, simplicity, and managing the overall process.

As the title applies, this blog post basically goes over 3 principles that are basic but powerful that will make life as developers easier and they are KISS, YAGNI, and DRY. The first principle KISS stands for Keep It Simple, Stupid and the meaning of it is straightforward. The simpler the code is, the simpler it will be easier to maintain in the future. This means that according to the author’s advice, developers should avoid using fancy features from the programming language they are having it in on. It does not mean developers should not use these features, it is to say only use them when there are perceptible benefits to solving a problem. Second principle YAGNI stands for You Aren’t Gonna Need It and the meaning is rather related to programming the first time. We do not want to waste time coding extra features that might not fit to what is needed or in the worst-case scenario, it will not be used. So from the author’s advice, when there is an unexplained anxiety to code extra features, take a deep breath and see the pending work at the moment. The third principle DRY stands Don’t Repeat Yourself and the meaning is clear to understand. We must try to maintain the behavior of a functionality of the system in a single piece of code. This means to keep it in a steady pace to avoid redundancy.

Based on the contents of this blog, like the concept of KISS, I would say this was simple and easy to read. The author gave the meaning of the principle, explained the origin of it, and advice on how to apply it while programming. What I did before to try to understand these principles while coding is that I try my best to not write down a method twice or an extra class unless needed.

What I learned from this blog about the principles is that DRY should be not used all the time in the life as a developer. The idea I got from this blog is that while DRY is a good principle to follow, it will sometimes when violated lead to a solution which is called WET or Write Everything Twice and that is a bit of time spent. For future practice, I should try to apply the KISS and YAGNI principles a bit more while writing down code as it will not only save from being overwhelmed on how the code works but also others that can benefit from it.

Link to the blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

Approaching Complex Code

So for this week, I have decided to read “Code Smells: Too Many Problems” from the Jet Brains and Intellij Idea blog. The reason I have chosen this blog is because while I have my experience of parsing codes, I do need another way to approach complexity. It will help in figuring out the simplest step to take first when there is complexity in coding and not be overwhelmed by it.

This blog post basically goes over three approaches that is figuring out how to tackle complex code. Each of the approaches have their pros and cons. The first approach is simple but effective to do and that is break down the method into smaller sessions. While it might help for methods with multi responsibilities, it does not make some other smells more approachable to work with. However, it also does help in determining when is the right time to refactor.  Second approach is to work on one smell at a time. It is a variety of steps that the author has showed to get this point for the series of code smells. This is the less risky and easier to reason approach that gives simpler code. The third approach is to step back and try to model the problem. Instead of looking at individual smells or individual lines of code, this approach introduces new domain objects to model what is happening in the code. It encourages a bit of redesign and may lead to new classes that can help with other areas of code, but be aware that it will have the same problems as the other two approaches if not used carefully.

Based on the contents of this blog, I would say this was a pleasant read on getting started in tackling complex code. The author was able to show how the approaches work with a sample code and addressed the drawbacks from it. It was easy to understand and has the What I did to getting started is to write down one method at a time and try to refactor it based on the design it has been used on. Sometimes I would try to write down comments if I do need to have a clear reminder of what I’m trying to do while refactoring.

What I learned from this blog is that if breaking down the methods and refactoring happens to lead to an inconvenient end, then perhaps undoing a few steps back is not a bad idea. The idea I have gotten from this blog is that all the tests should pass, and commits should be small, but very frequent. This helps in making sure that it is easy to stay back and not having to be in a place that can lead to a complete halt. For future practice, I shall try to use the rule of three that will help in determining if a method is needed to be broken down into smaller pieces.

Link to the blog: https://blog.jetbrains.com/idea/2017/09/code-smells-too-many-problems/

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/

First post to the class CS-343

Hello my name is Dennis Tran. This is my test blog for CS-343. Here is my blog for this class and I look forward to working my way to a great experience.