Author Archives: Gloris Pina

Adapter Design Pattern

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!




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.

Singleton Design Pattern

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 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!



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.

Proxy Design Pattern


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.


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



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.


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.






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.


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.


  • 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.


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.


  • 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.


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.



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.

REST – Representational State Transfer

REST is a term coined by Roy Fielding to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.  It represents the state of database at a time. REST is an architectural style which is based on web-standards and the HTTP protocol. In a REST based architecture everything is a Resource. A resource is accessed via a common interface based on the HTTP standard methods. You typically have a REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.  Every resource should support the HTTP common operations. Resources are identified by global IDs. REST allows that resources have different representations, e.g., text, XML, JSON etc.

HTTP Methods

The PUT, GET, POST and DELETE methods are typically used in REST based architectures. The following table gives an explanation of these operations:

POST –> INSERT (adds to an existing resource)

PUT –> UPDATE (overrides existing resource)

GET –> SELECT (fetches a resource, while the resource is never changed via a GET request)

DELETE –> DELETE (deletes a resource)



Purpose Method Incorrect Correct
Retrieves a list of users GET /getAllCars /users
Create a new user POST /createUser /users
Delete a user DELETE /deleteUser /users/1
Get balance of user GET /getUserBalance /users/1/balance


Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

/cars instead of /car

/users instead of /user

/products instead of /product



  • Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET method or Query parameters for state changes.
  • If a resource is related to another resource use sub resources.
  • Both, client and server need to know which format is used for the communication. The format has to be specified in the HTTP-Header.
  • Make the API Version mandatory and do not release an un versioned API.
  • Use a simple ordinal number and avoid dot notation such as 2.5
  • Use a unique query parameter for all fields or a query language for filtering.
  • Allow ascending and descending sorting over multiple fields.
  • Use limit and offset. It is flexible for the user and common in leading databases.
  • To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths.



Thank you for your time!





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.

TypeScript and Object-oriented Programming Fundamentals

pasted image 0

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.




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.

Unified Modeling Language (UML)

curso-de-uml-2-Nowadays, Unified Modeling Language has made it easier to describe the software systems, business systems, and any other systems. Their graphics show an explanation with words and pictures also, which proves that UML is practical and anybody should be able to use it. UML first appeared in 1997 and its content is controlled by the Object Management Group. The primary contributors to UML are Grady Booch, James Rumbaugh, and Ivor Jacobson.

UML Basic Notation


Why UML?

UML has been able to unify the terminology and different notations, which leads to a great communication between all parties, on different departments of any company. It is also much easier for co-workers to get access or transfer information, while they are working on the same project. UML seems to be a very powerful modeling language, which makes it perfect to use, even for small projects. Stereotypes can extend its functionality if it is not sufficient for some kind of projects. UML did not come from anywhere, it started from real-world problems with existing modeling language that needed modification or transformation. This is why it is widely supported because it guarantees usability and functionality, based on real-life problems.

UML 2.0 defines 13 different types of diagrams, where each of them may be expressed with different details. They are classified into three categories: Structural diagrams, The Behavioral Diagrams, and The Interaction Diagrams.

–          The Structural Diagrams represent elements that are static in nature and they can be fundamental to the UML modeling of a system. This contains:

The Class diagram, The Component diagram, The Composite Structure diagram, The Deployment diagram, The Object diagram, The Package diagram.

–          The Behavioral Diagrams represent the modeling of how the system functions. This contains:

Use Case Diagram, Activity Diagram, State Machine Diagram.

–          The Interaction Diagrams represent how the flow of data and control work on the modeling system. This contains:

Communication Diagram, Sequence Diagram, UML Timing Diagram, Interaction Overview Diagram,


As a conclusion, the Unified Modeling Language is an internationally accepted standard that is used for Object-Oriented Modeling and can be used to represent a model that adopts the best software architecture practices.


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.

Hexagonal Architecture

Today I am going to discuss one of the software architectures: Hexagonal Architecture. Its purpose is to reduce the amount of time we need to maintain and modify the code, in order to improve the maintainability. The more we increase the maintainability, the less work is required to achieve the tasks. This software architecture is not called “Hexagonal” for no reason. It is actually represented by a hexagon which is very flexible, and it allows you to make changes anytime, because of the independent layers. Each side of the hexagon has an input, an output, and a domain model. The three components of a Hexagonal Architecture are Domain Model, Ports, and Adapters.


Since the Domain is placed in the middle of the hexagon, it makes the Domain the center layer of it, which works independently in the architecture. Also, the Domain Model is used to maintain all the business data and the rules related to that data.

Port is the way to get to the business logic, or in other words, it serves as an entry point. There exist primary and secondary ports. The primary ports are functions that allow you to make changes, and they get called by the primary adapters. The Secondary ports are the interfaces created for the secondary adapters, but other than the primary ports they get called by the core logic.

Adapter serves as a bridge to connect the application and the maintenance that is needed for this application. A primary adapter is an essential adapter which connects the user and the core logic through a piece of code. It might be a unit test for the core logic. A secondary adapter is an implementation of the secondary port (interface).

I found this article interesting because the writer knows who the audience is and explains everything in detail. Also, the topic is related to our CS-343 class and this might be a good start to get into the world of software architecture. Nowadays, we are looking for simplicity and flexibility and this is what Hexagonal Architecture is about. According to the article that I chose the benefits of a Hexagonal Architecture are:

– Agnostic to the outside world

– Independent from external services

– Easier to test in isolation

– Replaceable Ports and Adapters

– High Maintainability

Apparently, Hexagonal Architecture makes the work easier and more efficient, based on this article:

Thank you for taking the time to read my blog!




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.

Introductory Blog CS-343

Hello everybody!

My name is Gloris Pina. I study Computer Science in Worcester State University.  CS-343 is one of the classes that I am registered for this semester. This blog post is an introduction to this class. CS-343 will be another challenge to accomplish and the blog that I just created would be a good opportunity to share my knowledge professionally. I hope you will enjoy my blog posts weekly!

Thank you for reading!

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.