Hello dear readers. Welcome back to my blog. As we know by now most programming language support and encourage object-oriented programming and in this blog post we are going to talk about the principles of the Object-Oriented Programming. The key design principles of Object-Oriented Programming are:

Abstraction – is the idea of simplifying a concept to its bare essentials in some context. It allows you to better understand the concept by stripping it down to a simplified version. Your abstraction should be intuitive.

Encapsulation – can be thought of as putting something inside a capsule. In software, restricting access to inner objects and properties helps with data integrity. Encapsulation makes your classes easier to manage, because you know what part is used by other systems and what isn’t. This means that you can easily rework the inner logic while retaining the public parts and be sure that you have not broken anything. A disadvantage of it is that working with the encapsulated functionality from the outside becomes simpler as you have less things to think about.

Decomposition – is the action of splitting an object into multiple separate smaller parts. Spitted parts are easier to understand, maintain and program. There exist three types of decomposition relationships: 1. Association, which defines a loose relationship between two components. They don’t depend on each other but work together. 2. Aggregation, which defines a weak ‘has-a’ relationship between a whole and its parts. The parts though can exist without the whole. 3. Composition, which defines a strong ‘has-a’ relationship where the whole and the part can’t exist without each other.

Polymorphism – is the ability for data to be processed in more than one form. It allows the performance of the same task in various ways. It also consists of method overloading and method overriding.

Inheritance – is the ability of one class to inherit properties of another class, called the parent class. We can inherit properties from other classes s well.  So, when we create a class, we do not need to write all the properties and functions again and again, as these can be inherited from another class which possesses it. Inheritance allows the user to reuse the code whenever needed.

Design principles are rules in software design that have proven themselves valuable over the years. Just like any other ‘game’ even when we code we need to know and follow the rules. This is the main reason why I choose to write about the principles of Object-Oriented Programming.

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

Anders Hejlsberg is known as the creator of TypeScript. On 2010, he and his team began developing TypeScript, and in 2012 they released TypeScript 0.8 for the first time. There were several versions of TypeScript released since 2012. The last version announced is TypeScript 3.2 RC, which is the release candidate of the next version. According to Anders Hejlsberg, JavaScript is TypeScript, but TypeScript is not JavaScript, which makes TypeScript a superset of the JavaScript language. That means that any valid JavaScript code is also valid TypeScript code.

TypeScript has additional features and does not exist in the current version of JavaScript, supported by most browsers out there. In TypeScript, we have this concept of strong or static typing. If you have worked with languages like C# or Java, you know that in these languages when we define a variable, we need to specify the type of that variable. In TypeScript typing is optional so we don’t have to use this feature. But using this feature makes our applications more predictable and it also makes it easier to debug them when something goes wrong. Typescript also brings Object-oriented features that we have missed in JavaScript for a long time. We have the concepts of classes, interfaces, constructors, access modifiers like public and private, fields, properties, generics, and so on. Another benefit of using TypeScript is that with TypeScript we can catch errors at compile time instead of the runtime, of course not all errors but a lot of them. There is a compilation step involved, and when we compile with TypeScript code, we can catch these errors and fix them before deploying our application. And finally, another benefit of using TypeScript is that we get access to some great tools out there. One thing that I personally love about TypeScript is the autocomplete suggestions that we get in our code editors as we are coding, like Atom and Visual Studio Code.

TypeScript is a beautiful language but the browsers that we use every day don’t know TypeScript, and it is very unlikely that the browsers are going to support TypeScript in the future. So, we need to compile or more accurately Transpile our TypeScript code into JavaScript code.  This is part of building an application. Whenever we build an application TypeScript compiler kicks in and it Transpiles TypeScript code into JavaScript code that browsers can understand.

References: https://en.wikipedia.org/wiki/TypeScript,

https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript,

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

As I take another step towards my journey in software C.D.A. I dive into REST APIs. Where I will be talking about the YouTube video I found “APIs|REST|REST APIs Demystified” from The TechCave. For this weeks blogs I am going to try things different. I will give a very short summary of what the blog talks about and if you are interested in the topic I strongly suggest watching the video it is very interesting and on point to the topic. The video also provides a short example to help you understand and see how rest APIs works using Node.js.

This video talks about what an API is, and how it relates to a web service and/or relates to REST. This is a very interesting video because it seems to cover a lot of basic knowledge needed when dealing with APIs, REST, or RESTful APIs. It also talks about what a person needs to start building APIs. In the video the presenter answers the following three question:

1. What is an API?
   • Also known as Application Programming Interface, that has the ability to give software component a way to communicate with each other.
2. How does it relates to web services?
   • API relates to web services because they both work as a communication sharing base between services or components.
3. What is a REST API?
   • “Is an API that follows the rules of the REST specification”.

for more specification on those question just watch the video by clicking the highlighted link above. I have to say that from this video I found the following tip from the video very useful and interesting… “Questions every API should answer:

1. How can the client tell the service provider which operation it wants to perform?(Method information)
2. How can the client tell the service provider what data to operate on?(Scoping information)”

That is because it helps you understand during building the API it needs to answer those question in order to make sure your API would be successful. This video is not just interesting… it was also useful. From now on when building an API I will ensure that it answer those two questions.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Greetings reader!

In today’s blog, I will be discussing the differences between specification-based testing and code-based testing . I will also explain the benefits of each test, as well as pointing out their distinct features. Without further explanation, let’s begin!

Code based testing is a technique used to see if each line of code has been executed correctly. It corresponds to the testing that is carried out on code development, code inspection, and unit testing in the software development process. The idea is to find out whether any bugs exist in the program by choosing a set of test cases that can create the wanted results. Code based testing involves dynamic testing, static testing, and calculating Cyclomatic complexity.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. Cyclomatic complexity is a mathematical based technique that helps reveal the facts that may be hard to find. It is the calculation of the number of nodes reached and the jump to the next node. It is done with the help of a control flow graph.

Specification-based testing technique is also known as black-box testing because they view the software as a black-box with inputs and outputs. Black box testing is a testing method in which there is no access to the source code or the internal structure of software. The main goal is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors. The testers have no knowledge of how the system or component is structured inside the box. Specification-based techniques are applicable at all levels of testing where specification exists.

Types of Specification Based Testing Techniques

1. Equivalence Partitioning
2. Boundary Value Analysis
3. Decision Tables
4. State Transitioning

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

This week I will be looking at the decorator design pattern. This post discusses the advantages of using a decorator design pattern over inheritance in Java and gives examples of its implementation. The main advantage being a significantly less number of classes are needed when adding functionality using a decorator versus using traditional inheritance. It also mentions that the decorator should be added so that it is natively supported by programming languages. I think that this is the most interesting part of the entire article. I agree that languages, and in particular Java should start natively adding support for these design patterns. By doing this, as the article says it makes it much easier for beginner programmers to implement. I agree with this and I find that this can be challenging when you are first learning about design patterns and especially if you are starting out programming. In addition, I agree that a native implementation makes this design pattern, and others much cleaner to implement. As the example of the implementation in this article shows it would require a lot less work and code if it was implemented as they have it with just having a decorates statements instead of implements when creating a new class. I find this approach would encourage me and others to use this as it would be easy to use and not require repetitive typing, which as the article states would lead to better programs. I think this point of native support should also go beyond just this particular design pattern. I think that Java and other object-oriented languages should add native support for some of the other popular design patterns as well such as strategy or singleton. This would make it easier to experiment with different patterns earlier in the stages of learning to program and would let people see the benefits without struggling on the implementation necessarily. I would have found it much more encouraging to use one of these patterns as the article suggests if it was natively supported versus creating my own implementation based on text-book examples. Overall this article and what I’ve learned in this class have taught me to prefer using a design pattern over basic inheritance in most scenarios when building programs and that adding native support for these patterns would make it even better to use.

Source: https://dzone.com/articles/is-inheritance-dead

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

Derek Banas has a youtube channel dedicated to java tutorials and higher level software development concepts. In his video series of design patterns, he describes the value and how to use the Decorator Design Pattern. Banas begins his tutorial by explaining the utilization of the decorator pattern, and then applies it by using a simple example based on a pizza making simulator.

The purpose and value of using the decorator pattern according to Banas is it allows you to dynamically modify an object, without having to hard code additional features. By extension, this allows us to add to old code without having to rewrite the program. Banas suggests to use the decorator pattern in situations where we would want to use inheritance, but where the classes need to be flexible enough to add features to during run time, so inheritance itself is not sufficient. By applying this pattern we are able to favor composition over inheritance.

Banas applies this pattern in an example of a program used to add toppings to a pizza, and display a description and cost. He first implements the solution to this problem using inheritance, hard coding each type of pizza subclass with a preset description and price. However, Banas notes how by using inheritance, we would have to implement an infinite amount of subclasses for each combination of topping. Furthermore, the change in price of a topping would necessitate changing every subclass using that topping. So regular inheritance is not sufficient for this program.

From here out Banas implements the decorator pattern using a Pizza interface, a ToppingDecorator abstract class with a Pizza instance variable, and PlainPizza concrete class. By creating topping classes that extend ToppingDecorator, he is able to add toppings dynamically to a PlainPizza object, calling a string of constructors for each topping (Pizza myPizza = new TomatoSauce(new Mozzarella)…).

I highly recommend Derek Banas’ youtube channel, as he is adept at breaking down high level software design strategies into simple examples anybody can understand, and he is skilled at illuminating the benefits of design patterns over more basic, intuitive implementations. The structure of his videos are easy to follow as well, starting with a high level discussion, moving down to a UML diagram, and finally implementing the solution. This strategy is very helpful for anyone learning or needing clarification on design patterns.

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

For this week, I have decided to read “Black box, grey box, white box testing: what differences?” from the NBS System blog. The reason I have chosen to read about this is because while I do understand the basics of what each box does, I have the need to find out more about the benefits and the perspectives of using them. I believe this will help in understanding the purposes of utilizing each one and why do some tend to use them for a certain amount of time.

This blog basically goes over as the title implies what do the boxes do and what do they offer for possibilities. Black box consists of reviewing only the functionalities of an application or rather what it does it is what is supposed to, no matter how it does it. The user needs to know what the role of the system is and its functionalities but does not need to know its inner mechanisms. For white box, it consists in reviewing the functioning of an application and its internal structure. All of the internal components of the software or application are tested through the source code, which is the main work base of the user. Grey box testing complies both of the previous approaches: testing both of the functionalities and functioning of a website. This means that a tester gives an input to the system, checks to see if the result is the expected one, and checks through which process the result was obtained from. It is vital with these kind of tests to make sure the product is complete, secure and efficient.

What I think is useful about this blog is that it provides the benefits and drawbacks for each box like for black box, it has simplicity and redundancy listed down and gives an explanation based on it. There is also the example of penetration testing to give an understanding of each box in a real-life situation. From this blog, it goes from the general definition to the boxes, explaining how the boxes works from one perspective to the next, benefits and drawbacks of the boxes, and finally a penetrating testing example.

Based on the content of this blog, I would say that this blog is a good introduction to knowing the boxes in concept.  I do not disagree with this content since it does try to give readers the information needed and provide great examples to get a clear understanding overall. For future practice, I shall try to get familiar with the examples the blog uses for the boxes in real-life situations.

Link to the blog: https://www.nbs-system.com/en/blog/black-box-grey-box-white-box-testing-what-differences/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.