The Decorator Design Pattern

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

400px-Decorator_UML_class_diagram.svg

 

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.

WSU Blog #8 for CS-443

URL: 

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Documentation Testing

Documentation Testing

When I was searching for different types of testing, I found a type of testing that I never heard about, which was documentation testing. I was curious since I only knew documentation that testers/developers added at the beginning of the methods/classes/test cases to give others enough basic information about them. I wanted to know more about this type of testing, therefore, I chose a basic introduction of documentation testing to read. Below was the URL of the post.

http://blog.e-zest.com/why-is-documentation-important-in-software-testing/

In this blog, Kirti Mansabdar explained the definition of documentation testing and some common documents that should be used and maintained regularly, the importance of documents. According to her, documentation testing was a non-functional type of software testing. Poor quality documentation showed badly on the quality of the product and vendor. She also provided some advantages and disadvantages of preparing documentation. Some of the advantages were making project testing easy and systematic, saving time and cost, maintaining good relationship with the client, making the client satisfied, etc.

Kirti said that in many cases, projects could be rejected in the proposal/acceptance phase for lack of documentation. This should be highlighted to get the attention since I thought that being rejected just because of lack of documentation was unworthy. In the beginning of the blog, she mentioned that one of the reasons people did not talk much about documentation in software testing was they did not want to waste time preparing documents. They wanted to spend all their time on the more functional aspects of their jobs. I disagree with them. In my opinion, even though testers knew what they were doing, but their projects would be presented and used by people who knew a little or nothing about the projects. Without documents, it would be hard for others to fully understand what the projects were and how useful they were.

In some important documents that Kirti recommended to use and maintain regularly, there were some of them that I never heard, never did, and wanted to try when I had a chance, like Test Plan Document, Weekly Status Report, User Acceptance Document. Test Plan Document included testing schedule, team structure, H/W-S/W specification, environment specifications, risk analysis and scope of testing among other points. Weekly Status Report included the status of all bugs and requirements. It could help in improving the quality of the product. This one would be useful for me since I rarely report anything weekly. It was also good to know that these documents could be used as evidence for the delay when having problem regarding product delivery.

 

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.

Post #14

As a follow up to my previous post about our upcoming group-code-review, I thought I would review another article I found that compares group code reviews to peer code reviews.  “Peer Review vs Group Review: Which Is Best For A Code Review?“, written by Stephen Ritchie, provides an answer to this question as it is often asked by clients in the field.  Ritchie begins by stating that that both methods have advantages over the other, depending on the development team’s particular circumstance.

Ritchie defines a group code review as a code review in which a portion of the development team comes together to review code while the rest of the team provides feedback for improvement.  He believes that group code reviews engage the individual developer, the team, and the team’s leaders in ways that evoke experience and judgment to find and fix problems.  As I mentioned in the previous post, Ritchie also believes that effective group code reviews let tools perform fundamental review and let the focus of the developer review to be a spotlight on parts of the code that do not utilize the best practices and designs.  Ritchie feels that discussing code, as a group, serves as an excellent transfer of knowledge from the more experienced to the less experienced.  If a group code review is conducted properly, it opens up a healthy dialog between developers about the chosen conventions and why adherence to them is important.  The main advantage of group code reviews is that it allows for a group of developers to learn and grow together, improving relationships and cultivating the transfer of knowledge and experience.  The main disadvantage of group code reviews is that it can be challenging to get all group members up to the same working pace.  Group code reviews can suffer if group members become diverted or distracted.  This can potentially lead to a worsening of relationships among developers.

Ritchie defines a peer code review as a code review in which one developer’s code is reviewed by another developer.  A pair of developers would meet and one developer would review the code of the other, and provide constructive feedback.  Peer code reviews are similar to group code reviews but their personal nature generally ensures a thorough and properly done review.  The main advantage of peer code reviews is that pairs of developers who conduct peer code reviews have likely collaborated and formed a bond in the past that allows for issues to be better-handled and addressed immediately.  The is also somewhat of a disadvantage in that it necessitates that you have a decent relationship with the person you are reviewing with, if you wish to conduct the review effectively.  A bad relationship between the reviewer and the developer being reviewed can result in a lack of collaboration and dialog and, inevitably, a poor review overall.

Ritchie believes that, for teams that have many developers with years of experience, it is more efficient to conduct peer code reviews.  This is because the time of identification to resolution of an issue is much shorter, due to the personal relationship between peers.  Ritchie prefers peer code reviews to group code reviews because they quickly improve the developers’ skills while simultaneously making progress in the implementation.

I agree that peer code reviews are more personal and allow for faster feedback and resolution to issues but I also appreciate the fact that group code reviews bring many resolution strategies and points of view to the table.  For the small projects I have worked on, I have always found peer review to be more effective – but I think that, because larger projects generally require more developers, a group code review is necessary to get all the developers on the same page.  I think that the code we are reviewing could be done by a pair of developers, but I am looking forward to seeing if the group review will provide better solutions and insight.

 

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

Code Quality: Fighting Primitive Obsession Code Smells

In this blog post, Anna Makowska talks about primitive obsessions code smells and what you can do to fix them. The author chose to focus on primitive bbession code smell because some smells are harder for developers to detect intuitively.

“Primitive data types are basic built-in building blocks of a language. They’re usually typed as int, string, or constants. As creating such fields is much easier than making a whole new class, this leads to abuse. Therefore, this makes this smell one of the most common ones.”

Examples

  • Using primitive data types to represent domain ideas. For example, using an integer to represent an amount of money or a string for a phone number.
  • Using variables or constants for coding information. An often-encountered case is using constants for referring to users roles or credentials (like const USER_ADMIN = 1).
  • Using strings as field names in data arrays.

Consequences

  • Code becomes less flexible because of use of primitives instead of objects.
  • Primitive data types are much harder to control. As a result, we may get variables that aren’t valid (supported by the type) or meaningful.
  • Primitives are often related to dedicated business logic. Therefore, leaving this logic unseparated may violate the Single Responsibility Principle and the Open/Closed Principle.
  • When data type logic is not separated in a dedicated class, adding a new type or behavior makes the basic class grow and get unwieldy.
  • By using primitives, the developer loses the benefits that come with object-oriented design, like data typing by class name or type hinting.

Replace Data Value With Object

  • Instead of a set of primitive values, the programmer has full-fledged classes with all the benefits that object-oriented programming has to offer (typing data by class name, type hinting, etc.).
  • There is no need to worry about data validation, as only expected values can be set.
  • When relationship logic extends, it will be placed in one place dedicated to it.

I chose this resource because it had plenty of good information on the primitive obsession code smell, when it’s going to lead to problems and how to fix that. I learned two more fixes, Replace Type Code With Subclasses, State, or Strategy (patterns) and Replace Array With Object for when “values of a coded type aim to control the behavior of the program.” I felt the content to be quality content from a author who has experience with spotting and fixing code smells. I will use this information in the future, by keeping an eye out for primitive obsession code smells.

The post Code Quality: Fighting Primitive Obsession Code Smells appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Benefits of Using Angular and TypeScript

What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

  1. Consistency
  2. Productivity
  3. Maintainability
  4. Modularity
  5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

 

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

11/27/2017 — Blog Assignment 10 CS 343

The blog post this week discusses my favorite principle in software development, the open and closed principle. The open and closed principle encourages independencies in software development. It states the following as outlined in the article: Class behavior should be open for extension but closed for modifications. This can be separated into two parts. As explained in the article, the first part is about the behavior of a class. Extensions of behavior allows for changes in behavior to be added, deleted or modified without affecting the other behaviors. This is what is meant to be independent. Thus, the 1st part of the statement signifies changes in behavior which signifies changes in source code. The second part of the statement states that class behavior should be closed for modifications. Is this a contradiction? Modifications means changes to source code, which the second statement encourages developers not to change. This means that class behavior should be independent and not need to be modified when other parts of its behavior are changed. So, when extending a class behaviors, the source codes for other behaviors should not be changed. The other definition introduced in the article is: Software entities(classes, modules, functions, etc.) should be open for extension, but closed for modifications. The explanation for the principle is as I have described previous just above that it encourages independence in software methods.

The article, however, expresses confusion for both definitions because the two sides of the principle is a contradiction, however I think it did a pretty good job in its explanations and examples. As explained in the article, the main idea behind the OCP is that the behavior of the system can change by replacing “entities that constitute it with alternative implementations,” but that the other behaviors can be independent and therefore need not be changed. The example given is that for calculating taxes. As stated, take for example the TaxCalculator interface for calculating taxes. In this system, if we replace the UsTaxCalculator with the UkTaxCalculator, this does not require modifications of existing logic, but that it provides for new implementations to an existing interface. Overall, the main idea is that you can add behaviors to systems be adding new code, but the existing ones do not need to be changed. This creates separability so that system behavior can be easily modified and changed.

Finally, I will close this post with a discussion about 3 rules of thumb suggested in the article that can help a developer to determine when to use the open closed principle. The first is to add extension points to classes that implement requirements that are intrinsically unstable due to instability of the system. This helps to clean the code which makes it easier for modifications of system behavior. The second is to not add more preliminary extension points. Finally, the third is to refactor parts of the code and to introduce additional extension points when the parts are unstable.

Overall I chose this article in order to compare my understanding of the OCP with another software developer. In my opinion, the OCP is based on indenpendence of methods, functions and classes. Although the article indirectly refers to this point, still I think it misses to introduce this point directly.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Blog 7

Soft Qual Ass & Test

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

The Testing Show: Episode 43: Machine Learning

For this weeks blog i will be doing a podcast from The testing show on machine learning, which can be found here.  The podcast starts with a discussion of a recent tech story by facebook on their AI chat boxes developing their own language and having to be shut down. To understand this story the podcast goes into some detail about what machine learning is. The guest on the show Peter Varhol defined it as follows: machine learning works on the feedback principal, which is how we can produce better results by looking and comparing the results produced by the machine learning algorithm to the actual results and then feeding that back in to adjust the algorithm and produce incrementally
better results. After this they discuss what they think might of happened with the facebook chat bots, they went through multiple views such as being intrigued , to skeptical , to really questioning if the bots actually developed a language at all or just gibberish.

Although the podcast does not come to some big conclusion , the final view on the topic was the most thought provoking. The last view was disputing if the chat boxes really created their own language , and if so how? In the podcast the hosts were talking about how language is semantic and that it would be impossible right now for a computer to be able to understand semantics ,let alone creating a new language. The host theorizes that the chat bot created a language of gibberish to make up for the fact that it could not fully understand what was being asked of it semantically. I thought this was a really interesting point, i had never considered the semantics of language and shows how far computer scientists have to go for real artificial intelligence.

In the last part of the podcast we dive deeper into how machine learning works and some of the pros and cons. One pro is that we can set up a series of algorithms and iterative processes to achieve something we simply couldn’t do on our own. The example given here is the Facebook chat bot again, they talk about how even if Facebook released the source code for the bots, the algorithms would likely be to complicated to understand for almost everyone, and so it would be hard to verify the results for the chat bots. As maybe you can see from the example , our pro also becomes our con. This is because once we get what seems like a reasonable result from our machine learning algorithm, it becomes very hard to trace our answer back through the code.

The last part of machine learning covered in this podcast is the difference between supervised and unsupervised learning. Supervised learning is pretty straight forward we know the result from out training data and try to get a result close to our known result. Unsupervised learning is more difficult to explain, we don’t know the expected result and are just trying to optimize something. The example given for this is airline ticket sales online, the algorithm is built to maximize profits for the airline company. Roughly 3 times a day online ticket sale prices change, there is no exact formula to how the airliners change their prices, the algorithm is simply trying to optimize the amount of money made.

This was a very interesting listen on a topic which i don’t know a whole lot about, but seems to be the way of the future in tech. I picked this article because it was an interesting topic which comes up all the time in articles and discussion boards and i wanted more information, as well as how to test it. Although the podcast did not get around to talking about how machine learning is tested, there is a second part which was recently released which should go into more detail on that. This first section however gave a good overview on the topic and the issues that may arise, this gives you somethings to think about in terms of how testing will be affected compared to testing a standard algorithm. I enjoyed this article quite a bit and will be listening to the 2nd part to see how to go about testing Machine learning, i will be looking out to see what my expectations for testing using machine learning are before and after listening to part 2 of the podcast.

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

Benefits of Using Angular and TypeScript

What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

  1. Consistency
  2. Productivity
  3. Maintainability
  4. Modularity
  5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

 

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.