Category Archives: CS-343

Writing Efficient Code

In the second part of Brandon Gregory’s blog post “Coding with Clarity: Part II“, he starts with the assertion that “Good programmers write code that humans can understand”. In the spirit of clarity, Gregory continues to elaborate on solid design principles that are helpful in software engineering.

The first principle is the Law of Demeter, or as Gregory puts it “the principle of least knowledge”, and describes this principle as an application of loose coupling, another design strategy that states one part of a program should not rely on others. Adhering to this principle will help ensure flexibility if new features are added or modified.

An example Gregory uses that demonstrates this principle is the use of getter/setter methods to provide access to class data as opposed to allowing classes to directly access data. By applying this tactic, it ensures that future modifications do not mess up any other parts of your program, as all modifications will be in the getter/setter methods.

The next programming practice is the Interface Segregation Principle. This is to make sure no object contains methods it doesn’t use. If a class has a bunch of methods, and not all methods are used for each instance, the better strategy is to separate that class into specific interfaces or sub classes. This is a similar goal as the strategy design pattern that we discussed in class.

However, Gregory warns us that abstraction can be taken too far. It is possible to abstract so much that the program contains an excessive number of interfaces or sub classes. The author reminds us that the goal of abstraction is to reduce complexity.

The final principle in the article is the open/closed principle. This assertion is that software should be open for extension but closed for modification. If the program is designed correctly, the implementation should perform as specified and should not be modified. Instead, to change functionality of the program, all that should be done is adding functionality, and not changing any of the existing code.

I very much found this two part series of “coding with clarity” helpful.  Almost all of the principles Gregory explains have been applicable to content we have covered in class. I found his writing style easy to follow and the particular examples he uses to demonstrate the principles are cogent and illuminating.  I recommend them to everybody looking to improve their design knowledge.

 

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

Factory Design Pattern – Factory Method

In this week’s blog post I decided to share an informative post by Henri Idrovo on dev.to detailing the implementation and usage of the factory design pattern, specifically the “Factory Method.” Henri starts the blog by introducing the problem the factory design pattern is aiming to solve: using the ‘new’ keyword creates dependencies on concrete classes within our program. When many new objects are being created, this tends to get out of hand. Henri introduced the dependency inversion principle, stating “Depend upon abstractions. Do not depend on concrete classes.”

To show how to implement and improve your code using the factory design pattern, an example is introduced that involves a Pizza Store that has to create different types of pizzas. Without the design pattern in place, every type of pizza you would want to make would require another if-statement, so clearly something needs to be fixed. In order to use the factory pattern, we need to separate what is likely to change from what is not, and put what will change in a class of their own.

In Henri’s example everything that is common to pizza creation is placed in an abstract creator class, and the specifics are placed in concrete creator classes that extend the abstract class. Similarly, the different kinds of Pizza are each given their own concrete product class that extends the abstract Pizza class.

The factory method seemed hard to understand at first, but after going through the examples given in the blog it became clear to me, and the advantages of using the factory method are clear. By relying on abstractions instead of concrete classes, you are removing dependencies within your code and making it much more open for modification. Whereas prior to applying the method, the handling of creation of pizza objects was handled within the PizzaStore class itself, it is now handled within concrete sub-classes that can also handle different categories of pizzas. Also, personally it is easier to read the code of the PizzaStore class after applying the factory method, and it is much more clean in the abstraction. I can see the factory method being useful in any situation where you have to deal with the creation of a lot of categorically related but different objects.

https://dev.to/henriguy/design-patterns-factory-pattern-part-1-6k0

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

factory design pattern

This week blog post is going to be about one of the creational design patterns, Factory Pattern. Factory pattern has many advantages:

  1. “Factory design pattern provides approach to code for interface rather than implementation.
  2. “Factory design pattern removes the instantiation of actual implementation classes from client code. Factory pattern makes our code more robust, less coupled and easy to extend. For example, we can easily change PC class implementation because client program is unaware of this.
  3. “Factory pattern provides abstraction between implementation and client classes through inheritance.

When we have a super class, which can be an (interface, abstract class, and concrete class) with many sub classes and we want to return one of the subclasses based on a specific input, this can be done with Factory Design. The benefit of factory design is that we don’t have to instantiate a class every time we want to use a class instead we can just call the Factory class.

For example, if we had an interface named Game System and we created more than one sub class that implements it (ps4, Xbox, and pc) and then we wanted to use one of those objects in a test class, we would have instantiated one of the sub class every time we created an object from the class. This way is very tedious, that’s why Factory design is so helpful. Instead creating a object every time, we can create an Game system factory which allows us to input for example enter a string name “ps4” and create a ps4 class instead creating for example GameSystem gs = new ps4(); every time.

I think factory design pattern should be used mostly every time if there are more than one sub classes just because it removes clutter and simplify the code to be more readable. From my personally experience I think factory design patter help me think more about organization when coding. I always think of ways to make my code more reusable after reading this article. All in all, Factory design pattern is very helpful and is an important method when it comes to Object oriented programming.

https://www.journaldev.com/1392/factory-design-pattern-in-java

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

Mediator Pattern

Between many design patterns Mediator is one of most used in today’s software world. In this pattern, the object encapsulates the processes between other objects, without asking other objects to interfere. We are going to analyze a real-world example that uses the mediator design pattern. This pattern serves as a go-between operator, so other components … Continue reading Mediator Pattern →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

OOP Basics

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time.
I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly.
The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declaring objects, how difficult it would be to keep track of everything and make everything work properly. 
This video was made for someone who might be interested in computers, but this is not their specialty. Although this was helpful for me in getting a better background on what OOP is, I felt it did not go far enough. I would have liked it if it went a step further and explained some of the next topics that would logically follow. The video was under fifteen minutes, and most of the videos in the channel are that length, so there wasn’t that much room to expand. 
He said that he would go over the topics like inheritance in another video, but I searched through all the videos with him, but I could not find the “OOP part two” or anything of that nature. I don’t like that the channel doesn’t cater to people with a computer science background, but on the other hand, there are some interesting looking videos that I would like to watch after this. My next step will be to learn about functional programming because I do not have any experience in that area.

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

“The Psychology of Design”

In his post “The Psychology of Design”, Blogger Jon Yablonski writing for the blog “A List Apart”, discusses the importance of software developers to understand some principles about heuristic psychology that are helpful in improving user experiences and overall design.

Yablonski begins by explaining the concept of Hick’s law, the notion that the amount of time it takes a user to respond to a situation depends on the volume of information the person is presented with. He uses the example of a television remote, and how as the number and complexity of devises increases, the more confusing the remote controls become. But by abstracting the features to those only absolutely necessary, we’re able to create a much more user friendly product, as demonstrated by the apple TV remotes.

The author also goes into the idea of Miller’s law, which is the assumption that people can commit to memory seven plus or minus two different objects. Yablonski goes into strategies designers have used to work around this inconvenience; namely chunking. Chunking is used to break up large or complicated amount of information into chunks, like the digits in a phone number, or breaking up a news page in discrete parts.

Finally, Yablonski explains Jakob’s law, that people tend to form their expectations based on previous models that we have learned. For example, most video game controllers tend to have a similar arrangements of inputs. This serves to lower the learning curve required in adopting a newer model.

Personally I think heuristic psychology is very useful in the area of software development. Understanding how our minds process information is an integral source of data to help us achieve our goals of creating efficient, user friendly software. By applying smart strategies like design patterns to help implementation, combined by the insight of psychology, we should be able to handle a broad range of situations and have a good array of tools to help solve the problem.

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

How to Make the Perfect Singleton

In our Software Construction class, we have been going over the design patterns used by developers everywhere. Our last test covered all of the design patterns, and after I got the test back, I decided to research more into the design patterns topic and I found the article, “How to make the perfect Singleton?” I found this article whilst browsing the internet looking for other articles, and this one jumped out at me.

The article starts off by discussing the purpose of the Singleton. I liked this section of the article because it provided some specific examples of when this pattern would and should be used. For example, it said it is “used when you have to control resources” (Patel), and it is used in database connections or sockets.

The article then goes on to show the reader how to create the perfect Singleton. It explains how to initialize it, and it explains how to make the class thread, reflection, and serialization safe. I actually didn’t know what it meant to make a class thread, reflection, and serialization safe until I read this article.

The interesting part of this article is how many new terms it introduced me to. The volatile keyword was brought up in this article, and I personally haven’t seen this keyword anywhere in my few years at Worcester State. The volatile modifier makes it so that the write of a certain variable is guaranteed to happen before the read of said variable. I also learned that making classes thread safe is essential for any “multi-threaded application environment” (Patel). They use Android applications as an example. I also learned how to make my Singleton class safe from Serialization, which is simply just preventing others from creating new instances by serializing and deserializing the singleton. I also learned how to prevent Singleton failure due to reflection. This was also very simple as you just have to throw a run-time exception in the constructor.

This article was a great read and contained a lot of useful information. I plan on using this information that I obtained in the future when I create more classes using the singleton pattern.

 

Link: https://medium.com/exploring-code/how-to-make-the-perfect-singleton-de6b951dfdb0

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Journey into Design Pattern a Adapter Pattern Explanation

As I take another step towards my journey in software C.D.A. I dive into Design Pattern, where I will be focusing on one of the patterns known as Adapter pattern. While searching in the internet I ran across a blog called Design Pattern Explained – Adapter Pattern with Code Example by Thorben Janssen.  This blog talks about Adapter Pattern which actually is one of the many Design Pattern type. This topic is chosen because it was one of the pattern talked about in my Software Construction, Design, and Architecture class. Since the blog by Thorben Janssen talks about the topic related to a class discuss topic, I choose this blog to write about it and summarize its content in my blog. The content in the blog is about the Adapter Pattern of Design Pattern. I will give a summary of what the blog was about and what it explained from my point of view and understanding.

According to Thorben Janssen research on Adapter Pattern, there are two different version of it. The type that uses inheritance and the type that uses composition.

What is Adapter pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say your at your friends house and you have an i-phone USB charger cable but no power adapter, and lets say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

In the blog “Design Patterns Explained – Adapter Pattern with Code Example” by Thorben Janssen he gives an applied example of the adapter pattern he referrers it as Brewing Coffee. I highly suggest you to click on the title so you can check out the example and see how he implements the adapter. I will end my blog here and let you do your own research on adapter pattern.

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.

The Process of Reviewing Code

Since CS-343 is meant to teach us about how to craft and design better code, I figured it would be important to first identify the key components of reviewing code, whether it be your own or someone else’s. To do this, I used the article “Yet Another Code Review Best Practices” by Pawel Ochman as my main reference.

He begins by describing some of the reasons for reviewing the code, leading into a few tips and things to look for, ending into a note about how to maintain the code after your review. With all of this information, a few key things stuck out to me:

  • Prior to reviewing the code, you must create a goal. There can be a single or multiple goals, but no matter what all code reviewers must have common goal(s). Some examples of these goals include:
    • Eliminating bugs at an early stage
    • Improving code quality
    • Increasing knowledge about the project
    • Learning from each other
  • The most important principles to follow when reviewing code are quality and motivation. In this context, quality is the principle of making sure that every time you review code, you review it to the best of your ability. Similarly, motivation is the principle that plays as a constant reminder of the values of code review to keep the team/yourself feeling positive about the review/editing.
  • Positive feedback after reviewing the code is important for whoever’s code it is. The values of code review outweighs allowing it to continue to be inefficient or ineffective in functioning/solving the problem (whatever that may be).
  • The most important point is that you don’t have to be an expert:

It’s a great chance to learn something new. If you are not sure whether solution is correct, you can start a valuable discussion. As a team member you should be able to work on any area of the project. Don’t allow any person to be the only expert in specific part of an application. You should be able to replace anyone in case of his absence.

All in all, this was a great article to learn from as it allows you to see the benefits of  code review through each stage. With small pieces of advice, it transforms what may be a painful process into a more positive one.

 

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Java Singleton Design Pattern Best Practices with Examples

This week blog post is about Java Singleton design pattern. The reasons for Singleton pattern are to restricts the instantiation of a class and ensures that only one instance of the class exists. This article explains and show examples of the many different approaches of Singleton pattern implementation, the problems with the approach.

The approaches of Singleton pattern implementation:

  1. Eager initialization – pros: easiest way to create a singleton class | cons: instance variable is created even though it might not be used.
  2. Static block initialization – Similar to eager initialization but provides option for exception handling.
  3. Lazy initialization – This is the approach that was we used in class and it’s a completely fine for a single threaded environment, but potential can cause problems for a multi-threaded environment.
  4. Thread Safe Singleton – resolutions for Lazy initialization but reduces performance. Requires synchronization.
  5. Bill Pugh Singleton implementation – Best method for singleton implementation. Contains a inner static helper class by doing so the instance is not created unless someone calls on the getInstance() method. Doesn’t require synchronization.
  6. Using Reflection to destroy Singleton Pattern – This approach destroyed the singleton pattern.
  7. Enum Singleton – resolution for reflection method. Not flexible. Any enum value is instantiated only once.
  8. Serialization and Singleton – Use to store it in file system to retrieve it later. Cons: when deserialize it creates a new instance of the class.

I found this article very helpful with understanding Singleton design. This article explains to me when to use and the consequences that comes with each different implementation. The content of this blog was the best. The example code of this article was very clear and made easier to understand the materials. This change my way of using this method because I now know which method to choose in certain situation. The lazy initialization will be used more while I’m in school, but I think Bill Pugh method will be used more in the future because it’s very popular and it’s easy to understand. I agree with all the contents, but I read the comments of the other readers and they had some issue with some of the content which I have to read more about the subject to find out what’s right and wrong.

https://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-examples

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