Category Archives: Week 11

Encapsulation

Encapsulation is a technique in programming where the programmer hides the internal behavior of the object from the user. Encapsulation hide the inside view of the object from the user such that it only implements the behavior of the object. Usually the client does not need to know the detail of the program and that is exactly what encapsulation does.

Encapsulation hide the data for object and makes the variables as private, and expose only the property to access the private data which would be public. So, when you access the property you can validate the data and set it.

For example, let take a Mobile Phone and Mobile Phone company. Suppose you are a Mobile Phone company and you designed and developed a Mobile Phone design(class), now by using machinery you are making a Mobile Phone(object) for selling, when you sell your Mobile Phone the user only learn how to use the Mobile Phone and not how the Mobile Phone works.

Again, let consider a TV operation for example, the manufacturers encapsulate it with cover and we can only operate it with the remote and have no need to open the TV and change the channel.

In this regard, everything is in private except remote; so anyone can access to operate and change channel and not the things in TV.

Reference:

https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

 

 

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

#5– Episode 67

Episode 67 – Object Oriented Mistakes

Presented by Joe Zack, Michael outlaw and Allen Underwood, the group addressed many object-oriented mistakes that coders often make. I found this to be an interesting podcast because like many of us upcoming coders, we are taught mistakes that cause problems when attempting to develop in an object-oriented environment. From the previous design patterns episode, we were able to understand the best situations and the proper design pattern that should be used. For example when using domain designs, we have learned not to use domain anemic models. Before we continue, anemic model is the use of a software domain model where the domain objects contain little or no business logical validations, calculations, business rules etc. These are typically called bags of properties with getters and setter without any kind of behavioral type method. The domain model objects cannot therefore guarantee their correctness in any moment due to lack of validation and mutation logic which is usually placed somewhere outside the class being addressed. One would ask, why is this considered an anti-pattern in todays programming world, well first of all, it disrupts the concept of object-oriented design. This design contracts what is implemented when on opts to use the object oriented design. Object orientation allows objects to have states and sessions but anemic causes stateless objects. It is great for just a simple application because there is a clear separation between logic and data unlike object oriented programing. Simple applications also do not require a ton of logic to be implement. They do not need methods with behavioral code in them. After this point, Micheal spoke of another anti-pattern. This pattern was known as the base bean anti-pattern. This is when you inherit functionality from a utility class instead of delegating to that utility class. The issue associated with this practice is that defeats the purpose of inheritance. Inheritance is used for the wrong reasons. The main purpose of inheritance is to create a hierarchical order in which code information can be managed and understood. Wrong implementation of inheritance disrupts object properties and class properties. Overall, design patterns are created for incoming developers and even intermediate developers to have a guide that can be used as a reference. Thy provide us with a way to getting things resolved or better yet, the first solution that solved the problem. It is up to every developer to learn beyond that and recognize how they can utilize the already laid out platform to their own coding needs and development.

 

 

 

Source

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-67-object-oriented-mistakes

https://en.wikipedia.org/wiki/Anemic_domain_model

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-11-27 23:31:16

This week’s resource can be found here.

I chose this resource on code review because we’ll be doing a code review ourselves this week, and it not only outlines several types of code review but also includes interesting additional information like statistics about which code review practices produce the best results.

There are a few unexpected benefits of reviewing code. Situations that foster communication between programmers about the code they’ve written help distribute the sense of ownership over any particular piece of code, which is useful because blaming each other for faults in the code doesn’t help anybody. Code review can also serve as a good educational tool for newer developers, as more experienced developers can point out ways to write cleaner code and shortcuts to solve common problems. A more obvious benefit is that human inspection is the best way to find complicated problems in the software’s requirements, design, scalability, error handling, and other non-code aspects like its legibility. Lastly, knowing your code is going to be reviewed demonstrably improves the quality of your code.

There are several methods of lightweight code review that fit in with modern development. Code review can be done in an email thread, for example. The benefit to this is its flexibility, as it doesn’t require everyone meeting at the same time. The downside is that the original coder ends up with a bunch of different suggestions that they have to sort through instead of the group reaching a consensus on what should be done.

Another lightweight method is pair programming, where two programmers work on the same piece of code and check each other’s work as they go. The benefit to this is that code review happens automatically during the development process. The downside is that the coders can’t get much distance from their project, so they lose the advantage of a fresh set of eyes looking at it.

Third is the over-the-shoulder method, in which someone reads your code while you explain to them why you wrote it that way. This is intuitive and very lightweight, but problems can arise if you don’t document what happens at this meeting.

Tool-assisted code review involves using software to help with the review process. Programmers can contribute reviews at different times and without being in the same location using this method, which offers the flexibility of reviewing by email thread with more organization. You still miss out on the benefits of meeting and discussing in person, however.

In addition to making me aware of several different code review options, this resource has provided statistics on how best to use these methods. Code should be reviewed in chunks of under 400 lines, as defects stop being uncovered with anything more. Reviewing 300 lines of code per hour or under and a total review time of under an hour results in the best defect detection. Defect detection drops significantly after 90 minutes of review time. These are very useful things to keep in mind.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Java: The Factory Method Pattern

In this blog post, Justin Albano talks about the Factory Method Pattern and gives us an example.

The Textbook Definition

According to the Gang of Four book that defined the technique, the intent of the Factory Method pattern is as follows:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Using the Factory Method involves creating two sets of interfaces: “(1) the product interface that constitutes the object to be created and (2) the creator interface that constitutes the object that will instantiate the product.” The UML diagram for the Factory Methods is below:

The author explains the UML diagram as the following:

Using the general pattern, we build a Creator interface, which includes one or more Factory Methods, as well as any number of other methods. This interface may also be an abstract class with defined methods or even a default implementation of the Factory Method that returns a default instance of Product. From this interface, a set of ConcreteCreator classes are created that return desired ConcreteProduct instances that implement the Product interface.

An Example in Java

  • We create an encryption mechanism that allows the user to supply a string of text and a file name, which is then encrypted and written to disk. Using the Factory Method allows us to use multiple encryption algorithms.
  • We create implementations for two encryption algorithms: (1) SHA-256 and (2) SHA-512. “For both implementations, we will use the Apache Commons encryption implementations (org.apache.commons.codec.digest.DigestUtils).”

    • In the end you should be able to do something like this:
    PersistedFile file =
       new PersistedFile("/foo/bar/text.txt", "Hello, world!", new Sha256Encryptor());
    View complete example here

    Colloquial Definition

    A method whose sole responsibility is to abstract the creation process of an object and return that object.

    I chose this resource because I am interested to learn new implementations of popular design patterns such as the Factory Method. This resource gave a detailed explanation along with other patterns that can be good alternatives to the Factory Method pattern like the Template Method pattern and Strategy Pattern. I believe the content of the article is very detailed and informative. The example they used is very interesting and I’m going to implement the code myself to test it out. I plan to use this and many other design patterns in the future. I learned more about the Factory Pattern method and when it is appropriate to use it.

    The post Java: The Factory Method Pattern 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.

    AB Testing – Episode 10 by Brent Jenson and Allen Page.

    Episode 10 by Brent Jenson and Allen Page.

    In this week’s testing podcast episode, Brent and Allen begin by discussing changes that Microsoft made during the absence of Allen in the testing department. Microsoft decided to shift their focus to a quality assurance based system instead of emphasizing on a testing based platform. Although these concepts are closely related in the field of software testing, they each specifically represent something different. Software testing is usually the process of executing a system with the intent of finding defects. By process of testing, we are able to assess or evaluate the capabilities or attributes of a software program’s ability to adequately meet the applicable standards and customer needs but quality assurance on the other end refers to a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. These new implementations by Microsoft forced engineering managers to move between teams and successfully understand the overall product specifications that need to be accomplished. After this talk, they moved over to duties and abilities of a manager the drives a QA team into either being successful or a failure. Inadequate technical skills and bad manners often lead to the demise of a team according to Brent. He believes that a manager that falls into this category only knows how to “demand more from the sausage crank”. This not only damages the crank but also shifts the focus of the operation. Increasing the fire under the meat provides more desired result. The fire is resource and help that is needed to get the task accomplished. The sausage is the software and the crank is the team members. To be a good testing and QA manager, you have to task the team members with things you would do yourself if you were the worker. Understanding that consistency and confidence in you by your employees pushes the team momentum forward. Another big factor is that product quality directly relates to the team adequacy. The best products more likely than not comes from the best QA and testing teams. Understanding that the well being of a team affects the product they are able to produce is one of the first steps to succeeding in creating a great QA and testing team. Good organizational health has to be the focus of every organization that supplies products and services to users.

     

     

     

    Sources

    https://testingpodcast.com/category/ab-testing/page/7/

    http://www.mosaicinc.com/mosaicinc/rmThisMonth.asp

     

    From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

    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.

    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.

    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.