Author Archives: jeffersonbourguignoncoutinho


Last week reading took us through one design pattern the singleton pattern and a quasi-design pattern the simple factory technique. I was very impressed by both and took some time to analyze their delivery method –how they presented their arguments. On singleton the author presented the design as a conversation in an almost Zen tone. I was attracted to his way of explaining because I believe that a lot of times when studying we let the stress get the better of us and miss many important points. The step by step really show not just how but why. A lot of times we write a lot of code because we know how but not always know why we write it a certain way, which I believe makes the knowledge untransferable –although why is not always important.

The relaxed Zen mode of explaining is also something I appreciate because I am a strong believer that sometimes, some things should be explained like you would explain a 5-year-old, and I have no shame in listening like a 5-year-old. It is easy to have many years of experience on something and forget some of the things taken for granted are very important to the beginner(me). The Zen approach also reminds me of Buddhist monks drawing complex sand diagrams only to erased them and start over again. It is hard to erase bad habits and acquiring good ones, but by creating the habit of erasing habits the learning cycle can be increased considerably. That’s all I must really say on how the authors carried their message, but the interesting thing was the message itself.

The singleton pattern at first was not impressive if anything I always had a bad view of private or protected variables or methods. I never really understood the need to hide things in code maybe because I never really had to write code of considerable size. Once I started working with the pattern it was like a little light bulb flickered on top of my head and I suddenly started seeing the coolness of obfuscation in this case just preventing object overcrowding. I really thought it was pretty cool and I think that in the way the idea was explained the structure will be in my head for quite some time, and I am a very forgetful person.

The simple factory technique was also well explained in just the right number of words. It was very clear that by consolidating actions or delegating the creation of objects helped to minimize how much one class was doing. Uncle bob always say doing too many things is bad, so I think this applies in this case. I was afraid at first that to implement this was to substitute the singleton pattern that I’ve gotten so fond of, but that was not the case. After implementing it I saw that there were other areas that could be greatly improved by consolidating further. My only fear is to know when to stop –how much is too much consolidation.

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

UML Diagrams

Diagrams are usually a good way to convey an idea. There is an intrinsic human ability to understand abstract instructions in this form. It is not surprising that in designing software we would look for a way to express it as such. UML diagrams are not only helpful as a [mockup]blue_print in designing but also as format to present the main idea in a more straight-forward way to non-tech assets.

I find it interesting the idea of facilitating the introduction of a concept to a non-tech asset (perhaps because most of the time I just want to understand it better myself). I should really explain what I mean by a non-tech asset, this term could be used somewhere else for a different purpose –if you do so know a better word for my definition, please leave a message. I think of non-tech assets as a broad spectrum of individuals that may be involved directly or indirectly to the end-product. There also may be closer relations amongst different expertise that makes part of a certain project alien to a particular group –also tech aware but not omniscient. This is my philosophical attempt at saying some people need to understand how something works not necessarily why it works –this tie well with obfuscation I believe.

So, by the definition given above and by the readings this week it becomes clearer that there is a choice to be made in UML diagrams –should it be all-expressive or partially-expressive? I believe that most tend to stay at the partially-expressive end, which is best because it uses obfuscation to increase clarity. I know this sounds counter to obfuscation but think, a lot of information about something you don’t understand, or care, does not necessarily make things clear. It does the opposite; it muddies the intention; it hides the meaning by overloading the target. Now that we cover this, let’s move to decision making and end with standardization.     

Throughout the last classes (school class) we have been discussing how to optimize code by looking at UML diagrams. The information on the diagram provided us with the information necessary to see the problems accrued by the code’s configuration. So, it is safe to say that there is a minimum amount of information that needs to be in a diagram in order to be fully helpful. It is also a safe bet to say that a lot of the implementations that don’t affect the relationship amongst the classes (not school classes) is too much information. I think that if we code clean (no pun intended) the implementation speaks for itself and it doesn’t need diagram representation, which should only be necessary when we look at many classes interacting.

At the reading we were presented with a very interesting standardization problem. From what I saw there are a lot of ways to use UML for a variety of subjects. There was a discussion about a public (tech public) uproar from a previous attempt to standardize. I think the complexity lies in how many ways these diagrams are used. Maybe software developers would benefit from such standardization but who am I to say. As far as I know if I had to work with a team, I would like them to produce diagrams that follow a particular set of rules instead of looking at a jungle of too much and too little. Fowler says it best in this quote “… there is no hard-and-fast correspondence between the UML and code, yet there is a similarity. Within a project team, team conventions will lead to a closer correspondence” (Fowler, 2004).


Fowler, M., 2004. UML distilled Pearson Education, inc.

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

Thoughts on Encapsulation

This post is the result of a discussion in class which revolved around the concepts of polymorphism, encapsulation, abstraction and inheritance. The concepts of polymorphism and encapsulation eluded my group’s ability to elaborate beyond the definition of the word in a dictionary. Trying to explain such concepts by this method would be over simplistic and not helpful in the computer science context, so I decided to research it and write a blog to educate myself on at least one of the terms. The term I chose was encapsulation because I believe it to have ephemeral properties harder to describe than the others.

In the dictionary some explanations of the word encapsulation are interesting. One of the examples talk about setting a permanent cover over contaminated soil. I myself tend to think of encapsulation as a form of nesting –not in the recursive sense, but in a sense, attributes can be placed at different levels inside other objects and so on.     

The aforementioned nested idea says that encapsulation is used to bundle attributes of an object and control access to it. It does that by using access modifiers to control access to classes. An example would be the private access modifier –you can create a private variable in an object and then decide which type of modifications are allowed and how these modifications would work. Once those private variables are created, they can be initialized indirectly by a constructor, but they cannot be accessed directly outside their class. If access is needed, it must be granted in the form of a setter and or getter.

This can be very useful if the information of an object is important and changing it or using invalid arguments would cause undesirable behaviors to the class.

A getter can give access to a variable of importance if needed for any reason, but write access needs to be denied.

A very trivial example would be a constant found that is very useful but should never change, you may need access to it numerous times, but every time you access it you expect it to be the same, and you may not necessarily know what this value should be.  

A setter can also be a way to control access making sure that any change is done purposefully and not accidentally or by side effect during the execution of a program or a task. Some behavior of an arbitrary object may need to be changed from the outside but that’s a hard decision to make, and I believe it would involve investigating the functionality of the object in the context it was meant to execute. 

Looking at the small portions of code we usually work on makes it difficult to understand the necessity for encapsulation. But in large environments outside the boundaries of what we can see or are working currently, there can be countless opportunities to fail from not utilizing good practices for encapsulation.

Encapsulation is like the member of a melodramatic story that you only miss when it’s too late.

[please feel free to point things that are off the mark, missing and or incomplete statements]

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


Hi hope all are doing well, this has been a challenging couple of months but we made through it. I can’t wait to be in person again and hopefully soon this pandemic can be behind us. This semester seems promising to me and hopefully it will be to all of us.

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