Cohesion is one o the most important concepts o Software design, and it’s used as a measurable factor in how strongly are software’s features related and how software’s pattern is consolidated as one frame. Modern software design strategies suggest to use cohesion as a slide ding scale instead of binary attribute as it was introduced in 1974. As … Continue reading Understanding Cohesion →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Writing Better Tests With JUnit by Tobias Goeschel

For this week’s blog, I chose “Writing Better Tests With JUnit” by Tobias Goeschel. The blog contains different tips and suggestions on how to write a better test in JUnit. It also emphasized the idea that having a readable test code is at least as important as writing a readable production code and that the focus of the test must be on behavior instead of implementation. Another tip was to group tests by context. Grouping the tests by context would help us organize and focus on behaviors that should be grouped together. It would also help to understand the behavior more quickly and easily.  Tobias also talked about enforcing the Single Assertion Rule. The rule was to use a single assertion if possible, but not it does necessarily mean that there could only be one assertion called, there are times when you would want to have multiple assertions. He also emphasized choosing meaningful names for the tests, it would be easier to know what the test is testing and eliminate unnecessary comments. The blog also talked about using other dependency injection frameworks like Spring to keep the tests fast and to avoid overly complex configurations. Lastly, he talked about avoiding test inheritance if possible since navigating the class hierarchy to get an idea of what is happening would make the test harder to understand.

I really find this blog useful. It stresses the idea of test behavior, not implementation. The blog also has some code in it where you can see how the tests are implemented. There are also different patterns that are useful when testing in the blog like the “Triple A” pattern which stands for “Arrange(preconditions and inputs)  Act(things happen, methods are tested)  Assert(see if the result was right)”.  The other thing that I thought was thought-provoking is the use of inheritance. He said that it should be avoided if possible but when I read his explanation, it makes so much sense not to use inheritance. The way he emphasized that tests are as important as production code changes the way I think about coding now. I feel like writing test cases before writing the actual code might be a better approach to writing software.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

What is the Decorator Design Pattern?

The Decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when the sub-classing would be impossible due to the large number of sub-classes that could result. Also, use it when you want the capabilities of inheritance with sub-classes, but you need to add functionality at run time.

Intent

• Attach additional responsibilities to an object dynamically.
• Decorators provide a flexible alternative rather than making many subclasses to extend functionality.
• Client-specified embellishment of a core object by recursively wrapping it.
• Wrapping a gift, putting it in a box, and wrapping the box.

Discussion

Say, you are working on a UI and you want to add borders and scroll bars to your windows. You could define the inheritance like… Window class interface, then you have concrete objects WindowWith_Scrollbar, WindowWith_Border etc..  This type of architecture creates a lot of subclasses and not much room for modularity.  It will be hard to change the concrete classes if you want to add some additional functions to them.

The Decorator pattern suggests giving the client the ability to choose what features they want.  There might be a problem of chaining features together to produce custom objects as well. The solution to such problem is to encapsulate the original object inside an abstract wrapper interface. Both the decorator objects and the core object will inherit from the abstract interface. Then the interface uses recursive composition to allow an unlimited number of decorator to be added to each core object.  One thing to note is that the interface must remain constant when successive layers are specified using the decorator pattern.

The decorator pattern hides the core components of the objects inside the decorator object. Trying to access the core object directly would be a problem.

UML Diagram

Example

One example is making a pizza ordering system. You can use the decorator pattern to implement a simple pizza ordering system by creating a pizza(component) and a plain pizza(Concrete Component) that is just the base or dough. Then the decoratorPizza(Decorator) which has the plain pizza and other functions. Lastly, the toppings(Concrete Decorators) for your pizza like: mozzarella, the sauce, pepperoni, etc.

In this example, you have an interface pizza and a plain dough. The decorator then adds the desired toppings to the pizza.

Conclusion

I chose this particular topic since we are creating a simple web app for scheduling classes. I thought that it was helpful since we might be adding pop up windows to our web app.

The Decorator Pattern is useful when you see yourself making something that is extensible and where you can interchangeably choose which components/functions you want on your object.  I think that with the decorator pattern, there is a lot of potential when using it. You could create something that has many functionality and is still easily changeable.

source: decorator pattern

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.