Refactoring is an inevitable location that all programmers reach eventually. Working on any project there is bound to be changes and new ideas or concepts on how to structure the code. With constant updates and inventions coming about everyday for the software world it simply is something we will all have to deal with. We create a program and find that we need to pass different parameter types to achieve a different outcome well now we have thirty plus methods to go back and change one by one. Now while that may be a necessary actions there is another concept to consider, that is adaptation! A good analogy of the Adapter Design Pattern is to consider a program is a cable you use to plug in an electronic device. Imagine that you travel to another country with your device and cable and now you run into the issue of a different wall socket. Your plug won’t fit even though it works just fine back home. Do you go out and buy a whole new wire to make it work with the new power source. No! Simply buy a wall adapter and your cable will work just fine(Of course you should check the voltage in real life, but the idea is the same). Perhaps there is nothing wrong with the structure of you code, you just need it to execute with different data types. By writing an adaptation class you could save a lot of frustration and time refactoring your original code. The adapter and adaptee could function by both implementing an interface and therefore the adaptee would only need to have an “implements … ” statement. In doing this you now have the ability to create any number of adapter methods instead of changing your original code. 

A nice simplistic example I found from an online article is that of the Rectangle class. Suppose you write a display() method to display the parameters of the rectangle to the user and the method expects the parameters x, y, w, h. However, the user wants to pass x1, y1, x2, y2 but this will cause an error in the display() method. If an interface is created that hold the display() method then if can be adapted in many ways and fix this issue.

My question to you is; do you think that adaptation is in fact refactoring. According to google the meaning of refactoring is “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”. Think about this, although I’m sure there is a clearcut textbook answer.

Design Patterns and Refactoring. (n.d.). Retrieved from https://sourcemaking.com/design_patterns/adapter.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

When I started programming, one subject I felt I never fully understood was the Inversion of Control design principle, in the context of using dependency injection when testing. These were commonly mentioned in tutorials, blogs, and documentation. My main takeaway was “make it another class’s problem”, so I think it’s time for a refresher on this topic to see if that holds true. Inversion of Control extends the Dependency Inversion principle, the D in SOLID.

Once again Martin Fowler has a great article on the subject, this time with code examples. Before I summarize his description, what is the problem that IoC solves? A picture says approximately 2¹⁰ words, so:

Fowler describes a MovieLister class that can act on the MovieFinder interface. This is great for the methods in MovieLister and makes it easy to modify, but MovieLister is also creating the implementation. It would be nice to change the implementation without modifying MovieLister, especially if we want to package MovieLister for use by others, who might need a different implementation of MovieFinder.

“We would prefer it if it were only dependent on the interface, but then how do we make an instance to work with?”

Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern

The basic idea is simple: create the implementation of MovieFinder in another class and “inject” it into the MovieLister. This can be done in a separate Container class, or an Assembler class.

Dependency Containers allow you to keep track of the classes that you must create and their dependencies. This container will construct the dependencies, create the object you need, and return said object. This isolates all changes to dependencies into a single class. Note that this is encapsulating what varies. The user only needs to decide on concrete implementations in their own custom Container. They can implement MovieFinder in a custom class and use in in their Container.

There are three types of dependency injections: constructor, setter, and interface. The difference is straightforward: either inject the dependency with a constructor at instantiation, a public setter method, or an interface method. Fowler prefers constructors and I’m inclined to agree. If possible, it is better to have a completely constructed object immediately.

I do think this really boils down to “make it another class’s problem”, but this phrase was misleading to me a few years ago. The problem I had with it was figuring out where to end the abstraction and create a concrete class, thinking it should be yet another class’s problem. It was tempting to misuse the design pattern, which left me feeling confused when I didn’t have a good answer. At some point, you need a concrete class to actually do the work. With this design pattern that concrete class is the Dependency Container.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

During the first week of my CS 343 class we were learning about reading and writing uml diagrams. I found a article on lucid chart called UML Class Diagram Tutorial which was a big help. Its URL can be found below for anyone who is interested. It talked about hiw “Class diagrams are one of the most useful types of diagrams in UML as they clearly map out the structure of a particular system by modeling its classes, attributes, operations, and relationships between objects”. It also said how a class is made up of three block the top being for the name of the class. It also says how the middle is for attributes such as class variables. It also says how the bottom is for all the methods of the class. It also talks about the member access modifiers like how public is a “+” and private is a “-” and and static is underlined . It also talked about some I did not know about from class like how protected is “#” and package is “~” and derived is a “/” . It also talked about how to do Interfaces and Enumerations. It also had some good examples of them. Most of this though I already understood. What really helped me was the explanation of the different connections between classes and interfaces and such. It said how Inheritance is “the process of a child or sub-class taking on the functionality of a parent or super class, also known as generalization. It’s symbolized with a straight connected line with a closed arrowhead pointing towards the super class” and had an example. This connection I was not to bad with already though. What really helped me was the explanation of association and why only one side had a arrow on it sometimes which I had trouble with in class. The first type that was talked about was a Bidirectional association. They said this was “ The default relationship between two classes. Both classes are aware of each other and their relationship with the other. This association is represented by a straight line between two classes.” The second one they talked about was a Unidirectional association they said this was “a slightly less common relationship between two classes. One class is aware of the other and interacts with it. Unidirectional association is modeled with a straight connecting line that points an open arrowhead from the knowing class to the known class.”. I really learned a lot from this article and will continue to refer to it in the future if I need to be reminded about how to write a UML or how to read one.

https://www.lucidchart.com/pages/uml-class-diagram

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

In many programs there will be an action taken only when something else has changed. For example, if there was a security app, you would not want it to continuously send you alerts that everything is fine, only when there is an actual emergency. This is where observers come in handy and in specific observer design patterns. Imagine you were creating an alarm system for inclement weather. Whenever there was inclement weather, an alarm would sound, a alarm message would appear on a phone, etc. Without observers, a person would need to run a clock that constantly checks for updates in the weather. By doing so in this process, there is a big strain on hardware. Observers send a signal when there is an update and does not require the constant checking for updates. When using observers, the design pattern should be set up such that there exists an interface called subject. This subject interface will be used to register and unregister observers, notify observers and get an update from the subject. The next interface will be the Observer interface which will contain an update method for the observer and a setSubject method, which is used to attach the subject to the observer. From here you will be able to implement these two interfaces. While implementing the Subject interface you will be able to create a class that overrides register, unregister and update the observer. When implementing the Observer interface, you will be able to override the update which allows for you to implement what the observer needs to be checking for. This allows for the user to have control over what the system is checking for. When that observer notices a change, it will be able to send a signal down to whatever class has extended subject and send out whatever notice must be sent when this event is triggered. By using this type of design pattern, the user is allowed to be very flexible while saving strain on the hardware that would normally be placed there by clocks. Many API’s use this type of design because as mentioned before, if an API had to have a clock running that was checking if someone had pressed a button every so-often, it would be chaos. The API is able to implement an observer for the buttons and when that button is pressed it updates the subject and executes whatever that button was programmed to do. This website gives a great breakdown of the design pattern and how to implement it.

Observer Design Pattern in Java

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

While looking at the course topics for my CS-343 class, the topic Law of Demeter caught my attention and I decided to dig deeper into the topic. I found a post by Arun Sasidharan called “Object Oriented Tricks: #2 Law of Demeter” which talks about what the law of Demeter is and how you should implement it into your code/design patterns. The Law of Demeter is basically that you shouldn’t give a single function the ability to know/navigate the entire system. Codes like ” obj.getX().getY().getZ().doSomething() ” has more knowledge of the structure system than it should. I think that it’s important to follow the Law of Demeter because not only does it look simpler to call only one method to solve a problem but it also avoids a possible security risk. If methods are able to be used and connected to figure out the layout of the system, then it makes the job of a hacker that much easier since they can figure out how they want to get to the information they want or to break the system.
The Law of Demeter seems to be a useful rule that helps to protect data and the overall structure of a system. I want to apply this to my own coding since it will simplify code and keep information secure. It seems that this is a difficult rule to apply and has some disadvantages to applying it as well like writing many wrapper methods and creating narrow interfaces. The Law of Demeter certainly fascinated me with how it can be used and why you should use it in your coding. I think that the Law of Demeter can and will be used as I learn more about it because for the most part I choose to take the easier approach in using multiple methods. Now that I know more about the Law of Demeter, I will look to apply it more in my code and find ways to avoid giving objects too much knowledge of the system structure. one thing that helped my understanding into what the Law of Demeter was was the use of the example of cells which was ” Cells don’t ask each other questions, they tell each other what to do”. this helped me to see how the Law of Demeter was applied and what it truly meant since the objects are the cells in this analogy, meaning that you shouldn’t have your objects asking around the system, the objects should be told what to do.

Link to Article Mentioned: https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

This week i picked the pattern, “your first language”. I was very interesting reading it. I got to know more about why you should learned your first language to perfection. At least master it well before learning another language. From the reading, get a language you like and very easy to use, is the best way to be a better programmer by mastering it. The reason is because all the programming languages follow the say pattern. Only different statement but the same principle. So by mastering one and feeling very comfy about it, make it very easy for you to learn new programming language with ease.

From the readings, to my understanding. I got to know by becoming very good at your first language, you need to ;

• Use the language all day, every day. Usually this means being full-time employed in the language.
• Read all you can about the language. Especially, “best practices” and idioms.
• Join a users group to talk with others about the language and what they do with it.
• Work with other people’s code! There is no faster way to learn what not to do in a language than to have to clean up after someone who did something awful.
• Support the code you write – every bug becomes a tour of your worst decisions!
• Study computer science and languages in general
• Learn a very different language. A great compliment to C would be a functional language like Lisp. This will turn the way you think about your procedural language inside out.
• Learn to use the frameworks and APIs available for that language.
• Take the time to do your own experiments with the language. SICP is not applicable to C, but the attitude of learning a language by testing its limits is a very productive one.
• Read the history of the language to learn why it was made the way it is.
• Attend conferences to hear the language authors speak, or to hear what industry leaders are doing with the language.
• Take a class in the language.
• Teach the language to others

As I said, reading this pattern made my understanding broadened. I really know by following the pattern given from the book will be a great fit for anyone who want to have a better and easy life at work in the future as a computer software or programmer.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my fifth individual Apprenticeship pattern I have chosen “Concrete Skills”.

Summary

Although you may have the skills to learn quickly, it is important to acquire and maintain concrete skills. This is because when you demonstrate that you have certain ability with specific tools and technologies it will increase your chances to be trusted enough to contribute with minor task until you start gaining stature, where at that point you will be able to contribute more directly. The concrete skills pattern suggests you to acquire the type of skills that would reassure your prospective team that they do not need to babysit you because you have skills that could be put to good use. It states that an “Examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice”. These concrete skills shows how you can benefit the company because it shows what you can bring to the table and be able to do on you first day of hire. According to the book a way you can show this by having “A deep understanding of Your First Language“. These skills are important in the beginning because as you “transition to the role of journeyman you will become less dependent on these skills, as you start to be hired on the basis of your reputation, your portfolio of previous work, and the deeper qualities you bring to a team”. Action to take are:

1. “Collect the CVs of people whose skills you respect.”
2. Identify five discrete skills on the CV for each of the people you chose, and then determine which one is useful for the kind of team you want to join.
3. “Put together a plan and a toy project that will demonstrate that you have acquired these skills. Implement the plan.”
4. Make sure you go through your own CV and separately list the concrete skills.

My Reaction

This pattern stresses the importance of developing concrete skills that would help you get hire in a job market. I agree with this idea. I found this pattern interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need to sharping up my concrete skills in order to show how I can be beneficial in the work place environment.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

There are going to be many situations in which we will not be able to figure out a solution to something. Deciding what to do in these situations is a big portion of solving the problem. Sometimes we can get very frustrated and give up. Other times we will try mundane fixes that won’t even solve our main issue. One thing that we need to realize, however, is that we are not alone. Most often than not, some issues that we run into have been solved by someone else. There is no reason to tread dead water if a solution is out there. Finding the way to this solution is a key part in problem solving. So, what do we do from here? We seek out help.

The thing I liked the most about this method is that by seeking help, it shows our willingness to understand and continue to learn. It also teaches us how to figure something out on our own, even if we don’t know what that issue is. One main part I agree with about this method is that it explains how, since this field of study is fairly new, it can be difficult to narrow down the “masters of the craft” because an apprenticeship can only mean so much. The difficult part is finding that one person who CAN teach you and guide to on the right path. One of the hardest part about mastering something is finding a that specific master or network of masters in order to reach the goals you have set for yourself. You can’t expect to learn everything on your own, this is an issue in itself. You need to seek help, evaluate that help, and then decide if it is worth your time to continue to learn by them. If not, that’s something you will have to decide. One great modern tool that we can use to do this is the internet. A simple google search can solve a lot of our problems, especially in this field of study. But sometimes we also should be careful at which sources we are pulling from.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.