Flyweight

The blog I chose to talk about this week goes into detail about the flyweight design pattern using its applications and implementations. When the blog starts talking about the applications of the design pattern, it begins with the situations of when you should use this design pattern. It explains that flyweight is centered around memory and sharing which may not be an issue for today’s computers, but it still is prevalent within mobile phones. When there is a need to create many objects, that needs memory power to execute but this design pattern focuses on efficiently optimizing that memory sharing which helps boost performance. The application of this design is shown in the blog when it talks about the large number of objects being used by the system and how flyweight will group certain objects together to reuse code to make the entire problem less repetitive. The blog then goes on to talk about the intrinsic and extrinsic states which is explained through the types of data values the objects can hold. It explains how a concrete object may hold an intrinsic state as a value which allows that value to have certain properties. These properties can be extrinsic and be modified as needed.

I chose this article because as I read more about this flyweight design pattern, I realized it also had the possibility for factory implementation as well due to the efficiency with mass object creation. This really interested me since we just went over factories and I wanted some more experience in understanding how factories can be used in other patterns. Though it would just be used to test this design pattern, I thought it was good exposure to how they worked, and it worked well with explaining how flyweight worked. The content was easy to explain with the examples used that had written out code and UML diagrams. The blog used these resources together with JDK to produce an output based off a test class that emphasized the main points of the applications and implementations. They helped cement the idea of factories and code sharing between different objects very well and used similar concepts to those discussed in class. This would affect my future practice by allowing a new view on code reuse which is an important concept. This pattern taught me more about code efficiency using factories and different pattern concepts as well as the idea of objects having different modifiable properties.

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

Cohesion and Coupling

      This week, I chose to write about a blog that talked about high cohesion and loose coupling. The post went over the definitions of both terms and used examples to help solidify the idea. It started with high cohesion by defining it as the degree to which certain modules correlate or belong with each other. Essentially comparing the functionality of different parts of a software module to see how similar they are. The blog then talks about different types of cohesion and goes on to list worst to best. It talked about coincidental, logical, temporal, and even functional which allowed a wider understanding of the sub categories within cohesion. The blog then defines couplings as how much one module knows about the inner workings of another. It then divides it into the subcategories of loose and tight couplings saying that loose is a method that makes the modules as least dependent as possible from each other while tight is a method that makes it so you can’t change one module without changing the other. The blog then goes into more detail about the Law of Demeter which is a well-known specific case of loose coupling that explains more about what fields the object in question should access.

      I chose this article because it was a main topic within our class discussion of design patterns. I thought that it would be a good idea to review this topic more as it seemed important to know for the future projects given to us in class. The post was a great source of information that balanced the amount of text given with visual examples. It stuck to basic definitions with applications to code while also using visual drawings to intrigue the reader. The tables and code used to explain the ideas were very helpful as they illustrated how each example differed from the others. I now understand that high cohesion is better used to see the similarities between modules and loose coupling allows as much freedom as possible within the dependent relationship of the modules. Since theses fell under the category of design patterns, I think it would be very helpful to fully understand the subcategories as well since there is a best and worst type for a given situation. This could help out a lot in future practices of code when dealing with multiple relationships of modules in a software that need to be optimized using a design pattern. Once again, since we learned this material in class, I thought it would be important to review this topic before we have to apply it again in our upcoming classes.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience 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.

Encapsulation

        I chose a podcast this week to try and broaden my learning experience using different resources. This podcast talked about object oriented programming dealing specifically with the idea of encapsulation. It went through the basics of what encapsulation is and how classes, methods, and variables all connect with each other to hide data. The people on the podcast explained the differences that encapsulation can have between different languages but the basic idea is essentially the same. The overall syntax may change slightly but the idea of data and code being hidden from the user is still there. They then explain how the idea of a roadmap works well with this idea and how helpful it could be if other programmers are looking at the code. It allows programmers to understand what they can and should use in your code. They go over access modifies such as public, private, and protected where they explain that giving the user all the code can be harmful as that allows the user to change values that could end up breaking the program. They also use global variables to help show this point by saying they are not reusable and make it more difficult to track down errors.

         I chose this podcast because encapsulation is an essential part of coding in an object-oriented language like java. It allows the programmer to hide code that doesn’t need to be seen by the user to make sure that they can’t alter anything they shouldn’t. I have to admit that out of all the complicated podcasts I searched through, this one especially made it easy to understand java concepts. Coding blocks has a solid source of information and does a great job explaining how everything works using their own definitions for the somewhat confusing vocabulary. Although I already knew most of this information, it was a great idea to refresh on it because I had forgot all the vocab such as mutators and accessor methods which I just called getters and setters. Overall the content was very easy to understand due to the helpful explanations given by the people in the podcast. It affected and helped me by allowing me to refresh on encapsulation and encouraged me to go look at inheritance along with polymorphism again. This obviously will tie back to our class since we’re going to be using a lot of object oriented programming in java and using encapsulation to work on our projects. Encapsulation will have a big impact on my practice of code as it will help shape my design for how the code will look and what the user will have access to if I want them to only have limited control over the program.

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

Multiton Patterns Explained

The article I chose this week explains a lot about the multiton design pattern which is very similar to the idea of the singleton pattern. It limits the number of instances a class can have by using a specific key for each instance and only one object can be made from that key. It uses a similar format to hash tables where there are values connected to specific keys. To be more specific, when an object is requested a key is passed to a static key generator method. If that key is brand new and never used before then the new object is instantiated and is returned after being linked to the key in memory. However, if that key has been used before than it will return the object that is already paired to that key. The article explains singleton as well by explaining that it ensures a class allows only one object to be created if there is only one access point. The key difference between the two being that singletons deal with one at a time while multiton allows the use of a map of named instances. The article then explains the design pattern using UML diagrams and specific examples.

I chose this article because we talk a lot about instantiation in class which is easier to digest as it involves simpler object-oriented ideas but these design patterns seemed a bit more complicated to me. The parallel this article drew to hash tables helped show off the similarities the system used with the concept of memory allocation. The content of this resource was quite dense as it was a lot of simple concepts woven together to create an intricate design which was difficult to understand at first. The first time I read the article, I didn’t understand any of it but after quite a few minutes it started to come together. The use of graphs and UML diagrams within the article helped with the basic understanding of what was happening to the objects. They also helped me learn the concept that a multiton pattern is essentially a group of singleton patterns all on a single map. This material affected me by explaining how multiton patterns work and how it uses instances of objects to create a key-object relationship. This all ties back to class where we will be learning about complicated patterns such as the multiton and singleton design patterns. These patterns will affect my future practice by helping my exposure to patterns and new ideas as this is my first time really dealing with patterns.

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