Category Archives: Week 9

API Design with Java 8

In this blog post, Per-Åke Minborg talks about the fundamentals of good API design. His inspiration for writing this article is a blog post by Ference Mihaly which is essentially a check-list for good Java API design.

“API combines the best of two worlds, a firm and precise commitment combined with a high degree of implementation flexibility, eventually benefiting both the API designers and the API users.”

Do not Return Null to Indicate the Absence of a Value

Using the Optional class that was introduced in Java 8 can alleviate Javas problem with handling nulls. An example below shows the implementation of the Optional class.

Without Optional class

public String getComment() {

    return comment; // comment is nullable

}


With Optional class

public Optional getComment() {

    return Optional.ofNullable(comment);

}

Do not Use Arrays to Pass Values to and From the API

“In the general case, consider exposing a Stream, if the API is to return a collection of elements. This clearly states that the result is read-only (as opposed to a List which has a set() method).”

Not exposing a Stream

public String[] comments() {

    return comments; // Exposes the backing array!

}

Exposing a Stream

public Optional getComment() {

    return Optional.ofNullable(comment);

}

Consider Adding Static Interface Methods to Provide a Single Entry Point for Object Creation

Adding static interface methods allows the client code to create onjects that implement the interface. “For example, if we have an interface Point with two methods int x() and int y(), then we can expose a static method Point.of(int x, int y) that produces a (hidden) implementation of the interface.”

Not using static interface methods

Point point = new PointImpl(1,2);

Using static interface methods

Point point = Point.of(1,2);

I selected this resource because it relates to design principles, and it’s something that I do not know well. I would like to learn more about APIs and good practices for designing them using Java. The article had useful information and topics that I didn’t know well. A few more pointers from the article I learned:

  • Favor Composition With Functional Interfaces and Lambdas Over Inheritence – Avoid API inheritance, instead use static interface methods that take “one or several lambda parameters and apply those given lambdas to a default internal API implementation class.”
  • Ensure That You Add the @FunctionalInterface Annotation to Functional Interfaces – signals that API users may use lambdas to implement the interface
  • Avoid Overloading Methods With Functional Interfaces as Parameters – Can cause lambda ambiguity on the client side.

I would like to learn more about using AWS Lambdas, and learning more about APIs in general. I plan to use this information if I am ever to work on Java APIs which is possible. I want to make sure I have the best practices and the check list mentioned in the start of the article seems like a good starting point.

The post API Design with Java 8 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.

What is Model-Based Testing?

Link to blog: https://blogs.msdn.microsoft.com/specexplorer/2009/10/27/what-is-model-based-testing/

There are many different ways to test software. This blog written by Nico Kicillof defines what model-based testing is and what it is used for.

Model-Based Testing is a lightweight formal method used to validate software systems. It is considered “formal” because it works out of a formal specification or model of the software system. It is “lightweight” since it doesn’t aim at mathematically proving that the implementation matches the specification under all possible circumstances. Here is an image below from the link:

image

(In the image above, Kicillof shows the diagram that illustrates model-based testing in a nutshell.)

The difference from considering a lightweight method from a heavyweight method is that it comes between sufficient confidence vs. complete certainty as Kicillof likes to put it.

The first step of the process is that it is important to know that the method starts off as a set of requirements that could be written from the development team, or you the developer. The next step is to create a readable model that shows all the possible behaviors of a system meeting the requirements that were given to you the developer. Keep the model manageable by creating the right level of abstraction. Kicillof says this because it makes sense to keep a model manageable. If a model isn’t manageable, then it is basically a bad model to use. It would be difficult to make edits or reconfigure your model if you run into a specific type of problem where your model doesn’t clearly highlight how to fix it.

Kicillof gives the example of model based testing through the use of Microsoft Spec Explorer. He explains that in Spec Explorer, models are written as a set of rules in the mainstream language of C# which makes it less difficult to learn in comparison ad-hoc formal languages.

Kicillof’s explanation on how model-based testing works made me understand the concept better than before. The image he provides, just like the one shown above, illustrates the process of model-based testing. The numbers near each part of the process in the image made it easy to follow. I chose this blog because I wanted to know a little more on model-based testing. I wanted to think on how it would be used in my future career of video game development since it is another great way to test software. Depending on what games I’ll be creating in the workplace, knowing model-based testing is important because I think it is an easier formal way of testing in comparison to other types of testing.

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

TS>JS (For Scaling)

Before this class, I had heard of Angular before and had always heard it referred to as a JavaScript framework. I guess technically it is, because it still compiles to JavaScript but the language itself is written in the JavaScript superset, TypeScript. I had never heard of TypeScript before this class and the idea of a superset language was also a new concept. I was curious why Angular was written in TypeScript over JavaScript or other supersets. I know from outside sources that the first iteration of Angular was written in JavaScript but every iteration of the framework since, has been written in TypeScript and I wanted to know why. This post by Victor Savkin lays out the benefits of using TypeScript as a way of explaining why Google chose TypeScript for Angular.

Victor clears up my lack of understanding of what a superset is relatively simply. He explains that being a superset of JavaScript, everything you can do in JavaScript, you can do in TypeScript. With small changes to the code, a “.js” file can be renamed a “.ts” file and compile properly.

Victor emphasizes the lack of scalability in vanilla JavaScript. With JavaScript, large projects are much more difficult to manage for many reasons including the weakly typed aspect and the lack of interfaces. TypeScript solves these problems and helps create better organized code with its syntax. With its better organization, TypeScript is much easier to read through compared to JavaScript.

The lack of interfaces in JavaScript is a major reason why it doesn’t scale well for large projects. Victor uses a code example in JavaScript that shows that aspects of a class can be lost in JavaScript because of its lack of explicitly typed interfaces. The code is then reshown in TypeScript and is much more clear because you can actually see the interface. It’s that simple, in JavaScript, you have to really focus in on how every object interacts with each other because of the lack of explicitly typed interfaces. TypeScript allows you to create these interfaces so future code maintenance is less stressful and bug filled.

TypeScript offers explicit declarations, which is illustrated through some code samples in the article. The JavaScript code is a simple function signature that lacks any typing or clear information about the variables involved in the function. In the TypeScript version, it is clear what the types of the variables are, making the function much more clear in TypeScript.

There are other reasons defined in this article on why TypeScript was chosen and what makes it so great, but these are a few of the ones that stuck out to me. I’ve written JavaScript projects before and wondered how some of these concepts would affect larger projects, and now I know how they can be resolved. This article and information will prove useful for writing my final project and any future TypeScript-based projects that I decide to take on in the future.

Original Post: https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8

 

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Revisiting Polymorphism

This week I found this article on JavaWorld by Jeff Friesen that is entirely about polymorphism. Polymorphism is a core concept for all software development and a lack of strong understand will lead to weak applications and poorly written code. One can never revisit topics like polymorphism too much. This article discussing the four types of polymorphism, upcasting and late binding, abstraction, downcasting, and runtime type identification (RTTI). The article presents everything in the form of a code example and constantly revisits in the explanation process, which I find incredibly useful.

The first part of the article is an overview of the four types of polymorphism, coercion, overloading, parametric and subtype.. Of these four there are some bits that stuck out more to me than others. For coercion the obvious example is when you pass a subclass type to a method’s superclass parameter. At compilation, the subclass object is treated as the superclass to restrict operation. The simple example that is forgotten is when you perform math operations on different “number” data types like int’s and floats. The compiler converts the int’s to float’s for the same reason as the subclass to superclass object. Another piece in this first section that stood out to me was the overloading type of polymorphism. The obvious example here is overloading methods. In a class, you can have different method signatures for the same method name and each will be called depending on the context. Again, there is a simple example that is overlooked in the operators like “+”. For example, this operator can be used to add int’s, float’s, and concatenate Strings depending on the types of the operands.

The upcasting section uses our favorite example, different types of shapes and is almost entirely written in reference to one line of code, Shape s = new Circle(); This upcasts from Circle to Shape. After this happens, the object has no knowledge about the Circle specific methods and only knows about the superclass, Shape methods. When a shared method (implemented in both Shape & Circle), the object is going to use the Shape implementation as well unless it is clear through context to use Circle’s.  Similar to this section that uses superclasses and subclasses, is the section on abstraction. The article uses the Shape and Circle example again but points out that having a draw() method that does something in Shape does not make any sense from a realistic standpoint. Abstraction resolves this, meaning that in an abstract class, there is no way to instantiate a method like draw() for the superclass of Shape. This also means that every abstract superclass needs subclasses to instantiate their behaviors.

These are just a few parts of the article that stood out to me personally. The article as a whole is incredibly useful and worthy of a bookmark by every developer. I will continue to revisit this article if I find myself lacking confidence about the topic of polymorphism in the future!

Original Article: https://www.javaworld.com/article/3033445/learn-java/java-101-polymorphism-in-java.html

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Blog 5

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.

Abstraction

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

Test case Evaluation

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

Determining Which UML Diagram to Use

Link to blog: http://blog.architexa.com/2010/04/determining-which-uml-diagram-to-use/

This blog gives an overview on choosing which type of UML diagram to use when it comes to designing software. Some software designers may encounter a problem where they’re coming to a choice on whether which UML diagram to use that is most efficient for a particular task given to them. I am one of those designers because sometimes, I come to a problem where I can’t decide on which UML diagram I should use.

First, there are 3 classifications of UML diagrams: Behavior diagrams, Interaction diagrams, and Structure diagrams.

Behavior Diagrams: 

These are types of diagrams that show behavioral features of a system. This includes activity, state machine, and use case diagrams. Examples of a behavior diagram would be an Activity Diagram and a Use Case Diagram. The activity diagram shows high-level business processes, including data flow, or to model the logic within the system. To simply put it, behavior diagrams, in general, breaks down processes into individual decisions, loops and chain of events.

Interaction Diagrams: 

Interaction Diagrams are a subset of diagrams which emphasize the interaction of objects. This includes communication, interaction overview, sequence, and timing diagrams. These diagrams fulfill the need of designing a system where there are complex relationships between code elements and provides a view on how the elements interact over time. Examples of interaction diagrams include Collaboration/Communication Diagram, Sequence Diagram, Interaction Diagram, and Time Diagram. 

Structure Diagrams:

Structure Diagrams show elements of a specification that are irrespective of time. This means that the elements are not affected by the nature of time. Examples of structure diagrams include Class Diagrams, Composite Structure Diagrams, Component Diagrams, Deployment Diagrams, Object Diagrams, and Package Diagrams. Structure Diagrams, in short, help break large projects or features into parts and specify which parts do what and how they interact within the system.

I chose this blog because I wanted to know the different types of diagrams within the three classifications of UML diagrams. I was aware of the three classifications of UML diagrams, but I didn’t know certain types within each classification such as the Deployment and Composite Diagrams within the Structure Diagram Classification. The author of the blog briefly highlighted each of the three classifications in detail with links pertaining to each of the example diagrams presented within each classification. This made it easier to understand how each example operated. It is important for me to understand the different classifications and their examples of diagrams because when it comes to programming video games, which would be my future career, I would have to implement and figure which diagram is necessary for each type of game design.

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

Builder Design Pattern

Builder Design Pattern is an example of a creational pattern. Creational design patterns solves the problem/complexity of object creation in a design by somehow controlling the objects creation.

Builder design pattern is used to create objects that are made from a bunch of other objects. You use the builder design pattern when you want to build an object made out of other objects. Use it when you want the creation of these parts to be independent from the parent object. Hide creation of the parts from the client. Only the builder knows the specifics of the object and nobody else.

Intent of Builder design pattern.

  • To separate the construction of a complex object from its parent object so that the same construction process can be created differently in representations.
  • Create one of several targets

In a builder design pattern, we have the “director” which invokes the “builder” services as it interprets the external format. The “builder” then creates the object each time it is called. Then, when the product is finished, the client retrieves the results from the “builder”.

1aa5ab128c99a174fc628835260d7aeb

Example:

Say the client wants a new remote for your TV, but you know that you’ve already made a remote before and the client wants the same thing but calls it the “remoteX”. You can use your old remote object to pass it in a director to create remoteX by passing it to the remote builder without changing anything from the old remote set up.

 

Other Useful things to consider:

  • Builder can use one of the other patterns to implement which components get built. i.e Abstract Factory, Builder, and Prototype can use Singleton for implementation.
  • Builder focuses on constructing the complex object step by step.
  • Builder often builds a Composite.

 

The builder design pattern is really helpful when you are creating objects that are made out of other objects. Just like creating a menu, most menus have a drink, appetizers, and a dessert associated with the meal. You can also use other patterns to implement which components will be built.

I selected this topic because it is one of the main design patterns that is discussed in the Gang Of Four book. It is also pretty simple to understand. The builder design pattern is also a good pattern to have under your belt, since it seems like in the real world we are creating the same objects and upgrading it much more often than creating a new one.

I really think that learning the main or fundamental design patterns is beneficial when creating an application. It just always seem to pop up. Like for our final project, we were thinking of building a class schedule maker, but you can also make the class schedule maker just a regular schedule maker say for appointments or meetings.

 

https://sourcemaking.com/design_patterns/builder

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

FEW HICCUPS

This week i read the blog few hiccups by Michael Bolton which can be found here. This article is about better describing the expectations you have for your code before testing which makes it easier to find problems in the code. Also in the article is identifying and applying oracles. I could not figure out what that meant at first but in an older Michael Bolton article i found the definition to be as follows.An oracle is a principle or mechanism by which we can tell if the software is working according to someone’s criteria; an oracle provides a right answer—according to somebody. That article which is called Testing without a map can be found here.

The article is actually a mnemonic in which the blog is based around. The mnemonic is split into two parts, FEW and HICCUPS. The HICCUPS part of the mnemonic refers to a list of  the authors oracle principles. HICCUPS is designed as follows:

  • History. We expect the present version of the system to be consistent with past versions of it.
  • Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
  • Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
  • Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
  • Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
  • Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
  • Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
  • Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

Each one of these is a criteria that can be used to identify a problem in your code. We have a problem once we realize that the product or system is inconsistent with one or more of these principles. The FEW part of the mnemonic is defined as follows:

Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.

World. We expect the product to be consistent with things that we know about or can observe in the world.

Familiarity. We expect the system to be inconsistent with patterns of familiar problems.

These last 3 oracle specifications were added later on updating the mnemonic from HICCUPS to FEW HICCUPS. The way to remember this given in the article is: When we’re testing, actively seeking problems in a product, it’s because we desire… FEW HICCUPPS.

I stumbled on to this blog by accident while looking at other blogs about testing consistency but i am glad that i did. This was a very interesting read and was not like other blogs that i have read. All the different specification oracles in the article were interesting and each seems to have it’s place. These specifications i think would make you a much more consistent tester by giving you a consistent guideline for finding problems in your code. The mnemonic was my favorite part of the article and not something that i have seen to many times in software testing. This seems like it would be very helpful in memorizing these oracle principles well into the future.This is something i am going to try and remember and use in my testing. Often times it is hard to pick were to start looking for problems in your code , or how to identify those problems. This mnemonic seems like a good way to fix that.

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