Category Archives: Week-16


For this week’s blog post, I have found an article about encapsulation. Encapsulation is more than defining accessor and mutator methods. It also follows two main objectives hiding complexity and hiding the sources of change. To understand more about encapsulation, we will first need to understand the two concepts of modularity and abstraction. In the article, Edwin Dalorzo, the author of the article, uses the example of a car to understand abstraction. He says on this, “A car is complex in its internal working. They have several subsystems, like the transmission system, the break system, the fuel system, etc. However, we have simplified its abstraction, … we know that all cars have a steering wheel through which we control direction, they have a pedal that when we press it we accelerate the car and control speed, … These features constitute the public interface of the car abstraction” (Edwin Dalorzo). This is a great example because we can use abstraction to simplify unnecessary parts that the users would not need to understand. This concept is similar to modularity. In his book Code Complete, Steve McConnell said on complexity “ the interface should reveal as little possible about its inner workings”. So now that we understand the two concepts, the idea of encapsulation starts to unravel.

One of the things that we want to always encapsulate in Java is the state of a class. This should only be accessed through its public interface. Edwin says on encapsulation in Java, “In a object-oriented programming language like Java, we achieve encapsulation by hiding details using the accessibility modifiers … With these levels of accessibility we control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes, subclasses, etc.).” (Edwin Dalorzo).  It is crucial that we keep this idea in mind while we design encapsulation for these public interfaces so that we can foster evolution of our APIs.

As talked about in the article, it is often wondered why we need to use accessor and mutator methods in Java, aka getters and setters. With encapsulation in mind, it is not there to hide the data itself but the implementation details on how the data is being manipulated. So once again we would need a public interface to gain access to this data. However, by exposing this data we risk losing encapsulation. So this is why we would need to encapsulate this information.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Blog #7: Hierarchies

I have already written two separate blog posts on the topic of Class Diagrams (UML and ER) so it only seems right that I revisit how they relate to hierarchies in programming. During this semester, we transitions from UML Class Diagrams into hierarchies with class assignments and a homework project about ducks. The fact that the assignment was based on a program about ducks sounds funny, but it was actually a great example to work with for learning hierarchies better. Some ducks can fly, swim, quack, or squeak depending on the type of duck (including rubber ducks etc.). This is perfect because although all the duck types are considered “ducks,” they all cannot do the same things. This means that programming classes for the different ducks was extremely efficient if it had a good hierarchy for the classes. Rather than hard-programming what every duck could do one at a time, the hierarchy allows the programmer to write much less (as well as have a much easier time adding or deleting duck types). Obviously since all the ducks where considered “ducks” the main class we had to write was just the duck class. Every other class extended off this class and inherited functions from that class. If some ducks shared similar actions and properties, then they would be grouped together under another class and so on. This often creates a web/tree shape if the program where to be drawn out in a diagram. I have learned about hierarchies and their benefits and importance before this semester, but revisiting it is always good for me, especially since I have a bad habit of trying to hard-program things if I am not getting the hierarchy to work the way I want it to. For this post, I did not use a link, but I certainly would still recommend looking around the internet or in books to find all the information about this very important topic of computer programming. All of the studying, researching, and practicing is valuable!

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

Rubbing Elbows

Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

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.

Sweep the Floor

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

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.

Create Feedback Loops

This pattern discusses the need to have good, quality feedback to allow for personal growth. Often times, the only form of feedback is coming from ourselves and what we have done. As discussed in the article, this can often cause our reflection and feedback to be skewed and biased. If you are on a very good team, it can cause you to either ride their coattails and feel more prepared than you are in reality or cause you to become overwhelmed and feel as if you know nothing. On the other side of the spectrum if you are on a bad team, it can cause you to become complacent because you are able to succeed easily on this team.

The way that this pattern offers a solution to this common problem is to be able to develop a test of actual tangible data that will allow for an honest form of feedback. For example, if you are in team but writing your own portion of code, have another teammate peer review your code. By having another pair of eyes on your own code, they will be able to pick up and point out portions of code that are bad, messy etc. that you would usually gloss over because it was how you had always done it. In a similar manner, if you have any supervisors or managers above you it is always a good idea to be asking for feedback from them. This will not only help you improve your abilities but will also show them that you have initiative to improve yourself.

I believe that this type of feedback is very important to get. Many times, people can become too complacent with their own skills and not try to improve or gain more knowledge. This has happened to me and the main reason I was able to realize my complacency was by working in a group project. By constantly collaborating with them it was easy to see my strengths and weakness and what needed to be worked on. By having the group give feed back and documenting the project as you go, allowed for you to see your progress in a tangible sense.

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

Concrete Skills

This pattern begins by discussing the desire to get into the software development field with the drawback that often times managers or HR won’t hire without experience. To be able to show that you can become an effective member of the team, you need to be able to translate all of the knowledge gained previously into concrete skills. A good way to show these concrete skills is the capability to demonstrate that you would be able to make an immediate positive impact to the team, even if that impact is something very basic. By showing these concrete skills, it will give you a leg up on the competition when hiring.  HR is already taking a chance on you; it is best to show that it will not be for nothing and you are at least capable of something beneficial.

The way to go about this that the article discusses is by going through CVs or anything that shows the concrete skills that well-respected professionals list about them. Then find which one(s) of the skills are applicable to whatever team you are trying to join. From there, work on being able to demonstrate that skill as a concrete ability, whether it be by doing a pet project or simply practicing that over and over.

I believe that this pattern is something very important to learn. As someone who is just getting started into the software field, it can often be hard to even get a foot in the door for some companies. When you finally are able to get in the door, it is absolutely essential that you show that it was not a waste of time. The most successful interviews I have had was when I was put in front of a team leader who wanted me to demonstrate certain skills that would be able to help them immediately. Often times it is simple problems that are needed to be shown, but it is very important to show that you not only understand the problem but are able to apply the solution. A hiring manager is far more likely to “take a chance” on you if they think you’ll be able to immediately have useful, applicable skills for the team.

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

Early Testing


This week I read the post from the site linked above. It talks about effective quality assurance strategy in the early stages of a project. Uncaught bugs or fundamental flaws in the foundations of the software life cycle can result in setbacks for the later stages. Ultimately, it is more efficient to test early and test often than to spend resources going back to fix an early issue. If this is the case, sometimes the best solution is to rewrite many built features of a software project just to change the foundation, which is the worst case scenario in a time crunch environment.

There is a balance to be achieved between spending enough time testing early as to not create fundamental mistakes, and spending too much time testing without devoting enough resources to producing a working prototype. Software projects are typically planned on a time based release quarterly, half-yearly, or yearly, depending on the size of the project and the goals in mind. Because time is of the essence, defects need to be organized based on severity, time allocation, and expected collateral impact for the rest of the code.

This cycle can be broken down into steps; the developer creates, the tester tests the creation and ranks severity, the developer responds by fixing the most important issues, and the tester evaluates the fixes. Ultimately, this cycle never ends as long as they are employed. Constantly, there are new features and new bugs, and it is impossible to discover every bug from every new feature, the product is never defect free. In this way, testing is especially important in the early stages of development since it plays better into the long term which we expect to never end.

Now that I’ve summarized why and how early testing occurs, the final segment of the site reviews the primary targets for early testing. To begin, stakeholders determine which features will be the most effective by generating the most revenue, complying with standards, catching up to a competitor, or succeeding a competitor. These selected new features are the focus of early testing since they usually involve many lines of code with a high possibility of intersection. QA and development leaders both need to work together when working on these high priority features in the early stages of development. This collaboration must be stressed as especially important to the work efficiency of the entire project.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Software Testing Principles

I am writing in response to the blog post at titled “7 Software Testing Principles: Learn with Examples”.

This blog post highlights some useful general guidelines for software testing. In order to write effective test cases, it is important to follow some logical approach toward determining what to test for and how to test it, and this is a guide that describes such a set of principles to follow that are well suited to capture the logic involved in software testing.

The first principle is that exhaustive testing is not possible. I am not sure I believe this. In general it is useful to assume there exists no perfect test, but for simple enough applications where the number of possible interactions are enumerable, I would think that it would be possible to achieve exhaustive testing, much like an exhaustive proof, where every possible path is covered and verified. Maybe I am missing the implausible event that the test is correct but the computer running the tests is corrupted in such a way that certain tests are not run. This is relevant to a point made in this area, which is risk assessment.

The second and third principles make similar points. Always running the same tests will eventually not cover certain issues. If all of the same methods for testing are always applied exactly the same, then eventually there will be some scenario which the particular method is not suited for, and it will miss something. This leads into the later principles: the absence of a failure is not proof of success, and context is important. Developing tests suited for the particular application is necessary to ensure the correlation between tests passing and the program functioning correctly, and just because every test passed does not mean the program is going to work perfectly.

This set of software testing principles can be summarized in a few basic points. Develop test cases that are well suited specifically for the application that is being tested, consider the risk of certain operations causing a failure, and do not assume that everything works perfectly just because every test case passed.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Mocking & Mockito

For the final blog entry for this class, I decided to cover a topic that I’ve had personal experience with but wanted to review for further review and understanding, mocking and specifically, mockito. I found an article on by Ivan Pavlov about mockito that is a guide for everyday use of the tool, exactly what I was looking for! The article has sections that includes some in depth analysis that could likely be used as a more in depth documentation for several aspects of mockito. The article also includes some insight into what mocks and spies are in the context of testing, unit testing specifically as well as some examples of the mockito tool in action.

For unit tests, we are testing the smallest unit of code possible for validity. The article states that the dependencies are not actually needed because we can create empty implementations of an interface for specific scenarios known as stubs. A stub is another kind of test double, along with mocks and spies, which are the two test doubles relevant to mockito. According to the article “mocking for unit testing is when you create an object that implements the behavior of areal subsystem in controlled ways.” They basically serve as a replacement for a dependency in a unit test. Mockito is used to create mocks, where you can tell mockito what you want to do when a method is called on a mocked object.

A spy for unit testing is another test double used by mockito. A spy, unlike a mock, requires a non-mocked instance to “spy on”. The spy “delegates all method calls to the real object and records what method was called and with what parameters”. It works as you would expect a spy to, it spies on the instance.  In general, mocks are more useful than the spy as they require no real implementation of the dependency as the spy does. The spy is also an indicator that a class is doing too much, “thus violating the single responsibility principle” of clean code.

Mocking with mockito can be used in a situation where you want to test that an object is being assigned a specific value when a method is called on it and certain parameters are met. A mock does not require the implementation of the methods to be written yet as you can assign values when a method is called by the power of mockito. This is why mockito is such a popular testing tool and mocking is such a popular testing strategy, and why I’ll continue to utilize it whenever relevant.

Link to original article:


From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Boundary Value Testing

For this week’s blog post, I wanted to cover a topic that we covered earlier this semester, boundary value testing. I found an article on seemingly my go to site for articles for this blog, guru99. The article has several sections including a brief definition on what boundary testing is, as well as a definition of what equivalent class partitioning is and the relationship between the two. There are also a couple of examples and an analysis section that explains why we should use equivalence and boundary testing.

The article describes boundary testing as “the process of testing between extreme ends of boundaries between partitions of the input values.” These extreme values include the lower and upper bounds, or the minimum and maximum acceptable values for a given variable. For boundary testing, you need more than just the minimum and maximum values though. For the actual testing, you need a value that is just above the minimum, a nominal value that lies somewhere in the middle of the range, and a value that is just below the maximum value.

Equivalent class partitioning is explained by the article as “a black box technique (code is not visible to tester) which can be applied to all levels of testing.” It also states that when using equivalent class partitioning, “you divide the set of test condition into a partition that can be considered the same”.  This may sound a bit confusing but it is actually pretty simple. The article uses an example of a ticket system where values 1-10 are the only acceptable values and values 11-99 are invalid. You could break up this set of numbers into two different equivalent class partitions and then returning back to our boundary testing concept, we would test values like 0, 1, 5, 9, and 10.

The best part about boundary testing is that because it is a form of black box testing, you do not need to see how the actual code works. You only need to know the specifications for the valid and invalid numbers. Another reason to use boundary testing is that it eliminates the need for testing every value and thus, minimizes the tests needed. I have and will continue to utilize this testing strategy throughout my software engineering career.

Link to original article:


From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.