Design Patterns


This week, for my final blog, I’ve continued the recent trend of developing the fundamentals of software engineering.  To have any hope to be a decent programmer I need a good foundation of knowledge so I can adapt and learn easily in my career.  This week, I took the time to make sure I understood the different types of design patterns.  I.e. creational, behavioral, and structural.  I chose the source above because it gave me exactly what I wanted.  A concise definition of what the types were.  The website also goes in depth about the GoF patterns as well in other articles so it’s a good resource overall.

Before explaining what the types are, we’re given a summary of what patterns are, the GoF design principles, and why we use design patterns.  In this part of the article, only one thing stuck out to me.  My opinions of patterns shifted somewhat.  These patterns are documented so that newer developers can learn design in a much easier, faster way.  There’s no need to reinvent the wheel, I should learn from my predecessors’ work.  The patterns exist to solve common problems in object oriented design so it’s best I know what problems they solve, or at least, where to look for a solution.

That’s why understanding the pattern types is essential. And, although it’s an admission of ignorance, I can say that I understand the types better now.  Or rather, what they achieve.  Creational hides creation logic while giving more flexibility for deciding what objects are needed.  Structural helps organize class hierarchy and relationships.  And, lastly, the only type I’ve active experience with, behavioral.  It concerns itself with the communication between objects of a program.  Not new to me but it’s a better articulation than my previous understanding.

From this source, I know I’ll be a more complete, competent developer.  It’s immediately applicable both as a student and an employee.  With this knowledge I’ve got an insight into what the individual design patterns achieve. As a student, which all developers are, it’s vital to my research and growth.  Knowing their nature also helps with designing since I now know I have a resource for solving Object orientated problems.  Whether I’m working in a team or on a solo project, there’ll be times I need to think for myself and solve problems.

This is an extremely basic topic and my past few post have been near the same level.  But I think it’s imperative that I understand core concepts and basics completely.  I wont always know how to do something, but knowing what to do is the first step to getting past obstacles.

A SOLID Foundation

Linked above is the article I used for this week’s professional development blog post.


This week, in a continued effort to improve my fundamentals with Object orientated programming, I reviewed the five principles of SOLID.  In doing so, I found a popular resource.  The reason I chose this one for review though is that it cover’s every principle.  And, each principle comes with examples in code and explanations of how the principles should be applied to programming.

Having all of the SOLID principles explained in a single place was attractive because I had no exposer to them before this class.  This also means that nearly all the information within the web page was new to me.

Similar to the principles of GRASP, SOLID is fundamental to designing and writing code.  It’s five principles (Single-Responsibility principle, Open-Closed principle, Liskov substitution principle, interface segregation principle, and Dependency Inversion principle) all contribute to making code much easier to refactor.  Adhering to these principles means the subsequent software will be easier to maintain and extend.  This is vital because all software I produce will need to be refactored.  Both before and after it’s “finished.”  So, for both my sake, and any other developer, it’s worth making sure I’ve understood these principles well.  After reviewing and learning what each principle was, again just like GRASP, I was able to see how my past projects have embodied these principles.  In fact, many times I was working with towards achieving these principles with my projects or working with them in mind without knowing they had a pneumonic device.  In fact, many of the mottos of Object Orientated design are expressed in SOLID.  Take the first principle of SOLID, Single-Responsibility.  Simply put, it means any class or module should be only concerned with a singe part of the program’s functionality and that the functionality should be encapsulated. This immediately reminds me of “encapsulate what varies.”  Adhering to this principle makes the code a lot friendlier to refactoring since a class would only be concerned with a single function or behavior.

Just like the first, all of the principles are the foundations to good code practices and many common design patterns.  With this being the case, I can see that this is a subject I know in my sleep.



Firmly GRASP it (cohesion and coupling)

This week, for professional development, I chose to read and learn about two of the GRASP principles of software design, High Cohesion and low coupling.  One of the best resources I found was this blog post,

The post starts by mentioning the need for code to be maintainable and changeable, especially in business, to backdrop how useful these coding principles are.  Following, the author explains cohesion and goes through what seemed like an exhaustive list of the types of the common types of cohesion.  After giving a few visual examples (class diagrams and code) the same is done for coupling as well, along even more code and diagrams.

Now, all other resources do basically the same thing with the topic, but I felt this resource was the best for explaining both how and why we try to achieve loose coupling and cohesion.  Along with his diagrams and code, the examples provided to explain the concepts were easily understandable as well.  A good example would be the explanation provided for loose and tight coupling

iPods are a good example of tight coupling: once the battery dies you might as well buy a new iPod because the battery is soldered fixed and won’t come loose, thus making replacing very expensive. A loosely coupled player would allow effortlessly changing the battery.  The same, 1:1, goes for software development.

The example’s simple language and nature makes the subject a bit easier and a bit quicker to learn for me.  It’s important too that I understand this topic well because nearly everything I write will need to be refactored.  If not by me then by someone else, and having to change someone else’s code is already difficult enough.  So, it’s in my interest for both simplicity and professionalism that I make sure to value loose coupling and high cohesion in my work.


Now, I can see more clearly how my past object orientated class assignments have all stressed keeping classes independent and ignorant of each other. Loose coupling and high cohesion are instrumental to keeping code manageable and now I’ve got a much better grasp of these concepts.

Beyond the general concepts, I appreciated the overview for the different types of cohesion.  They are just different ways of grouping modules, but knowing some of the most common ones will improve my own designing speed and quality.

I know I’ll use the information from this post enough that it should become second nature to me, hopefully subconscious.

Decorator Pattern

This short blog post discusses the uses, design, and implantation of the decorator design pattern.  Specifically, in java.  There are two reasons I chose to write about this topic.  Firstly, I’m currently doing an assignment on the subject but, more importantly; Decorator pattern is one of the first ones covered in “Head First Design Pattern” (Freeman, Bates).  I’m assuming that this means it is one of the more basic ones we should understand as developers.  (Again, I’m still in school, I may be wrong) The reason I chose this blog in particular is because it’s example code is explained well and its example is more suited to what decorator pattern can do.  I found the aforementioned text’s example a bit ill suited.

The blog’s example is to create a basic ‘IceCream’ object that has toppings applied at runtime.   Decorators achieve their flexibility by creating wrappers to go around objects that communicate between the object and system.  Decorators can also wrap wrappers that are already applied to an object.  To do this, a decorator class is created that implements the same interface as the object we want to modify.  From there, two concrete, decorator subclasses are created that can make the modifications the user or developers want.  In this case, it’s adding nuts and honey.

From this blog I learned that the main advantage of decorators is “changing the behavior of an instance of our choice at runtime” which adds a great deal of flexibility to our project.  This seems like a great alternative to what can be referred to as “sub-class explosions.”  In other words, this is a good way to avoid having too many subclasses.  This may not be necessary for the machine but, it’s a boon to the humans who have to work with the code.

The decorator pattern, from what I can tell, will most often be used when inheritance is either impossible or unreasonable for whatever reason.  As I stated before, avoiding sub-class explosions is the most likely scenario for the later likely use of Decorator.

To me, this pattern seems fairly simple to understand and implement which excites me because that will make writing and practicing much less painstaking.  My only gripe with this pattern is that, although it adds flexibility to our code and can reduce sub-class totals, that’s all it does.  Of course, patterns are going to be one-dimensional because they are designed to tackle a single problem but, I’m not sure if there will be a lot of use of the decorator pattern in professional projects.  That is, the problem it solves doesn’t seem too common or obnoxious.  However, I enjoyed learning about it nonetheless because, for me it’s fun to solve issues of any kind.

Abstract Factories

Last week, on my blog, I discussed simple and static factories briefly.  That post, however; only talked about some of what factories can do.  This week, to round off my knowledge, I choose to reaffirm learn more about abstract factories.  The best resource I found to help me with the topic was (Object oriented design).  Above I’ve linked all three of their pages on factories but I’ll mostly be concerning myself with the last one, abstract factories.  For the most part, I can earnestly say I didn’t know much about abstract factories.  I’m not the most well-read developer, yet.  But immediately they seemed like an impressive tool.

From my readings and class lectures this week, I know that Factory Method pattern uses an interface to create objects while allowing for subclasses to decide the type of object.  I learned though, that abstract factories were an extension of this functionality.  They are essentially a factory of factories that allows us to take advantage of the “code to an interface” principle.

I can immediately recognize that abstract factories prove a good practice to code.  In the pages, I saw that every subclass had their own factory classes written for them (meaning that factory method pattern and abstract factories work well together).    Subclasses can be added to an interface, so long as they are compatible (in the same family of objects).  This would seem to promote easier refactoring and extending functionalities of programs.  And, as a developer, I assume that any program I write will need to be expanded or edited.  If abstract factories truly do make it easier on that front, then I’d be more than willing to use them.  Unfortunately, I do have a concern relating to their extendibility.

They aren’t entirely flexible, that is, an abstract factory can’t help creating in an object that isn’t in the same family.  The added abstraction and encapsulation seems like it would start to become overly complex or cluttered for it to be easily read by humans.  With every interface having multiple subclasses and factories, any UML diagram or visual would start to get cluttered or cumbersome if a program has multiple interfaces that create families of objects.  Making the code more efficient and organized doesn’t mean we’re making it easier to read.  We should remember that it’s humans that will edit our work after all. Though, since it seems like factories in general are prevalent, I’m sure I’ll become practiced enough that they aren’t daunting.  I just don’t want to be the guy who makes someone else’s day difficult because his code is hard to read.

Using abstract factories also avoids using conditional logic, it seems.  The usual factory design pattern would use if statements or switches to decide which subclass to return but, as I said before, each subclass has its own factory.  The abstract factory then returns the subclass depending on the input factory class.  Conditional statements aren’t necessarily difficult to write and understand.  The appeal to avoiding them, to me, is avoiding certain errors all together.  I have less to worry if less of my code can throw an error.  Also, if the program were of a larger size, there may be a so many conditions that writing a case or if statement for everyone would become painstaking.  Being able to avoid errors and making code easier to write is an attractive feature.

Just like the other factory patterns, I can see there is a place for abstract patterns in the workplace.  Now I just want to be sure I know when and how to use them.  I’ll certainly be practicing with them.

Simple and Static Factories


This week’s blog, as with the last, will be about a topic directly covered in class.  And, more importantly, it’ll be necessary knowledge for the first assignment of my class making it a good choice to review.  The above linked article is about factory design patterns.  In class, we only covered the use of simple factories whereas this article covers factory method pattern, abstract factory pattern, and static factory methods as well.  Since I have a length limit, I’ll cover the most pertinent material first while focusing on things I learned outside of the classroom about their use.

Starting with the Simple Factory first.  The author informs us that a simple factory isn’t considered a pattern technically but notes that it’s prevalence requires covering.  They describe it as a tool that can be “to create/instantiate objects,” but it’s one that is rarely used.  More commonly a static factory would be used in java.  If the developer’s “factory method needs some instances to work” or “they need to instantiate the factory in order to use it,” then the simple factory works fine but a lazy static factory is still advised.

Since Static Factories are more resourceful it seems, lets discuss them in more detail.  The first use he notes is the static factory’s ability to replace a constructor to “create an instance. The first advantage I see from this is the fact that factories have names.  Any unique constructor name can only be used once in a class.  Any time a class would need multiple constructors with the same name, static factories can be used with more descriptive names to help anyone reading/working with the code.   Another convenience of static factories, as opposed to constructors, is that it doesn’t have to create an object when invoked.  This helps reduce creating duplicate or unnecessary objects.  One last noticeable boon is its ability to have stricter control over what instances exist.  Relating to the previous blog, this helps guarantee that a class is a singleton.

Although this concept was already covered in class, its importance requires mentioning.  A factory can return any subtype of its return type.  This, overall, adds great flexibility to the programmer.

The author does advise that factories (and most patterns) should only be used when necessary as they can make the code more difficult to understand.  Small personal projects most likely don’t require them but, they find good use when working in large projects.

This information, complimented with examples, was instrumental to my understanding of factory use and implementation.  Using factories seems like a great practice, when done appropriately.  It also is obvious that this is a core tool that I’ll need to have as a developer.  I know that this will be applicable to my immediate work.  But, beyond that, I’ll probably be using it on any project that requires me to create multiple instances of an object.  Especially when that allows me to avoid having to write nearly identical constructors repeatedly.  (Factories seem awesomely useful and a huge time saver.)

A closer look at Singleton Design Pattern

Seeing as we’ve started learning about design patters in class recently, I decided I’d explore a pattern further in depth.  Seeing as the singleton pattern was the last covered in class it was the one I chose.  Where most other sources would just condemn it as a bad practice, the article linked above does a good job of exemplifying both the pros and the cons of using the singleton design pattern.  One of the pros, something I learned as well, was how singleton classes can save memory by using lazy instantiation.  Opting not to assign memory to the variable until called; this method can create errors as well.  If multiple threads access the instance at the same time it will create multiple instances of the singleton class.  There are synchronizing techniques to get around the issue but it’d most likely be easier to use static initialization.  In static initialization, memory is allocated when the variable is declared.  The only difference this makes in the code is moving the creation of the object to where the variable is being declared.  Inheritance with singleton classes seems straightforward enough.   Any class inheriting from it will create more than one instance of the class thus violation the principle that only one instance can exist. However, if you wanted multiple singletons to inherit the same behavior, the code could be provided in an abstract class.  Although this may seem purely a shortcoming, it does prove itself when compared to static classes inability to work from interfaces.  One of the other major drawbacks that I learned about was that singleton classes couldn’t accept parameters which contributes to their limited flexibility.

The singleton pattern has me a bit conflicted with its use in java.  Although it seems like an easy way to create global variables in java, many of its drawbacks seem very limiting or painstaking with more complicated programs.  The linked article does, however, do a great job of showing and explaining how to create singleton classes and will differently be my go to for a reference.  Reading it was a great auxiliary to the lectures given in class.  Seeing how singletons work (and don’t), in depth, has also raised my confidence with working with them.  I’m sure that having a complete understanding of this design pattern will be useful as a tool to compare and understand the behaviors of other patterns.

Java Interfaces

Jenkov’s article is about a core concept of java and other object-oriented programming languages; interfaces.  As basic as the concept is to programmers, it’s important to have a full understanding of such core concepts.  And that’s where I think this article excels.  It does a great job at making the information much more learn-able, digestible.  Far better than the oracle libraries, Jenkov explains how to implement and work with interfaces in projects.  His article does a good job of explaining what’s in the examples and code.  The first he speaks of, after what an interface is and how to implement it, is implementing multiple interfaces.  Unimpressive it may be, but it helped me. It’s not like the code was hard to learn or understand.  It’s just a huge help to how I learn to see everything completely explained.  Just looking at an example isn’t always helpful to me.  Although in the case of implementing multiple interfaces, it would have been.


Beyond just what we can do with interfaces and inheritance, he explains how interfaces relate and operate with core concepts in object-oriented programming.  Opting to discuss the usefulness of interfaces as well as how to implement them.  This portion of his work was most beneficial to me.  To not only know how to create interfaces but to also know how to use them effectively.  Paired with his explanations, he gives examples of good coding practices with interfaces.  But he doesn’t explain only what interfaces can do.  He also warns of the short comings of interfaces.

Sure, they are awesome examples of polymorphism in programming but, they can be broken.  One of the things to be cautious of is having overlapping method signatures.  Something I learned; Java classes can only implement a method with a given signature once.  Thus, having the same signature in two interfaces is a problem.  However, it shouldn’t be too much of a pain as long as the programmer remembers what they’ve already written.

Another great lesson I got from this writing was on how inheritance can work with interfaces.  I hadn’t known before that interfaces could inherit from one another and any class inheriting from a child interface got everything from the parent as well.  The article gave me a good overview on how interfaces work as well as ideas and understanding on how and when to use them.