Another programming term I learned about this week is “Bloaters” which are code, methods, and classes that have increased to such big proportions that they are difficult to work with. This is part of a section of code that “smells”, which doesn’t literally smell, but it means that this type of code stinks. When it comes to bloaters, these “smells” do not come up right away, but they accumulate over time as the program evolves.

https://sourcemaking.com/refactoring/smells/bloaters

The blog “Source Making” goes in-depth with Bloaters and I like this blog because it breaks down the types of Bloaters and explains what they are, what causes them, and how to fix them in a way that’s easy to understand. The blog lists a few types of Bloaters.

• Long Method
• Large Class
• Primitive Obsession
• Long Parameter List
• Data Clumps

Long Methods are methods with too many lines of code. The rule of thumb given by this blog is that if a method has more than ten lines of code, it should be reconsidered. A solution given by the blog is that if you feel the need to comment on something inside a method, you should take the code out and put it into a new method instead.

Large Class is a class that contains too many fields/methods/lines of code. Classes usually start small but get bloated as the program grows. If a class is wearing too many “hats”, then you should think about splitting them up.

Primitive Obsession is the use of primitives instead of small objects for simple tasks, the use of constants for coding information, and the use of string constants as field names for use in data arrays. Like many other smells, primitive obsessions are born in moments of weakness but become a problem later on. The blog suggests that if you have a large variety of primitive fields, it could be possible to logically group some of them into their own class, or move the behavior associated with the data into the class too.

Long Parameter Lists are more than three or four parameters for a method. To fix this, check what values are passed to parameters, if some of the arguments are just results of method calls of another object, you should replace the parameters with a method call.

Data Clumps are different parts of the code that contain identical groups of variables and should be turned into their own classes. This can be caused by copying and pasting a lot of code, and if you see repeating data, the blog suggests using the Extract Class to move data fields to their own class.

This blog gave me a great understanding of types of code smells, like the Bloater, with multiple examples of bloaters that many of us may encounter or even create while coding. This is a good way to see if you’re practicing bad coding habits and how to fix them to make your code more concise and to make your programs run better.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

This week, I am writing about the first Antipattern that I’ve learned about, which is called “The Blob.” I learned about this Antipattern from the website “Source Making.” And I like this blog’s explanation of The Blob because it breaks everything about it down into different sections, making it easy to understand.

https://sourcemaking.com/antipatterns/the-blob

The blog begins with some background to make the idea of The Blob Antipattern easier to understand by first describing the movie of the same name, where an alien would grow as it consumed things, which is a good analogy for the Blob AntiPattern because it has been known to consume entire object-oriented architectures.

The blog then goes on to explain that The Blob is found in designs where one class monopolizes the processing, which means that the majority of the responsibilities are allocated to a single class. Because of this, the code is procedural-style rather than object-oriented architectures.

The next section of the blog describes symptoms and consequences of the Blob. Which include: a single class with a large number of attributes, operations, or both. The blog explains that a class with 60 or more attributes and operations usually indicates the presence of the Blob. A disparate collection of unrelated attributes and operations encapsulated in a single class. A single controller class with associated simple, data-object classes. And an absence of object-oriented design. A program main loop inside the Blob class associated with relatively passive data objects, the single controller class nearly encapsulates the application’s entire functionality.

The blog then goes on to explain typical causes of The Blob AntiPattern which include: lack of an object-oriented architecture, lack of architecture enforcement, too limited intervention, and a specified disaster.

A solution for the Blob AntiPattern offered by the blog is a form of refactoring. The key is to move behavior away from the blog and to reallocate behaviors to some of the encapsulated data objects in a way that makes those objects more capable and the Blob less complex.

So from this blog, I learned about my first AntiPattern, The Blob. Like the movie of the same name, a Blob AntiPattern is where one class monopolizes the processing of the other classes in a program. It gives too much responsibility to the single class and leaves not much else for the rest of the classes to do. This is bad practice, and to fix this AntiPattern you should refactor your code by taking away some of the responsibilities from the Blob and delegate it evenly to the other classes to make the program more equal in processing.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

https://medialoot.com/blog/angularjs-for-absolute-beginners/

For this week’s blog, I chose a tutorial titled “AngularJS for Absolute Beginners” by Jenn Coyle because our final project is going to be coded in Angular, so I think that finding different blogs of tutorials for Angular is a good idea to help familiarize myself with the language. I like this blog by Jenn Coyle because it’s a straight-forward approach to Angular and does a great job at making the tutorial easy to follow so that it doesn’t overwhelm the person reading it.

Coyle’s blog starts off with an important sentence “Let’s face it, writing web applications is hard.” I like that Coyle started off her blog with the sentence because she assures the reader (who is probably just starting to learn Angular) that if they think that writing web applications is hard, then that’s perfectly fine because it’s supposed to be. I also think this adds a sense of comfortability for the reader.

Coyle goes on to say that AngularJS eases the pain of battling to make a functional front-end. The blog makes clear the prerequisites you’ll need to learn Angular, which is just a basic understanding of HTML, CSS, and JavaScript.

Coyle’s next point is why Angular is helpful. Anyone who has written code for a front-end web app has probably written code that’s soaked with bad practices. She defines imperative programming which changes the state web application by creating a flow that appends new elements to a list, which can be seen as negative because it can hide important functionality. Other problems that Angular address is direct DOM manipulation, global scope, and lack of organization.

Because of these problems, a meaningful and reusable structure for application was created: AngularJS. AngularJS is a front-end JavaScript framework and provides us with an opinionated way to build a powerful front-end for applications. It is opinionated because it forces the user to follow a specific pattern.

Coyle explains the structure of Angular well: that it is built to isolate specific responsibilities of an application from each other. And is made of different components. Coyle also goes over the other basic structures of Angular like the directives, controllers, and views.

Coyle then goes on to giving a step by step instruction on how to create an AngularJS program.

1. Create the module
2. Initialize the View
3. Create the controller
4. Set up $scope
5. Tell the view about the controller
6. Bind data to the page
7. Create view layout
8. Set up data on the controller
9. Bind the todos to the view
10. Set up the template
11. Finishing a todo
12. Removing the todo in the controller
13. Add a new todo
14. Adding a todo to the controller

All of these steps come with code and an explanation which helps make everything clear. This and the thorough explanations that Coyle gave for everything in AngularJS is why I chose this blog as a good tutorial for beginners. It breaks everything up into an approachable process for anyone who wants to learn AngularJS.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

I decided to write this week’s blog on Observer Design Patterns because I am going to be writing a tutorial on this in class next week. I chose a tutorial posted by author Santosh Kumar on the blog “WalkingTechie”. I chose this blog about the Observer Design Pattern because Kumar gives an in-depth explanation of what an Observer Design Pattern is, how it’s implemented and gives UML and code examples of it which I found to be extremely helpful.

Kumar starts by giving a definition for the Observer Pattern, which he states “defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” He also states that this is a part of the Behavioral Design Pattern.

Kumar furthers explains the Observer Design Pattern by giving a real-world example with a newspaper subscription. There are two variables – Subject and Observer. In this example, the newspaper publisher is the subject and goes into business by publishing newspapers. The observer is the subscriber who subscribes to a particular publisher, and everytime a new edition comes out it gets delivered from them. A user can unsubscribe which will stop papers from coming.

Kumar then implements the Observer Design Pattern. He defines a Subject interface that has a method to register, remove/unregister user and notify users when the object changes state. There is also a DisplayElement interface that has a display method, and an Observer interface and all concrete classes – BinaryObserver, OctalObserver, and HexObserver.

After constructing a UML diagram, Kumar goes through the code implementation step by step.

In the first step, the Subject interface is created. This contains the registerObserver and removeObserver and notifyObserver methods.

In the second step, the Observer interface is created. This includes the update method,

In the third step, the DisplayElement interface is created, which has the display method.

In the fourth step, a concrete class DecimalData is created and implements the Subject interface. Then a concrete class is created that implements the Observer and DisplayElement interface. And finally, the ObservePatternDemo class is created to use DecimalData and concrete objects to test observer design patterns.

I enjoyed Kumar’s blog explaining the Observer Design Pattern because he went in depth by defining the Observer Design Pattern, giving a real-world example, and implemented it by creating a java project. This really helped me understand the Observer Design Pattern more and it will come in handy when I do my tutorial on it.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

This blog that I chose to write about this week was a blog post titled “Design Patterns in Real Life” where the author Karthik Kumar creates his own examples of design patterns modeled after real-world situations to help him and the reader understand design patterns better.

http://karthikkumar.me/design-patterns

I chose this blog because I think it is important for those learning new programming concepts to get examples that relate to the real world because it helps them understand these concepts a lot faster.

Kumar begins his blog by explaining how after reading a popular book “Design Patterns”, he noticed that many of the examples used in the book were hard to relate to and the “Known Uses” of each chapter were outdated. To help understand the design patterns better, he created his own examples for each design pattern. In this blog, he explains patterns with his tangible, real-life examples.

Kumar starts off by explaining “Creational Patterns” which deals with how objects are created. They control how objects are built and can have a huge impact on improving the design of the system, it can also allow a system to be independent of how its objects are created.

He then goes into detail of a creational pattern called the Builder Pattern. This pattern separates how an object is constructed from its actual representation. It allows us to use the same general construction process to create different representations.

The real-world example Kumar uses for the Builder Pattern is the car manufacturing industry. In this example, he explains how when building a certain car according to specification, the manufacturer chooses several options about the car. This could include the color, engine, and any additional features. In this example, the client interacts directly with the builder to manufacture cars. The advantage of using the builder pattern is that we can construct cars with different characteristics using the same builder, and by specifying different parameters to the builder.

Kumar then explains Structural Patterns with deal with how classes and objects are built and composed as part of a larger system. He continues with the structural pattern the “Facade Pattern” which provides a single unified interface that encompasses several interfaces in a subsystem. It acts as a funnel to expose a single interface to many clients, and hides the actual subsystem that’s responsible for doing the work requested.

The example Kumar uses for the Facade pattern is Amazon’s 1-click ordering system. When ordering items, a customer is presented with a simple interface to purchase an item, but there are several complex processes running to enable an item to be purchased, and the user doesn’t see that.

Kumar takes these design patterns that may be hard for us to understand and uses everyday real-world examples to make understanding each design pattern easier, which I really like. I hadn’t looked at these design patterns in depth before and this blog helped me understand them quickly thanks to the examples provided.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

A topic we recently discussed in CS-343 was Factory Design Patterns. The factory design pattern is an object-oriented design pattern that deals with the problem of creating objects without specifying the class of the object that will be created. Creating an object usually requires complex processes, which may lead to a lot of code duplication and an insufficient level of abstraction. Factory design patterns handle problems like this by defining a separate method for creating objects.

http://javadesign-patterns.blogspot.com/p/factory-desig.html

I chose to write this week’s blog on this example of a Factory Design Pattern because I thought it was a simple example that makes understanding Factory Designs easy and also gives readers a straightforward understanding of Factory Designs.

The blog lists when to use factory patterns in a straightforward manner by stating that you can use factory patterns when a class does not know which class of objects it must create, a class specifies its sub-classes to specify which objects to create, or when at runtime you need to create an object based on input parameter.

The blog then gives a good example of Factory Design by imagining that we want to develop a Media Player application, which should play mp3 and mp4 format audio and video files.

In the example, the author creates a Decoder interface, a MP3Decoder class, a MP4Decoder class, and a player class. The problem that arises is that the classes MP3Decoder and MP4Decoder are tightly coupled with the Player class. This could become a problem if Player needs to support a new format because then a new decoder needs to be added to the Player class, so every time you would have to modify the Player class.

To fix this problem, the factory design pattern can be used. The author applies the factory pattern in this example by introducing a DecoderFactory class and moves the Decoder objects from the Player class to this new one, then by modifying the Player class to use the new factory class. With this new implementation, if the Player class needs to support a new format then no modification is required in the Player class because you will only need to put the new type of decoder in the Factory class.

I chose this blog because it efficiently explained the Factory design pattern, which we are learning in class right now, and gave a new example that helps further my understanding of the design pattern even more. It was simple and straightforward and did not leave me confused when trying to understand it.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

A topic that we recently discussed in class is Strategy Design Patterns which is defined as a family of algorithms that are each encapsulated and made interchangeable. Strategy lets the algorithm vary independently from the clients that use it. It is best to use when many related classes differ only in their behavior and when you need different variants of an algorithm.

https://www.madetech.com/blog/design-patterns-strategy

I chose to write this week’s post on a blog written by Scott Mason which is also on Strategy Design Patterns. I chose this blog because Masson explains Strategy Design Patterns by using a popular video game, Overwatch as an example and shows how Strategy Design Patterns are needed to make the game more efficient. This blog stood out to me because of the Overwatch example since I’ve played the game before.

The blog poses a problem. In Overwatch, players have the choice of playing as 21 different characters, and each character has 3 different attributes unique to them. During the game, the user is able to switch between characters when they die, so the game needs to run smoothly.

Mason shows what a poorly designed code would look like, where you have a class for each ability, but create an if statement for all 21 characters. This would result in 63 different cases which is too repetitive.

Mason poses the solution which is to create a series of classes known as strategies, one per unique character, that defines how each of the characters implements their abilities. This makes it so the Player class doesn’t need to know the specifics of how each character implements each of their abilities, and we can just pass a particular character to it. The new code that’s shown in the blog cleans up the program significantly so that new characters can be added with ease by creating different strategies with the same methods.

This was a nicely written blog that explains Strategy Design Patterns efficiently because it thoroughly went through transforming messy, inefficient code to code that uses strategy and is efficient. And what made this blog more appealing to me was that it used a video game I play as an example, which made it easier for me to understand everything going on in the code. This won’t appeal as much to people who haven’t played Overwatch though, but I enjoyed the blog and it helped me understand Strategy Design Patterns even more than I did before.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.