The Adapter pattern is easy to understand as the real world is full of adapters. The general idea of an adapter in software development is identical to the one in the physical world. If you have been to different countries, you probably recognized that a lot of them are using differently shaped power sockets. Quite often, they are shaped in a way that the plug of your electrical device doesn’t fit. So, how do you connect the charger of your mobile phone or laptop to these power sockets?

The answer is simple. You get an adapter which you can put into the power socket and then you put your plug into the other end of the adapter. The adapter changes the form of your plug so that you can use it with the power socket. In that example and in most other situations, the adapter doesn’t provide any additional functionality. It just enables you to connect your plug to the power socket. The Adapter Pattern applies the same idea to object-oriented programming by introducing an additional adapter class between an interface and an existing class. The adapter class implements the expected interface and keeps a reference to an object of the class you want to reuse. The methods defined by the interface call one or more methods on the referenced object and return a value of the expected type. By doing that, the adapter class fulfills the expected contract by implementing the interface and enables you to reuse existing, incompatible implementations.

The Adapter Pattern is an often-used pattern in object-oriented programming languages. Similar to adapters in the physical world, you implement a class that bridges the gap between an expected interface and an existing class. That enables you to reuse an existing class that doesn’t implement a required interface and to use the functionality of multiple classes, that would otherwise be incompatible.

One advantage of the Adapter Pattern is that you don’t need to change the existing class or interface. By introducing a new class, which acts as an adapter between the interface and the class, you avoid any changes to the existing code. That limits the scope of your changes to your software component and avoids any changes and side-effects in other components or applications.

 

Thank you for reading!

Reference

https://dzone.com/articles/adapter-design-pattern-in-java

 

 

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.

The Singleton pattern encapsulates a shared resource within a single unique class instance. This instance arbitrates access to the resource and storage-related state information. A class method provides the reference to this instance, so there is no need to pass the reference around Any object that has access to the Singleton’s class header can use the Singleton.

This design pattern defines the structure of a class that can have only one instance. A Singleton encapsulates a unique resource and makes it readily available throughout the application. The resource might be hardware, a network service, a persistent store, or anything else that can be modeled as a unique object or service. Singletons may often be modeled as a server within the application that accepts requests to send, store, or retrieve data and configure the resource state.

Implementation

Implementation of the Singleton pattern often typically creates a single object using the factory method, and this instance/object is called a shared instance in most cases. Since the access to the instance is passed on though a class method, the need to create an object is eliminated.

 

Pros and Cons

Singletons are not the answer to every problem. Like any tool, they can be short in supply or can be overused. Some developers are critical of Singletons for various reasons. We will examine this critique and discuss ways to address them briefly. The criticisms, for the most part, fall into two categories:

Singletons hinder unit testing: A Singleton might cause issues for writing testable code if the object and the methods associated with it are so tightly coupled that it becomes impossible to test without writing a fully-functional class dedicated to the Singleton.

Singletons create hidden dependencies: As the Singleton is readily available throughout the code base, it can be overused. Moreover, since its reference is not completely transparent while passing to different methods, it becomes difficult to track.

To avoid these complications, when considering the Singleton pattern, you should make certain that the class is a Singleton. Also, while thinking of designing the Singleton design pattern, keep testing in mind and use dependency injection whenever possible, which means: try to pass the singleton as a parameter to the initializer whenever possible.

 

Thank you for reading, please share it if you found it useful!

Reference

https://www.geeksforgeeks.org/singleton-design-pattern-introduction/

 

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.

Motivation:

Sometimes we need the ability to control the access to an object. For example, if we need to use only a few methods of some costly objects we’ll initialize those objects when we need them entirely. Until that point, we can use some light objects exposing the same interface as the heavy objects. These light objects are called proxies and they will instantiate those heavy objects when they are really need and by then we’ll use some light objects instead.

This ability to control the access to an object can be required for a variety of reasons: controlling when a costly object needs to be instantiated and initialized, giving different access rights to an object, as well as providing a sophisticated means of accessing and referencing objects running in other processes, on other machines.

Consider for example an image viewer program. An image viewer program must be able to list and display high resolution photo objects that are in a folder, but how often do someone open a folder and view all the images inside. Sometimes you will be looking for a particular photo, sometimes you will only want to see an image name. The image viewer must be able to list all photo objects, but the photo objects must not be loaded into memory until they are required to be rendered.

Intent:

The intent of this pattern is to provide a placeholder for an object to control references to it.

Implementation:

The participants classes in the proxy pattern are:

Subject – Interface implemented by the realSubject and representing its services. The interface must be implemented by the proxy as well so that the proxy can be used in any location where the RealSubject can be used.

Proxy – Maintains a reference that allows the Proxy to access the RealSubject. Implements the same interface implemented by the RealSubject so that the Proxy can be substituted for the RealSubject. Controls access to the RealSubject and may be responsible for its creation and deletion. Other responsibilities depend on the kind of proxy.

RealSubject – the real object that the proxy represents.

Applicability:

The Proxy design pattern is applicable when there is a need to control access to an Object, as well as when there is a need for a sophisticated reference to an Object. Common Situations where the proxy pattern is applicable are:

Virtual Proxies: delaying the creation and initialization of expensive objects until needed, where the objects are created on demand.

Remote Proxies: providing a local representation for an object that is in a different address space. A common example is Java RMI stub objects. The stub object acts as a proxy where invoking methods on the stub would cause the stub to communicate and invoke methods on a remote object found on a different machine.

Protection Proxies: where a proxy controls access to RealSubject methods, by giving access to some objects while denying access to others.

Smart References: providing a sophisticated access to certain objects such as tracking the number of references to an object and denying access if a certain number is reached, as well as loading an object from database into memory on demand.

Related Patterns:

Adapter design Pattern – The adapter implements a different interface to the object it adapts where a proxy implements the same interface as its subject.

Decorator design Pattern – A decorator implementation can be the same as the proxy however a decorator adds responsibilities to an object while a proxy controls access to it.

 

Reference

https://javapapers.com/design-patterns/proxy-design-pattern/

 

 

 

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.

Today, in this final post of the semester for CS-343 I will be examining the JPA architecture. This is something I have been curious about after browsing articles on DZone for the past couple of weeks and seeing this topic pop up a lot, luckily they made a good introduction post this week. From the article: “The Java Persistence API is the Java standard for mapping Java objects to a relational database”, this is something that I have been wondering how to do since we started working with the REST APIs and our projects that have been using Java HashMaps for makeshift databases instead of something more permanent like SQL. This article briefly introduces and explains the functionality of the six key parts of the architecture for JPA. The article gives a diagram for these six units and the multiplicity of their relationships. The article then gives a simple example of mapping a simple Java POJO Student class into data for a database, using the student ID as the primary key. I was surprised at how easy this translation was, all it includes is a couple of tags for columns above the instance variables that designate the database column, and which one is the primary key to generate in the database. The article then creates an application class that uses the various entity classes to store a newly created student into a database. I liked the simplicity of the article as most introductory articles are on this website for what are advanced programming topics, but my biggest criticism is that this article has brief definitions for many of the elements of JPA and then links to an external site that further elaborates on them. I wished that the author put a bit more time and consolidated all of this information into one article for this site, instead of having a bunch of separate webpages on his own website. I also wish he showed in this post getting data from the database and translating it back into Java and performing manipulations on this data with methods. Overall it was a good introduction to a very useful topic and one that I would like to further look at. Going forward, I am much in favor of using this way of storing data as opposed to simple Java in-memory databases for entire applications like we did in our projects.

Source: https://dzone.com/articles/introduction-to-jpa-architecture

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.

Today I am looking at another design pattern. This one is the command design pattern, which is yet another Gang of Four design. They classify it as a behavioral pattern with object as the scope (GoF 223). I wanted to explore this one as reading through the different pattern descriptions in the Gang of Four book, this peaked my interested by its ability to separate requests from objects. The article gives a good summary of the idea of the pattern with a real-life example of a restaurant with a server taking an order from a customer and handing it off to a chef. It then further breaks down the pattern with the usual UML diagram and a helpful sequence diagram that shows the order in which the classes perform the pattern. I found this sequence diagram, along with the comments in the example program with code that show which class matches with which part of the diagrams really useful in this example, as the pattern goes through a couple of classes just to call a basic function on a simple object. Although this pattern does seem complex at first, it has a nice simplicity once you understand what all the classes are doing, and once you get the base created adding more functions is as simple as adding more command classes. The article then creates a simple example with Java of the command pattern using the various classes to switch a light bulb object on and off. I do like the idea of the pattern and its particular implementation in this example. It nicely breaks down requests into their own separate command objects that gives much greater control over requests across a program. I agree that the ability this pattern gives to create a log of function calls and add an ability to undo all functions called on an object is very helpful. I also agree with the author that it can get messy if you have a lot of functions that need to be implemented. As this pattern calls for a separate command class to be made for each function or method performed on an object, this can quickly add up depending on how many methods you need in your program. In the future, I will definitely remember this pattern and its useful ability to separate commands from the objects it performs them on.

Source: https://dzone.com/articles/design-patterns-command

 

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.

For my last blog for this class — Software Quality Assurance and Testing — I decided to look at what I could find about the subject in the news. After searching around, I found an article from Forbes that came out only a few days ago — December 17. The article was titled “AI In Software Testing: Will A Bot Steal Your Spot?”

My first impression before I read the article was, “Of course not! There will always be people whose job it is to test software.” Software is growing to touch every corner of our lives, and even if AI is incorporated, I would think it would be unlikely that they would entirely, or even partially, replace testers.

Halfway through the article, the author confirmed my skepticism by saying, “While it’s unlikely the testers will be wiped out, I think machine learning and other branches of AI will significantly alter the way software testing is conducted.”

The article seems to have a misleading title. The article goes on to give several examples of how robots will be useful for people, but they will be still be implemented by people, whose jobs are still be there, even with the robots. It didn’t even hint even some jobs would be lost. It just said the job would look different. Seems pretty obvious that new tools will come out that will change how the work is done. That is true for most all industries.

The article might as well been titled “Sharks in the Ocean: Will You Be Eaten When You Go Swimming?” And then once you read it says “probably not.” This is link bait at it’s finest. Have a sensationalized title for people to click on, and then say, “It’s not going to happen.” It would be one thing if it were titled something different.

However, at least I sighed a breath of relief when I read what the article concluded. I would hate for something that I have wanted to pursue as a career be automated before I even graduate.

I’m sure that many parts of the computer science industry that will change dramatically over my career. I hope like most people that I will always be able to find work, but I think that the field is going to be fairly stable for a long time. However, I’m sure there will be no shortage of headlines that have similar titles — “Is your job in jeopardy?” I also think that the article contents will usually say that it’s not.  I do think it’s a good idea to keep alert to changes in the industry because no career or company is invulnerable.

Work Cited:

https://www.forbes.com/sites/forbestechcouncil/2018/12/17/ai-in-software-testing-will-a-bot-steal-your-spot/#996553136710

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

AngularJS is an open source web application framework. It was originally developed in 2009 by Misko Hevery and Adam Abrons. It is now maintained by Google. Its latest version is 1.2.21. AngularJS is a structural framework for dynamic web applications. It lets you use HTML as your template language and lets you extend HTML’s syntax to express your application components clearly and succinctly. Its data binding and dependency injection eliminate much of the code you currently have to write. And it all happens within the browser, making it an ideal partner with any server technology.

GENERAL FEATURES:

• AngularJS is an efficient framework that can create Rich Internet Applications (RIA).
• AngularJS provides developers an option to write client-side applications using JavaScript in a clean Model View Controller (MVC) way.
• Applications written in AngularJS are cross-browser compliant. AngularJS automatically handles JavaScript code suitable for each browser.
• AngularJS is open source, completely free, and used by thousands of developers around the world. It is licensed under the Apache license version 2.0.

Overall, AngularJS is a framework to build large scale, high-performance, and easy to maintain web applications.

CODE FEATURES:

Data Binding – It is the automatic synchronization of data between model and view components.

Scope – These are objects that refer to the model. They act as a glue between controller and view.

Controller – These are JavaScript functions bound to a particular scope.

Services – AngularJS comes with several built-in services such as $http to make an XML Http Requests. These are singleton objects which are instantiated only once in app.

Filters – These select a subset of items from an array and returns a new array.

Directives – Directives are markers on DOM elements such as elements, attributes, CSS, and more. These can be used to create custom HTML tags that serve as new, custom widgets. AngularJS built-in directives such as ngBind, ngModel, etc.

Templates – These are the rendered view with information from the controller and model. These can be a single file (such as index.html) r multiple views in one page using partials.

Routing – It is concept of switching views.

Deep Linking – deep linking allows to encode the state of application in the URL so that it can be bookmarked. The application can then be restored from the URL to the same state.

Dependency Injection – AngularJS has a built-in dependency injection subsystem that helps the developer to create, understand, and test the applications easily.

ADVANTAGES OF ANGULARJS:

• It provides the capability to create Single Page Application in a very clean and maintainable way.
• It provides data binding capability to HTML. Thus, it gives user a rich and responsive experience.
• AngularJS code is unit testable.
• AngularJS uses dependency injection and make use of separation of concerns.
• AngularJS provides reusable components.
• With AngularJS, the developers can achieve more functionality with short code.
• In AngularJS, views are pure html pages, and controllers written in JavaScript do the business processing.

DISADVANATAGES OF ANGULARJS:

Not Secure – Being JavaScript only framework, application written in AngularJS are not safe. Server-side authentication and authorization is must to keep an application secure.

Not degradable – If the user of your application disables JavaScript, then nothing would be visible, except the basic page.

 

References:

https://angularjs.org/

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

https://www.w3schools.com/angular/angular_intro.asp

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.

Hello dear reader. This is my last blog for my Software Construction and Design and as a very important part of development I choose to talk in this blog post for REST API.

REST API stands for Representational State Transferee and provides a lighter weight compared to SOAP. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations, additional information needs to be provided. Most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP verbs (GET, POST, PUT, and DELETE) to perform tasks.
REST-based Web services output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can keep the output you need in a form that’s easy to understand and use within the language you are using for your application. The information you receive when using REST is a JSON formatted document containing the information you asked for. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.
In most of the part REST is easier and more flexible to use. To use REST you do not need to purchase any tools, Postman or Insomnia can be downloaded for free. REST though, is efficient as it uses the small message formats and it has a fast process.
There are some very strong reasons that you should be using REST. First, REST is the most popular choice of programmers to build APIs.  Also REST API is great on making the data available as a resource as opposed to service.
To create a REST API, the following six architectural constraints are needed: 1. Uniform interface, which means that the same resource should not have more than one URL; 2. Client-server separating, which means that the client and the server should act independently. 3. Statelessness, which means that there should never be any server-side sessions; 4. Cacheable resources, means that the server responses should contain information even though the data sent might or not be cacheable; 5.Layered system, which means there might be different layers of servers between the client and the server that returns the purpose; 6. Code on demands, which means that the response can contain code that the user can execute.

If I also refer to the previous blog about SOAP API I would say that there are clearly good reasons why REST API is a better choice to use when requesting/ expecting data and when you want to build your own program. However the decision is yours. I hope I have helped your CS journey. Till next time…

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

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

As I take my final step towards my journey in software C.D.A. this blog would be the last one regarding my journey with learning and researching topic related to my class Software Construction Design and Architecture. For this blog I will be talking about the blog “API management with Kong” by Alexander Melnyk. This blog is about the importance of API management and why does it matter. It also focuses on the Kong Architecture.

In the blog it explain why API management matter. The idea of API management is that it plays an important role when it comes to integration. Which can be done “by providing clear boundaries and abstractions between systems”. The blog also explains a few “ways to tackle the technical complexity and how Kong API gateway can help deal with it”. You may be wondering what is Kong it is an open source API gateway to manage RESTful APIs.” However the blog gives a better description of what and how it is use for. There are five components of Kong architecture:

1. nginx – “The core low-level component” also the most popular used web server.
2. OpenResty – “a web platform that glues nginx core, LuaJIT, Lua libraries and third-party nginx modules to provide a web server for scalable web applications and web services.”
3. Datastore – is a component that “uses Apache Cassandra or PostgreSQL to handle the storage of the configuration data, consumers, and plugins of all APIs.”
4. plugins – “are Lua modules that are executed during a request/response life-cycle. They enrich the API gateway with functionalities for different use cases.”
5. RESTful admin API – It is used to manage the API and provide an important tool to automate developers workflows.

The blog goes on and covers the Kong API gateway in action which “will show you how to create a minimal infrastructure for Kong API gateway. Then I will add an API and a security plugin to restrict the access to a specific user.” and then covers the consumers and plugins. If you have found this topic interesting or if your curiously left with question click on the title link above and read the blog the blogger does a much better job at explaining and getting the message across then I do.

Personally I really enjoyed reading the blog because it helped me realize that the Kong Architecture is in fact very useful and important. I also found the blog to be well written full of useful and important information that will benefit me as a software developer.

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.

For this week’s blog, I am choosing test-driven development what is and what it is not by Andrea Koutifaris.

Test-driven development(TDD) is a software development process that relies on the repetition of a very short development cycle. First, developers write a failing test case then produces the minimum amount of code to pass that test and finally refactors it to acceptable standards.

There are three processes that are often described using TDD: Red/Green/Refactor cycle.

Red phase

In the red phase, you write a test that uses a piece of code as if it were already implemented. Without implementation and not thinking about production code, this phase is where you concentrate on writing a clean interface for future users and where you design how your code will be used by clients. The Red phase is the most important phase and it is the rule that makes TDD different from regular testing. You write tests so that you can write production code and not test your code.

Green Phase

For developers, the green phase is probably the easiest part of a TDD. This is the part where you write code but not the whole implementation, just enough for the test to pass. Make all the alarming red on the test report becomes green. In this phase, you do not need to worry about violating best practices since we will do that in the Refactor phase. This phase exists to make your task simpler and less prone to error.

Refactor Phase

In this phase, you are allowed to change the code while keeping the tests green. But there is something mandatory, that you have to remove code duplication. In this phase, you can worry about algorithms and such to make the program better. This is the phase where you can show off your skills to your users.

 

I really liked reading this blog and I kind of liked the idea of Test-Driven Development. I think doing it this way creates more code coverage and thus fewer bugs later on. This kind of development is a bit unique to me since I have only done behavior-driven development so far. Test-driven development changed my mind in a way. I think that doing test-driven development is more beneficial, kind of like reverse engineering, we start from something that we know is gonna work then proceed from there.

 

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