What is the RESTful architecture style and what is it good
for? Well I am here to break that down for you. REST stands for representational
state transfer, and it is an interface that can be implemented in order to help
with abstracting resources. In order for a system to be considered RESTful,
they must implement 5 guiding principles. The first principle is client-server
which deals with the separation of user-interface and data storage. The next principle
is that it must be stateless, meaning when information is requested, all the information
must be present and cannot be stored on the server. The next principle of REST
is that the data must be labeled either cacheable or non-cacheable. If the
information is cacheable, it is stored on a client cache. The fourth principle
deals with having a uniform interface. The next principle is the layered system
which allows for a hierarchy of layers to implement constraints.

Now that the principles have been laid out, the next main
part of REST is the information and data it deals with. A resource in REST is
the abstraction of information. Resources can be anything containing a name from
documents, pictures, and so on. REST then uses resource identifiers to be able
to find what resource is needed. Resources contain resource representation,
which is a timestamp of the resource containing the data, metadata, and hypermedia
links. REST contains resource methods which can be used for working with the data.
Many people associate REST with HTTP methods of GET/PUT/POST/DELETE however
since REST has a uniform interface, the user will be able to decide which
resource methods to use. However, with REST you are able to utilize these HTTP
methods in order to help with resources. The most common implementation has GET
to retrieve resources, PUT to change or update a resource and POST to create a
resource. Obviously DELETE is used to delete resources.

RESTful API’s are very beneficial when working with cloud
computing and working with the web. Because REST does not store any information
between executions; is stateless, this allows for the for scaling. This also
means that the if anything fails, it will be easy to re-work since nothing was
stored on the server. This makes it particularly useful for websites as well because
a user will be able to freely interact with the website while not storing any
information with-in it. If you want to read more on REST and RESTful API, look
into these two websites.

https://restfulapi.net/

https://searchapparchitecture.techtarget.com/definition/RESTful-API

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

In many programs there will be an action taken only when something else has changed. For example, if there was a security app, you would not want it to continuously send you alerts that everything is fine, only when there is an actual emergency. This is where observers come in handy and in specific observer design patterns. Imagine you were creating an alarm system for inclement weather. Whenever there was inclement weather, an alarm would sound, a alarm message would appear on a phone, etc. Without observers, a person would need to run a clock that constantly checks for updates in the weather. By doing so in this process, there is a big strain on hardware. Observers send a signal when there is an update and does not require the constant checking for updates. When using observers, the design pattern should be set up such that there exists an interface called subject. This subject interface will be used to register and unregister observers, notify observers and get an update from the subject. The next interface will be the Observer interface which will contain an update method for the observer and a setSubject method, which is used to attach the subject to the observer. From here you will be able to implement these two interfaces. While implementing the Subject interface you will be able to create a class that overrides register, unregister and update the observer. When implementing the Observer interface, you will be able to override the update which allows for you to implement what the observer needs to be checking for. This allows for the user to have control over what the system is checking for. When that observer notices a change, it will be able to send a signal down to whatever class has extended subject and send out whatever notice must be sent when this event is triggered. By using this type of design pattern, the user is allowed to be very flexible while saving strain on the hardware that would normally be placed there by clocks. Many API’s use this type of design because as mentioned before, if an API had to have a clock running that was checking if someone had pressed a button every so-often, it would be chaos. The API is able to implement an observer for the buttons and when that button is pressed it updates the subject and executes whatever that button was programmed to do. This website gives a great breakdown of the design pattern and how to implement it.

Observer Design Pattern in Java

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

When you think of the word smell, your first thought
is probably not computer design. Design smells are a vital part of designing
clean, readable and re-usable code. In total there are 7 main design smells.
They are rigidity, fragility, immobility, viscosity, needless repetition,
needless complexity and opacity. The reason they are called smells is because when
there is a “high smell” of one of these terms it means there is probably poor
code. According to Wikipedia, the origin of the term design smell was originally
from code smell which was in Martin Fowler’s book Refactoring: Improving the Design of Existing Code.

(https://en.wikipedia.org/wiki/Design_smell)

In this book the term code smell was essentially the
same as a high smell/bad smell would indicate a deeper problem in the code,
rather than what was on the surface.

The first design smell is rigidity. When code is has
high rigidity, it means there is often a lot of code that is hard-coded in. This
causes the code to become rigid because small changes can cause a much larger
impact through-out. In order to avoid a high rigidity smell, code should be
dynamic and able to fit the system it is in. If there is too much hard-coding
it will be very tough to make changes later on.

The next design smell is fragility, and this is
similar to rigidity with a few exceptions. Fragility is the tendency of code to
break when a small change is made, similar to rigidity. The main difference between
these two is with fragility, the areas that suffer are often unrelated to the
changes made. With rigidity, the changes directly affect the code related.

The third design smell is immobility. For a lot of
code to be useful, it needs to be able to work with other systems as well. With
immobility, the code or program could be beneficial to other areas but there is
too much effort/risk to be able to successfully integrate it.

The fourth design smell is viscosity which means that
code can become “thick” and hard to work with. When you are designing a
program, you want to be able to modify it along with the design, but “hacks”
can be done to quickly fix the issue. The problem is that the more hacks in the
program, the less the program sticks to its design. This cause a lot of extra
code and the program becomes highly viscous. It is important to know the impact
of these small hacks and how to limit them.

The next design smell is needless repetition, which is
pretty straight forward. In a program, you do not want to have to repeat the
same code over and over. Instead find ways to integrate and abstract the code
for re-usability.

The next design smell is needless complexity, again,
pretty straight forward. This can happen when a program includes sections that
are not yet utilized but “could be”. That extra code is clogging space and has
no benefit.

The last design smell is opacity. Opacity simply means
to become less clear. This can happen when there are many changes to a program
but no effort to keep the code clean and organized. Eventually the code will
become foreign to all that had worked on it before without proper care.

Keep all these design smells in the back of your mind
next project!

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Many times, people go into projects without much planning
before-hand which can cause many problems to arise. UML class diagrams can come
to be your saving grace. With these diagrams you are able to plan out how the code
will be set up down in a neat organized diagram. In these diagrams, the top section
depicts the name of the class, the middle section depicts the attributes and
the bottom portion is what lists the methods of the class. The top section will
be bolded to indicate that it is the class name. This top section however can
say whether or not the class is abstract, concrete or an interface. If the name
is simply just bolded, the class is concrete. If the title is italicized, then
the class is abstract. If the class is an interface, the top section will have
the class name bolded and <<Interface>> listed above the name.  In these middle sections you are able to
specify a lot about the attributes of the class. Any variable will be listed
with a minus sign beforehand and the data type following. If any of these
variables are static, then they must be underlined. This allows for someone to
seamlessly set-up the class without having to worry about including the correct
variables and data types. As stated before, the bottom section will contain the
methods of this class. These methods will contain the name of the parameter (if
applicable) and the data type of that method. If the method returns a data
type, this will be listed after the parameters. UML diagrams don’t stop there
though. What I was describing was one box/class, while UML diagrams can contain
many, with indicators to show the relationships between them. Arrows are used
to show relations between classes. An arrow going from one class to another
with a hollow white tip stands for inheritance. When an arrow is going from one
class to another with a dotted line, that represents implementation. A solid
black arrow means there is a reference from one of those classes to another. By
using UML diagrams, you are able to set up one’s entire program before writing
any actual code. This allows for anyone else to be able to read and understand
the code by simply going through the diagram. UML diagrams gives the coder the
ability to write clean flowing code. Below is an article which goes in depth
more with UML diagrams and also gives examples.

http://agilemodeling.com/artifacts/classDiagram.htm

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.