Today I will be talking about an article called “Builder Design Pattern” put out by JournalDev.com. According to the article, the builder design pattern is used to fix some issues that arise when the factory and simple factory design patterns are implemented. The article points out three major problems that come up when using the factory patterns. The first problem is that there can be too many arguments to pass to the factory, which causes error due to the factory not being able to keep track of order. The next problem is that all the parameters must be passed to the factory. If you don’t need to use the parameter, you still need to pass null to it. The last problem occurs when object creation is complex. The factory will become complex, and it will difficult to handle. So what’s the solution to all of this? The builder pattern.

So what is the builder pattern? The builder pattern builds objects by individual step, and uses a separate method to return the object when it has been created. This is a great way to implement a “factory” pattern when the object you are trying to create has a large number of parameters. The article uses an example of the builder pattern by writing a java program that builds computers. Two classes, Computer and ComputerBuilder are used. The Computer class has a private Computer constructor, which has the required parameters as arguments. The Computer constructor sets all of the parameters, including the optional ones. Then the ComputerBuilder class is called; note this is a nested class. This class, in addition to being nested, is also static because it belongs to the Computer Class. The ComputerBuilder Class has a ComputerBuilder method which is public, and this method sets the parameters as this.parameter. The ComputerBuilder Class has two other methods used to set the optional parameters as this.parameter. The final method is a builder method, which in this case is public Computer build(), and this method will call the this.parameter arguments to build a computer object. Then it will return the object.

I chose this topic because I have experienced the problems mentioned above when using the factory pattern. If there are a lot of parameters to be passed, it can become extremely tedious to code. It also becomes very difficult to keep track of what’s happening as the code becomes more cumbersome to handle. I will definitely have to try implementing the builder pattern because it seems to function like the factory pattern, but in a simpler, easier to understand way. I really like the idea of only having to worry about required parameters and being able to set optional parameters outside of the constructor class. This eliminates having to pass null to the constructor, which should help with the compile time errors. This article uses java example, and it helped me really understand the code as well as the idea behind the code.

Here’s the link: https://www.journaldev.com/1425/builder-design-pattern-in-java

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

This blog post covers 9 anti-patterns that are common in software development.

1. Premature Optimization – Optimizing before you have enough information to make conclusions about where and how to do the optimization. This is bad because it is hard to know exactly what the bottleneck will be before you have empirical data.
2. Bikeshedding – Spending excessive amounts of time on subjective issues that are not important in the grand scheme of things. This anti-pattern can be avoided by prioritizing reaching a decision when you notice it happening.
3. Analysis Paralysis – Over-analyzing so much that it prevents action and progress. A sign that this is happening is spending long periods of time on deciding things like a project’s requirements, a new UI, or a database design.
4. God Class – Classes that control many other classes and have many dependencies and responsibilities. These can be hard to unit-test, debug, and document.
5. Fear of Adding Classes – Fear of adding new classes or breaking large classes into smaller ones because of the belief that more classes make a design more complicated. In many situations, adding classes can actually reduce complexity significantly.
6. Inner-platform Effect – Tendency for complex software systems to re-implement features of the platform they run in or the programming language they are implemented in, usually poorly. Doing this is often not necessary and tends to introduce bottlenecks and bugs.
7. Magic Numbers and Strings – Using unnamed numbers or string literals instead of named constants in code. This makes understanding the code harder, and if it becomes necessary to change the constant, refactoring tools can introduce subtle bugs.
8. Management by Numbers – Strict reliance on numbers for decision making. Measurements and numbers should be used to inform decisions, not determine them.
9. Useless (Poltergeist) Classes – Classes with no real responsibility of their own, often used to just invoke methods in another class or add an unneeded layer of abstraction. These can add complexity and extra code to maintain and test, and can make the code less readable.

I chose this blog because anti-patterns are one of the topics on the concept map for this class and I think they are an interesting and useful concept to learn about. I thought this blog was a very good introduction to some of the more common anti-patterns. Each one was explained well and had plenty of examples. The quotes that are used throughout the blog were a good way of reinforcing the ideas behind each anti-pattern. I will definitely be keeping in mind the information that I learned from this blog whenever I code from now on. I think this will help me write better code that is as understandable and bug-free as possible.

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

Link to blog: http://www.programmr.com/blogs/5-solid-principles-object-oriented-software-design

This blog gives the description of the 5 different types of design principles. These principles include the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and the Dependency Inversion Principle. The acronym “SOLID” represents these principles in the given order:

S – Single Responsibility Principle

O – Open-Closed Principle

L – Liskov Substitution Principle

I – Interface Segregation Principle

D – Dependency Inversion Principle

Single Responsibility Principle:

“A class should only have one reason to change” is how the author of this blog describes this principle. This principle states that every class in your software should have one and only one responsibility.

Open-Closed Principle:

“Software entities should be open for extensions, but closed for modification.” This means that software systems should be available for change. Customers will request new features and changes to existing features. Designing a system such that changes or extensions in requirements can be done by adding subclasses instead of changing existing code is a way to avoid rewriting an entire system.

Liskov Substitution Principle:

“Derived classes must be substitutable for their base classes.” This means that there will be some implementation of inheritance from understanding inheritance hierarchies and traps that can cause the open/close principle to fail with certain hierarchies. This principle fixes the violation that a function causes towards the open/closed principle.

Interface Segregation Principle:

“Make fine grained interfaces that are client specific.” This means that client code should not be aware of such a non-cohesive class as one unit. The class should have multiple interfaces and the client code should only be aware of the interface which is specific to its needs.

Dependency Inversion Principle:

“Depend on abstractions, not on concretions.” This means that this principle attempts to prevent a tangle of dependencies between modules by stipulating that entities and high level modules must not depend on concrete implementations but should depend only on abstractions.

The author of this blog identified the five design principles in a way that is easier to understand. He highlights the main concepts by providing a brief one sentence description about each principle. The acronym S.O.L.I.D. also makes it easier to understand on which design principles are which. I chose this blog because I wanted to know more about certain design principles. I previously knew the Single Responsibility and the Open-Closed principle, but didn’t know the remaining three. Understanding these principles will help me in my future career because there will be many different principles I will need to apply as a video game developer considering that there will be many different design principles involved for coding games.

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

We’ve been going over the concept of design patterns during the past few weeks, so I thought it would be appropriate to do some research on those most commonly used. Subham Aggarwal has an informative blog on the topic entitled Top 3 Design Patterns in Java. We’ve been examining design patterns written in Java, so I feel that Subham’s blog is a great one to discuss. He provides excellent examples written in the Java programming language.

Subham first explains that design patterns are generally creational, structural or behavioral. He then introduces three design patterns that he speculates are the “top three” used in Java.

1. Singleton Pattern
2. Factory Pattern
3. Decorator Pattern

I covered the Singleton pattern in a recent blog so I will try not to duplicate anything posted in that entry. One aspect that stands out in Subham’s explanation that I ought to mention is his assertion that Singleton is one of the most “inappropriately used” design patterns in Java. Based on what we’ve learned so far, it seems to me that the true intent of Singleton is to have just one instance of each Singleton class. But Subham states that many developers seem to manipulate the pattern in an attempt to have Singleton classes act as global variables, which is not what this pattern is intended to do. Based on Subham’s breakdown and what we’ve learned in class, I would have to say that I believe the Singleton design pattern seems to be a creational one.

Next discussed is the factory pattern, which Subham describes as a way to create certain objects based on the user’s specification. For instance, he provides the following code as an example:

public class ShapeFactory {
 
 // use getShape method to get object of type shape 
 public Shape getShape(String shapeType) {
     if (shapeType == null) {
     return null;
     } 
     if (shapeType.equalsIgnoreCase("Quadrilateral")) {
          return new Quadrilateral();
     }
     else if (shapeType.equalsIgnoreCase("Parallelogram")) {
          return new Parallelogram();
     }
     return null;
     }
}

Something I’d like to add on the subject is perhaps it would be a good idea to develop an enumeration type to define the names of the above given shapes as constants. Also, based on the fact that we are offering a way to create objects here, I would have to say that the factory design pattern is a creational one as well, along with Singleton.

Last but not least, Subham describes the decorator design pattern as one commonly used in Java. The idea here is to “add new functionality to an existing object without changing its structure.” Thus I would have to agree with Subham that this design pattern seems to be a structural one. I do not think we’ve discussed this in CS-343 yet, but I remember using the decorator pattern in a previous course, so I see how it can be useful.

I feel that Subham provides great examples that have helped me better understand these design pattern concepts. The code he provides is well detailed and easy to follow. His blog will be a good reference to me in future projects during my professional career.

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

https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
This week we analyze why a code may be STUPID. What makes code STUPID are the following:
Singleton
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication
Singleton, what is wrong with that? According to the example code provided in the article, the singleton allows access to the DB from anywhere using the getInstance() method. In addition, it ensures that there is only one database connection at a time. This is not an issue until a second connection to a different database is needed. In this case, when the application grew larger, the developer needed to change the singleton to have a getSecondInstance(). However, this isn’t a singleton anymore. Another issue is that the getInstance() function binds the code to the DB classname. This means that the DBclass can’t be extended. In this case, when a developer wants to optionally log query performance data to the APC, tight coupling to the class name will not allow it to do so. Dependency injection would have solved the problem, however this is not allowed in singleton pattern. What the writer introduced was what can be called a “hack”, but this is bad coding practice. The last point to be disappointed in is that the getInstance() method allows global access from anywhere using the DB. However, in PHP we learned to avoid the use of the global keyword. Global instances in singletons creates non-obvious dependencies, making the app harder to reuse and test. So, this is impractical coding practice.
The singleton issue can also be generalized to the issue with static methods and properties. For example, the Foo::bar() method will tightly couple the code to the Fooclass. This prevents the Foo function from being extended. This makes it harder for the code to be reused and tested. The example provided is the House class with the constructor function for the variables door and window. The question to ask is how would you replace the door or window in the house class. The answer is you can’t! Instead, the dependency injection can be introduced, however the House class is an example of stupid code.
Finally, we stop at the U in STUPID which stands for untestability. Unit testing is important and if we cannot test we cannot verify its proper functionality. If we don’t test we can end up with broken code. Making a code hard to test is in this case stupid code. What makes a code hard to test? — tight coupling. Dirty hacks can be used to avoid these issues, but we would rather not have broken codes in the first place. Overall, good coding practices means that it can be easily tested.
I chose this blog post because it introduces the disadvantages of the singleton design. This further intends what I have learned in my first blog post on Singleton patterns. Singleton in this case is criticized even for its advantages in creating a global state for a single instantiation. In this case, it is criticized as stupid code because it does not allow the developer to extend the code without modifying it to include a second instance, making it a dupleton.
I chose to learn about STUPID coding practices in order to improve my own coding practices as a developer since it provides good examples for how to avoid bad code and how to improve upon it. By, following some of the guidelines introduced here, this helps to make the code easily extensible without modifying its previous functionalities.

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

Model-View-Controller

          This week, I chose to write about a blog that went over the understanding of Model-View-Controller. The post first started by explaining each term separately by saying that the Models represented the knowledge while the View was a visual representation of the Models and the Controllers were the links between the user and the system. It talked about Models first, saying that most of the time there should be a one to one correspondence to make sure everything is easily understandable. The blog then goes on to talk about Views as a presentation filter, it would be used to easily convey information. As stated before, this is helpful when it is a visual representation of the Model but it can also be connected to the model which allows it to know more about the attributes and data. This leads to the controllers that essentially allow the user to see outputs based off of menus and other ways of giving commands and data. It uses this output to then make changes back in the Views section which will them give out another output.

          I chose this article because it seemed important to know more about how to explain code using models and controllers in this sense to other people. This post used examples that allowed this idea to be understood much easier for me, as the summary was a bit confusing. When they used the example of HTML code in the browser it made much more sense. The way I understood it after that was that the model was the information the creator wanted to put into HTML while the CSS was the view which acted like the “code” that displayed everything in a clean visual representation. This all came together within the browser which they linked to a controller as it is what combines and connects the entire thing. As I said before, the content had ok definitions but the examples they used made up for it since it allowed an easier understanding. I thought this topic was important since we will be learning about this subject as it is a software architectural pattern. This material affected me by showing me a system to show the user simplified information through the use of code. I think that if this were to be implemented within coding, it would be best used as a way to reuse code along with implementation of user interfaces. As a software architectural pattern, I could see this being important to future practices as it seems to be used a lot within popular programming languages and even web application development.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.