After reading and doing factory pattern design, I was still not sure why we used it and its purpose in a code; I decided to do in-depth reading and also post this blog to outline the main ideas gotten from this reading.

First of all, what is refactoring? Refactoring is a name given to a collection of small individual learning techniques for improving code that has already exit. It implies the code has already been written, it is working and you are not changing it functionality. The purpose of refactoring is not to break down code and rebuild it. It is to improve on the exiting code for more clarity.

Again, what do we get for refactoring code? Refactoring is used to improve code design to make it easy to understand and extensible.

Besides, Refactoring also makes it easy and quicker to create complicated systems.

Refactoring makes code easy to read and eliminate duplication and make modification easy and minimizes complex conditional logic.

Refactoring removes excess code so that it is easier to understand and modify.

In other words, one of the main objectives of refactoring is to remove bad smell. Bad smells are common design problem and they are usually unclear, complicated or duplicated.

behavioral vs Structural Testing

Behavioral vs. Structural testing

After thoroughly reading of the chapter with the level of testing, I have seen the important of one understanding the difference types of testing, how to use them and more importantly what time or stages you are required to use a particular technique. In this regards, I am writing this blog to basically outline the major differences between behavioral testing and structural testing techniques. In my earlier postings for the level of testing, I tried to capture all the testing techniques. I have also talk of dynamic verse the static testing and it is now time to look at behavioral and structural testing in comparative perspective.

Both structural and behavioral testing techniques are used to ensure adequate testing.

First and foremost, Behavioral testing which is also known as functional testing is a kind of testing where the functionality of a software is been tested. This type of testing is often referred to as black box testing. Functional testing basically is test that happens during implementing requirements and design specification.

Also, Functional testing usually cares about only the results but not processing because the tester does not have to know anything about the code or program.

Structural testing however is a testing technique which is based on the internal structure of the program or code. Structural testing basically analyses the code to verify if there are errors in the design process. Structural testing which is often called white box testing is concern with both the result and process because knowledge of the code is very important; we need to understand the design code. This is a stage where design requirements and algorithm are discussed. White box testing technique often get work done and can be run every time part of the code changes, allowing issues to be resolved as quickly as possible.

The main objective of the structural testing technique is to ensure that the functionality of the code is as required and the design is readily acceptable to be implemented in the real world.

Again, I am inspired a lot reading this chapter and writing this blogs as they enables me to do in-depth reading into the topics and more to the point understand the various levels of testing, their unique terminologies and differences as a whole. I know very well that I did not only understands how and when to use a particular testing technique but it is also going to help me save time in my future testing as I will know in the fly which technique to use.




Static vs Dynamic Testing

Static vs Dynamic Testing

Static testing is done on a non-executable code. In this testing we try to find errors, code flaws and potential malicious code in the software application. Thus in static testing, code is not executed; it manually checks the requirement documents and the design documents to find error. There are three basic techniques in static testing.

First of all is the review stage which has two forms; the informal review which is conducted between colleagues and contemporaries. Peer-to-peer review is considered as informal. In informal review, no official communication or records is needed conduct it. Formal review in the other hand is done after informal review is over and the review is conducted through an official communication and official records are maintained.

Secondly, walkthrough technique is also a type of review which process might take place in the internal team or with the client at pre-fixed time. Walkthrough review can be done on a daily, weekly or monthly basis. This technique does not need to send an official communication but need to maintain official records.

Thirdly, inspection technique is basically a kind of review but the inspections are generally done by a third party company. These third party companies is called independence verification and validation (IV&V) and are hired by the internal team in conjunction with the client to do an unbiased review of the documents or processes followed in the company. And obviously, for inspection to be carried out, since it involves the service of a third party, you will need an official communication and official records.

In a dynamic testing, the code is required to be in a functional and executable form. This is because you will have both functional and non-functional testing in a dynamic testing technique where testing is carried out with executing code. This comes under validation.

In summary, under these two techniques, we have review, walkthrough and inspection under static technique. Under dynamic, we have experience based, structural and behavioral categories which further have  techniques such as exploratory, random testing error guessing for experience based, symbolic execution, definition use etc, for structural and equivalences, boundary value, cause and effect, usability and random state under behavioral categories.

I chose to explore these testing understanding them as I could not differentiate the two after reading the chapter in the first place. And after my in-depth research into the topic, I can proudly explain how the two testing techniques are conducted and their key differences, which I believe is going to help me a lot in my future code testing.




Factory design pattern

Factory Design Pattern

To begin exploring Factory design pattern, first of all, we need to know what factories are. Factories are simply functions that create objects and return them. In most cases you can use factories to design to code instead of classes, and they are much simpler and more readable than classes.

Even though classes have a lot of better performance, it is a good idea to use factories unless otherwise you are in a situation that requires you to instantiates many objects.  For example, factories will take averagely 0.0004 milliseconds to create an object in most case while class will take 0.0002 milliseconds to create an object; classes will reduce the time to half way as compare to factories. This comes to matter when you are creating about thousands of classes but when your classes are not that much you will never notice the difference and hence, will not be necessary.

Why do we need factory design pattern?  Now let think of it this way; in our codes, we uses a lot of objects. We have classes that instantiate object from class and we use them in many difference ways. In a strategy pattern, we use dependency injection where we imagine ahead of time what the objects will be doing. But at some point in our programming, that imagination has to be constructed. That is we need to instantiate our objects and the question is, where do we do that? This is what factory pattern try to address. In this regards, we say, when you are about to instantiate, let encapsulate them such that it span uniformly across all places so that you can use factory whenever you want to instantiate and the factory is responsible for instantiating appropriately.

Factory pattern gives you the ability to create objects without specifying the exact class of object that will be created; a class is chosen at run time using polymorphism.

For the matter, one will want to use factory pattern design when a method returns one of several possible classes that share a common super class. It is also a good idea to use factory design pattern to design your code when you do not know ahead of time what class object you will need. It is again useful when all of the potential classes are in the same subclass hierarchy and when you do not want the user to have to know every subclass in your code.

I chose to explore this topic as because I was unable to understand it on the go when we were treating it in class and I also got confused as to which pattern to use for my upcoming project and I decided to write this blog on factory pattern because I am impressed how you can use factories instead of classes to provide a clear code. I am actually redesigning my previous code using the factory pattern and I can figure out that everything looks simple at this point.


Reference: https://airbrake.io/blog/design-patterns/factory



Testing is very important to the development of a successful program. Without testing, there would not be any guarantee that a particular designed code would fulfill it design purpose. There are basically four level f testing namely Unit Testing, Integration Testing, System Testing and Acceptance Testing. I chose to explore and elaborate on these because we have just starting treating those topics in class starting with the Unit Testing. Due to time constraint, I would be describing the four levels of testing in a briefly manner as follows;

Unit Testing: Unit testing is done by programmers on a particular functions or code modules. White-box testing method is used to achieve this task.  Considering a code as a bulk program, unit testing will deal with each pieces of the code that comes together to form the code and make sure that each section of the code passes the test.  In this regards, it is easy to figure out which part of your code have a problem and solutions to non-functioning section of the code can be easily resolved. Sections of code can be testing on the go as they are created rather than wait till the end which might give you hard time figuring problem. Unit testing requires the knowledge of the internal program design and code.

Integration Testing: Integration testing is done after unit testing and it is a testing of combined parts of an application to determine their functional correctness. Unlike the unit testing which test individual pieces of the code, Integration testing gives you the opportunity to gather all the pieces or sections and test them as a group. This will enable you to determine how efficiently all the unit of your code is working together or to technically verify proper interfaces between modules and sub systems.

System Testing: System testing ensures that the system is in line with all the requirements and has meets the quality standards as well the code design purposes. It is the first level of testing the whole code or program to make sure the entire program is working as one unit. System test is often done by an individual who is not part of the developing group and it is very necessary because it ensures the program or code is meets the technical, functional and business requirements that they were tasked to design.

Acceptance Testing: Acceptance testing is related to the user and is designed for the user to test the system to see if it meets their standard. In other words, it is to verify that the system meets the user requirements. In this stage of testing, if nothing changes and the software passes, the program will be delivered to the entity they that need it and the programmers work is done.

It is important for one to note that all these levels of testing are done progressively from unit testing to acceptance testing. I have come to note that I cannot jump to acceptance testing without first doing the unit, integration and system testing. This is going to have a great impact in my career as I have now known and understand clearly how the testing is done.

References: https://www.seguetech.com/the-four-levels-of-software-testing/



Software Design Patterns

Software Design Patterns

Depending on the type of project you are designing, there will always be a need to adopt a particular pattern that clearly represents your design. There are many design patterns that a programmer can rely on to present his or her project. For the purpose of studies, I will be exploring and discussion the three most useful design patterns categories. Thus creational design pattern, structural design pattern and Behavioral design pattern. Below is a brief description of each pattern.

Creational Design pattern: This type of design create object as needed within a code and allows for abstract factory which group objects of similar functionality. This also uses polymorphism to allow one object to inherit multiple behaviors within a method. In this pattern, you do not need to declare the exact class or type because polymorphism is used at the end to assign behavior. Usually, an abstract prototype is created and the base classes that inherit it are defined.

Structural Design pattern: Structural patterns deals largely with composition of classes and object by using inheritance and interfaces to enable objects to gives out new functionality. It often has an abstract class which uses method signatures and behaviors for the classes that will implement the interfaces. In structural patterns, objects are group according to their behavior and what they inherit. Also, modifications of object are done before finalizing your code.

Behavioral Design pattern: This is a type of pattern that allows for the behavior of a class to change base on it current state; even though, these states are always changed in the entire programming, implementation of each state is defined by a unique interface. It also allows for new operations to be added to an object without having to modify its original implementation structure.

In general, when you are talking about code responsibility, you really want to have your methods to your classes do one thing and do it well. Bringing it to real life example, it is like texting and driving; there is no way to achieve both effectively at the same time. You are either going to be driving off the road while texting well or driving well and not texting regularly. This implies, having your code do two or more things will make it do one thing well and do badly with the rest. Also, changing one thing on base class might have side effect on the other too. In this case, as a designer, you will want to extend your classes rather than modifying them. Even though you will have more classes created in order to have them do one thing, it is worth doing that because it will provide a clear presentation of your code. This is going to help me a lot in the future because I am going to adopt having classes of my code perform one task which will provides higher efficiency.




Limitations of Inheritance and how to solve them using composition

In java, you can use one type as template of making another type. The new type can inherit all the same behavior as the original type. This is known as inheritance. Java class inheritance allows you to reuse existing type functionality and let you make modification in behaviors as it fit. Inheritance in the other words is when you design your classes by what they are rather than what they do. This is also term as “Is-a relationship” which sometimes can be misleading. For example, an SUV car or Sedan car can inherit the supper class base Car/ Vehicle on the “Is a relationship” functionality. The same time, it could be implemented based on the “Has- a relationship” functionality because, a car has a tire, break, engine etc. so when it comes to determining which one to implement, this becomes a little bit confusing. This seems to be very bad to me because the sub classes are base on the super or base classes and when something accidentally changes from the base classes, it automatically affects the sub classes.

Composition in the other hand is a design technique use to implement has-a relationship in classes unlike an inheritance which is an “IS A” relationship classes. Composition is basically designing the class base on what they do. According to Wikipedia, composition is a principle that classes achieve polymorphic behavior and code reuse by containing instances of other classes that implement the desired functionality rather than inheriting from the base or parent class.

Again, in composition, we can control the visibility of other objects to the client classes and reuse only what we need.

In general, composition is has-a relationship between objects, it is implemented using instance variables, code can be reused, it hide visibility to client classes and more importantly is it flexible to use.

Now, what do I learn from this study? I have come to learn that implementation of composition over inheritance basically start with the creation of various interfaces representing the behaviors that the code will perform.

I have also learn that inheritance will not only encourage you to go predicting the future which may or may not work but it also encourages you to built the branches of object very early in the project and you are likely to make a very big design mistake whiles doing that because we cannot predict the future even though we feel like we could. To me, inheritance is very bad way of designing classes as sub classes may inherit some functionalities from the supper classes which will never been used but cannot do away with it. With regards, I do not see myself designing a projects using inheritance unless for educational purpose project that will explicitly require me to use of inheritance. I will always go for composition when designing project with multiple functionalities.