Template Design Pattern

For my blog this week I choose to write to about the template design pattern. Picked it because I was recently learning about what design patterns were. So I was google and and came along a list of different ones and I liked the template design pattern because it seemed to be useful and fairly simple so I picked it.

The article first talks about how the template design pattern is used for the base of an algorithm where the steps always happen in the same order and sometimes some or none of them are the same most of the time. Then they talked about an example of an algorithm to build a house were the steps are always first to build the foundation then to build the pillars. Next to build the walls and last to build the windows. They also said that these have to built in the same order every time. Then they started talking about the first class which was an abstract template with the first method being a method to build the house which its self called all of the other steps in the process which were abstract methods. They also said the since the method to build the house was the algorithm to build the house it should be final so it cant be changed. They also you leave the step methods unimplemented or not if they are mostly going to be the same. Then for each type of house you create a new class to build it extending the template class while overriding the unimplemented methods or any methods you need to change.

This design pattern helps with the repetition of having to type the algorithm over and over for each subsequent class you make. It also lets you make reuse so of the steps if they never change. It does have some disadvantages though like how you cant change the order of the main algorithm and that you have to override most of the methods everything. So even if several of the implementations use the same step you still have to rewrite them anyway. I learned a lot from this article first of all I learned a completely new type of design pattern. I think this pattern is very useful especially with algorithms as they said. I also learned just by looking at the list on the website that were far more types of design patterns then I originally thought.

Template Method Design Pattern in Java

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Getting a solid grasp of SOLID

For this week’s blog, I have decided to go over the SOLID set of design principles. The blog article “SOLID design principles: Building stable and flexible systems” by Anna Monus describes SOLID and gives solid examples of each design principle with code and UML diagrams.

Single responsibility

Each class should only have a
single responsibility, such as handling data or executing logic. While this
increases the number of classes in a program, this will allow easier
modification of the code and code clarity.

Open/Closed

Classes should be open to extension
and closed to modification. This means that new features should be introduced
through extension and not through modifying existing code. The open/closed
principle allows programs to expand with new features without breaking the old.

Liskov substitution

Named for its creator Barbara
Liskov, the Liskov substitution principle states that a subclass should be able
to replace its superclass without breaking the properties of the program. This
means that a subclass shouldn’t change its superclass’ characteristics, such as
return types. Following this principle will allow anything that depends on the
parent class to use the subclass as well.

Interface segregation

Interface segregation states that
classes should not have to implement unused methods from an interface. The
solution is to divide the interface so that classes can implement only the
desired methods. I found this principle to be easier understood from a visual
example and I found the article’s UML diagram for interface segregation useful
for this.

Dependency inversion

High and low-level modules should
depend on abstractions. It is common to think that high-level classes should
depend on low-level classes, but this makes expanding the code difficult so
it’s best to have a level of abstraction between the two levels. The article’s
UML example for this principle shows how the abstraction level allows for easy
expansion.

The SOLID principles are important for code architecture as
it makes code expansion simple and easy to understand. I have found myself
applying SOLID principles to a project I have been playing with, a simple GUI
animation. Originally, I had drawn objects handling their own draw and movement
methods, but by using the single responsibility principle I separated the
movement-based code to its own class and used composition between classes. This
allowed for me to be able to use the movement code (contains position,
velocity, and acceleration values and methods) for all the different objects
that I make. I also made use of the O, L, and D of SOLID to handle the drawn
object hierarchy allowing my frame class to depend on an abstraction of all my
drawn objects. I use a loop to cycle through all drawn objects in a linked list
that’s type is an abstraction of all drawn objects. I can tell that the
structure of the code has made adding new functionality easy and intuitive.

Article Link:         https://raygun.com/blog/solid-design-principles/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Gradle: Test test

Testing Testing Testing… A few weeks ago we focused on JUnit testing using Gradle. I thought I would share a few things I learned along the way getting my projects setup for JUnit testing with Gradle. Since our testing is centered around Jupiter (JUnit5) there are a few unique things you need to do to get Gradle to behave as expected. If you are using Jupiter for your JUnit testing you need to have Gradle version 4.6 or later installed. So let’s start there. Verify the version of Gradle you have installed: Open a bash shell in your projects root directory and run: ./gradlew –version If you are not running a version greater than 4.6 update to the latest version before proceeding. Let’s setup our project to use Gradle. Open a bash shell in your projects root folder and run this: gradle init –type java-library –dsl groovy –test-framework junit This tells Gradle that we are creating a new JAVA project and that we will be testing with JUnit. It will take a few seconds to run and once complete you should see a message that says: BUILD SUCCESSFUL in xxseconds 2 actionable tasks: 2 executed Now check out your project folder. You will now see 3 new folders: gradle .gradle src and the following new files: .gitignore build.gradle gradlew gradlew.bat settings.gradle We are going to start off making changes to the build.gradle file. Using your favorite editor (I prefer Notepad++)open build.gradle and verify that the following is your frist entry following the commented docs: 1 plugins { 2 // Apply the java-library plugin to add support for Java Library 3 id ‘java-library’ 4 } This tells Gradle that it is going to be building a JAVA program. Now we need to make sure that Gradle gets the required and dependencies so add the following to build.gradle: 20 dependencies { 21 // This dependency is exported to consumers, that is to say found on their compile classpath. 22 api ‘org.apache.commons:commons-math3:3.6.1’ 24 // This dependency is used internally, and not exposed to consumers on their own compile classpath. 25 implementation ‘com.google.guava:guava:27.0.1-jre’ 26 // Use JUnit test framework 27 testImplementation ‘junit:junit:4.12’ 28 testImplementation ‘org.junit.jupiter:junit-jupiter-api:5.5.0-M1’ 29 testRuntimeOnly ‘org.junit.jupiter:junit-jupiter-engine:5.5.0-M1’ 30 } We tell build.gradle which frameworks to include for the JUnit testing. Jupiter is backwards compatible but if we want to run any JUnit 4 test we include that junit:4.12 dependency. This just ensure the correct flavor of JUnit is used for the testing. Now we’ll add one more line to our build.gradle to make sure we enable Gradle’s native JUnit 5 support. Add the following lines after the dependencies: 33 test { 34 useJUnitPlatform() 35 } Now hop back into your IDE and work on your project. Save all of your changes and navigate back to your project folder. Open up the src folder. You will see the following sub-folders: main test Both of these contain a folder called java. You will move your JAVA files into the java folders in the main and test subfolders. EXAMPLE: Let’s say I am working a project that has Duck.java , Pond.java , and DuckTest.java. Both Duck.java and Pond.java should be moved to ../src/main/java and DuckTest.java would be moved to ../src/test/java Once you’ve moved your files into the correct location run this in your bash shell: gradle build Once this succeeds run this in your bash shell: gradle test Once this finishes and you get a success message navigate to your project folder and go to /build/reports/tests/test/ and open up the index.html. This will give you a breakdown of how your gradle test went. Now that you’ve sucessfully setup Gradle you need to go back into your IDE and clean up your projects paths so that you are working in the src/main/java folder and the src/test/java folder. See easey peasey lemon squeezy! Next week we’ll go over how to intigrate our projects with GitLab so that GitLab does the testing for us. In the meantime checkout the docs up on Gradle.org related to testing with JAVA & JVM: https://docs.gradle.org/5.2.1/userguide/java_testing.html#using_junit5 #CS@Worcester #CS443

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Gradle: Test test

Testing Testing Testing… A few weeks ago we focused on JUnit testing using Gradle. I thought I would share a few things I learned along the way getting my projects setup for JUnit testing with Gradle. Since our testing is centered around Jupiter (JUnit5) there are a few unique things you need to do to get Gradle to behave as expected. If you are using Jupiter for your JUnit testing you need to have Gradle version 4.6 or later installed. So let’s start there. Verify the version of Gradle you have installed: Open a bash shell in your projects root directory and run: ./gradlew –version If you are not running a version greater than 4.6 update to the latest version before proceeding. Let’s setup our project to use Gradle. Open a bash shell in your projects root folder and run this: gradle init –type java-library –dsl groovy –test-framework junit This tells Gradle that we are creating a new JAVA project and that we will be testing with JUnit. It will take a few seconds to run and once complete you should see a message that says: BUILD SUCCESSFUL in xxseconds 2 actionable tasks: 2 executed Now check out your project folder. You will now see 3 new folders: gradle .gradle src and the following new files: .gitignore build.gradle gradlew gradlew.bat settings.gradle We are going to start off making changes to the build.gradle file. Using your favorite editor (I prefer Notepad++)open build.gradle and verify that the following is your frist entry following the commented docs: 1 plugins { 2 // Apply the java-library plugin to add support for Java Library 3 id ‘java-library’ 4 } This tells Gradle that it is going to be building a JAVA program. Now we need to make sure that Gradle gets the required and dependencies so add the following to build.gradle: 20 dependencies { 21 // This dependency is exported to consumers, that is to say found on their compile classpath. 22 api ‘org.apache.commons:commons-math3:3.6.1’ 24 // This dependency is used internally, and not exposed to consumers on their own compile classpath. 25 implementation ‘com.google.guava:guava:27.0.1-jre’ 26 // Use JUnit test framework 27 testImplementation ‘junit:junit:4.12’ 28 testImplementation ‘org.junit.jupiter:junit-jupiter-api:5.5.0-M1’ 29 testRuntimeOnly ‘org.junit.jupiter:junit-jupiter-engine:5.5.0-M1’ 30 } We tell build.gradle which frameworks to include for the JUnit testing. Jupiter is backwards compatible but if we want to run any JUnit 4 test we include that junit:4.12 dependency. This just ensure the correct flavor of JUnit is used for the testing. Now we’ll add one more line to our build.gradle to make sure we enable Gradle’s native JUnit 5 support. Add the following lines after the dependencies: 33 test { 34 useJUnitPlatform() 35 } Now hop back into your IDE and work on your project. Save all of your changes and navigate back to your project folder. Open up the src folder. You will see the following sub-folders: main test Both of these contain a folder called java. You will move your JAVA files into the java folders in the main and test subfolders. EXAMPLE: Let’s say I am working a project that has Duck.java , Pond.java , and DuckTest.java. Both Duck.java and Pond.java should be moved to ../src/main/java and DuckTest.java would be moved to ../src/test/java Once you’ve moved your files into the correct location run this in your bash shell: gradle build Once this succeeds run this in your bash shell: gradle test Once this finishes and you get a success message navigate to your project folder and go to /build/reports/tests/test/ and open up the index.html. This will give you a breakdown of how your gradle test went. Now that you’ve sucessfully setup Gradle you need to go back into your IDE and clean up your projects paths so that you are working in the src/main/java folder and the src/test/java folder. See easey peasey lemon squeezy! Next week we’ll go over how to intigrate our projects with GitLab so that GitLab does the testing for us. In the meantime checkout the docs up on Gradle.org related to testing with JAVA & JVM: https://docs.gradle.org/5.2.1/userguide/java_testing.html#using_junit5 #CS@Worcester #CS443

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Take a REST

What is the RESTful architecture style and what is it good
for? Well I am here to break that down for you. REST stands for representational
state transfer, and it is an interface that can be implemented in order to help
with abstracting resources. In order for a system to be considered RESTful,
they must implement 5 guiding principles. The first principle is client-server
which deals with the separation of user-interface and data storage. The next principle
is that it must be stateless, meaning when information is requested, all the information
must be present and cannot be stored on the server. The next principle of REST
is that the data must be labeled either cacheable or non-cacheable. If the
information is cacheable, it is stored on a client cache. The fourth principle
deals with having a uniform interface. The next principle is the layered system
which allows for a hierarchy of layers to implement constraints.

Now that the principles have been laid out, the next main
part of REST is the information and data it deals with. A resource in REST is
the abstraction of information. Resources can be anything containing a name from
documents, pictures, and so on. REST then uses resource identifiers to be able
to find what resource is needed. Resources contain resource representation,
which is a timestamp of the resource containing the data, metadata, and hypermedia
links. REST contains resource methods which can be used for working with the data.
Many people associate REST with HTTP methods of GET/PUT/POST/DELETE however
since REST has a uniform interface, the user will be able to decide which
resource methods to use. However, with REST you are able to utilize these HTTP
methods in order to help with resources. The most common implementation has GET
to retrieve resources, PUT to change or update a resource and POST to create a
resource. Obviously DELETE is used to delete resources.

RESTful API’s are very beneficial when working with cloud
computing and working with the web. Because REST does not store any information
between executions; is stateless, this allows for the for scaling. This also
means that the if anything fails, it will be easy to re-work since nothing was
stored on the server. This makes it particularly useful for websites as well because
a user will be able to freely interact with the website while not storing any
information with-in it. If you want to read more on REST and RESTful API, look
into these two websites.

https://restfulapi.net/

https://searchapparchitecture.techtarget.com/definition/RESTful-API

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Patterns Part Deux – A Rusty Duck

Last week we discussed some of the design patterns we’ve been studying. We shuffled those poor ducks around a lot! We did finally land on the Singleton Pattern. The Singleton restricts the instantiation of a class to one “single” instance. Also providing a single point of access to the instance. Wait, is that our new type of duck, The Singleton Duck? How would that work? Is Singleton Duck like Leisure Suit Duck? Just more aloof and dapper? Ok let’s not get carried away with the ducks. The Singleton design pattern is part of the Creational group of patterns. Design Patterns are typically broken out into three general categories: Creational patterns – these provide object creation mechanisms that promote flexibility and reuse of code. Structural patterns – these patterns show how to assemble objects and classes into larger structures while keeping the structures flexible and efficient. Behavioral patterns – these take care of effective communication and assigning responsibility between objects. What’s similar between these three categories? At their core they all promote flexibility and efficiency. Is this why we use design patterns? Well, to some degree yes. Design patterns can be thought of as tried and true solutions to common problems in software design. Over on [Refacturing.guru](https://refactoring.guru/design-patterns) they show 22 designs patterns that fall into the three categories above. Shall we dig into all 22 of them? How about, instead of me typing each one out with a description, you head on over there and check it out. One of the things I found helpful with the information on Refactoring.guru is the description and breakdown of each of the patterns. Here’s a high-level what each pattern contains from Refactoring.guru. Each pattern starts off with a description (the Intent) and has the following sections: Intent Problem Solution Real-world analogy Pseudo-code Applicability How to implement Pros and Cons Relations with other patterns The real-world analogy helped to solidify the concepts and I found the pseudo-code helpful. Sticking with Singleton pattern here is the How to Implement section from Refactoring.guru: How to Implement 1. Add a private static field to the class for storing the singleton instance. 2. Declare a public static creation method for getting the singleton instance. 3. Implement “lazy initialization” inside the static method. It should create a new object on its first call and put it into the static field. The method should always return that instance on all subsequent calls. 4. Make the constructor of the class private. The static method of the class will still be able to call the constructor, but not the other objects. 5. Go over the client code and replace all direct calls to the singleton’s constructor with calls to its static creation method. Pretty straight forward right? Knowing that these design patterns exist, not necessarily memorizing them, and understanding their benefits is a handy tool to have in your box of tricks. Which brings up next weeks topic: Utility Belt – Accessory or Fashion Necessity? Don’t forget to check out [Refacturing.guru](https://refactoring.guru/design-patterns) ! #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Patterns Part Deux – A Rusty Duck

Last week we discussed some of the design patterns we’ve been studying. We shuffled those poor ducks around a lot! We did finally land on the Singleton Pattern. The Singleton restricts the instantiation of a class to one “single” instance. Also providing a single point of access to the instance. Wait, is that our new type of duck, The Singleton Duck? How would that work? Is Singleton Duck like Leisure Suit Duck? Just more aloof and dapper? Ok let’s not get carried away with the ducks. The Singleton design pattern is part of the Creational group of patterns. Design Patterns are typically broken out into three general categories: Creational patterns – these provide object creation mechanisms that promote flexibility and reuse of code. Structural patterns – these patterns show how to assemble objects and classes into larger structures while keeping the structures flexible and efficient. Behavioral patterns – these take care of effective communication and assigning responsibility between objects. What’s similar between these three categories? At their core they all promote flexibility and efficiency. Is this why we use design patterns? Well, to some degree yes. Design patterns can be thought of as tried and true solutions to common problems in software design. Over on [Refacturing.guru](https://refactoring.guru/design-patterns) they show 22 designs patterns that fall into the three categories above. Shall we dig into all 22 of them? How about, instead of me typing each one out with a description, you head on over there and check it out. One of the things I found helpful with the information on Refactoring.guru is the description and breakdown of each of the patterns. Here’s a high-level what each pattern contains from Refactoring.guru. Each pattern starts off with a description (the Intent) and has the following sections: Intent Problem Solution Real-world analogy Pseudo-code Applicability How to implement Pros and Cons Relations with other patterns The real-world analogy helped to solidify the concepts and I found the pseudo-code helpful. Sticking with Singleton pattern here is the How to Implement section from Refactoring.guru: How to Implement 1. Add a private static field to the class for storing the singleton instance. 2. Declare a public static creation method for getting the singleton instance. 3. Implement “lazy initialization” inside the static method. It should create a new object on its first call and put it into the static field. The method should always return that instance on all subsequent calls. 4. Make the constructor of the class private. The static method of the class will still be able to call the constructor, but not the other objects. 5. Go over the client code and replace all direct calls to the singleton’s constructor with calls to its static creation method. Pretty straight forward right? Knowing that these design patterns exist, not necessarily memorizing them, and understanding their benefits is a handy tool to have in your box of tricks. Which brings up next weeks topic: Utility Belt – Accessory or Fashion Necessity? Don’t forget to check out [Refacturing.guru](https://refactoring.guru/design-patterns) ! #CS@Worcester #CS343

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Test Driven Development: Formal Trial-and-Error

Test Driven Development (TDD), like many concepts in
Computer Science, is very familiar to even newer programming students but they
lack the vocabulary to formally describe it. However, in this instance they
could probably informally name it: trail-and-error. Yes, very much like the
social sciences, computer science academics love giving existing concepts fancy
names. If we were to humor them, they would describe it in five-ish steps:

  1. Add
    test
  2. Run
    tests, check for failures
  3. Change
    code to address failures/Add another test
  4. Run
    tests again, refactor code
  5. Repeat

The TDD process comes
with some assumptions as well, one being that you are not building the system
to test while writing tests, these tests are for functionally complete
projects. As well, this technique is used to verify that code achieves some
valid outcome outlined for it, with a successful test being one that fails,
rather than “successful” tests that reveal an error as in traditional testing.
Related as well to our most recent classwork, TDD should achieve complete
coverage by testing every single line of code – which in the parlance of said
classwork would be complete node and edge coverage.

Additionally, TDD has
different levels, two to be more precise: Acceptance TDD and Developer TDD. The
first, ATDD, involves creating a test to fulfill the specifications of the
program and correcting the program as necessary to allow it to pass this test.
This testing is also known as Behavioral Driven Development. The latter, DTDD, is
usually referred to as just TDD and involves writing tests and then code to
pass them to, as mentioned before, to test functionality of all aspects of a
program.

As it relates to our coursework, the second assignment involved writing tests to test functionality based on the project specifications. While we did not modify the given program code, at least very little, we used the iterative process of writing and re-writing tests in order to verify the correct functioning of whatever method or feature we were hoping to test. In this way, the concept is very simple, though it remains to be seen if it stays that way given different code to test.

Sources:

Guru99 – Test-Driven Development

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Follow the Yellow Brick Road

Path testing peaked my interest when discussed in my CS-443 Software testing class, so I decided to dig deeper into the topic and see what others said about the testing method. I found an Article on GeeksforGeeks that focused on Path Testing. this type of testing focuses on the path of the code itself. calculating the complexity by McCabe’s Cyclomatic Complexity = E – N + 2P, where E = Number of edges in control flow graph, N = Number of vertices in control flow graph, P = Program factor. The advantages of Path Testing are reducing redundant tests, and focusing on the logic of the program.
Path testing seems to focus on the specified program and create the most appropriate test cases based on that program which in turn allows for best possible tests to be performed. Understanding code in a node graph way allows the tester to accurately understand the program and what needs to be tested and what can be tested individually or as a group. I really like the way that path testing views code because it is easy to understand and follow. Path testing, to me, is a directed path of testing that most people do without realizing it on a much simpler scale and because of its complexity calculations, it has more concrete evidence to support the style of testing.

Link to Article Referenced: https://www.geeksforgeeks.org/path-testing/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Integration Testing

Integration testing is the second step in your overall testing process. First off you will perform you Unit test, testing each individual component to see if it will pass. However, your testing process is just getting started and is not ready for a full system test. After the Unit test and before the system test you must run an integration test. This test is the process in which you combine all your units to test for any faults in the interaction between one another. Yes each individual unit might pass on its own but having them work together simultaneously in an integral part of the program. 

These are the many approaches one can take to Integration testing:

  • Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.
  • Top Down is an approach to Integration Testing where top-level units are tested first and lower level units are tested step by step after that. This approach is taken when top-down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases.
  • Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-level units step by step after that. This approach is taken when bottom-up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases.
  • Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.

I think this part of the testing process is the most interesting. Once you have individually working components it’s like making sure the puzzle pieces fit. 

Integration Testing. (2018, March 3). Retrieved from http://softwaretestingfundamentals.com/integration-testing/.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.