Category Archives: CS-343-02

Design Patterns

https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

 

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.

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

A SOLID Foundation

https://softwaredelivered.wordpress.com/2013/06/03/way-to-patterns-even-more-solid/

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.

 

 

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

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, https://thebojan.ninja/2015/04/08/high-cohesion-loose-coupling/

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.

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

Java Interfaces

http://tutorials.jenkov.com/java/interfaces.html

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.

 

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.