The Principle of Least knowledge also called the law of Demeter, as explained in Eric Feminella’s blog “Principle of Least Knowledge”, is a design principle that provides guidelines for designing a system with minimal dependencies.  It is summarized in short as “Only talk to your immediate friends.”

A client should have knowledge of an object’s member, and not have access to properties and methods of other objects via the members.

The example shown in the blog has three classes: ClassA, ClassB, and ClassC. ClassA has an instance member of type ClassB and ClassB has an instance member of type ClassC. This shows that all the classes are connected one by one, and this can be extended further ClassC if need be. Now believe it or not this example violates The Principle of Least Knowledge because it creates multiple dependencies, thus reducing the maintainability because if ClassA needs some work so would all the instances of ClassA. This creates like a domino effect and keeping up with the client could pose some trouble.

Now, like the blog explains, in software development there might be some trade-offs. If the program runs better optimally with the above method, then maintenance might need to be pushed aside for just that. But it’s an important goal for the software developer to minimize dependencies, and by following guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

The Principle of Least knowledge is very important when it comes to coding because when it comes to programming a client itself, it becomes very easy to callback other dependencies to make things easier. But this creates more classes that, in a before blog would be referred to as “master classes” and more redundant code is created, and other dependencies are brought into the mix.

In code it seems like it’s better off if some classes don’t know the inner working of their other class, I’ve seen many programs break entirely because of one class. These classes are dependent of other classes. When one class falls all the other classes fall with it. So, It’s important to implement these dependencies so that they can be changed easily. And it’s also remembered to implement in such a way that they don’t require these chains of dependencies involved. All in all, it’s best to create a program that easy to modify and refactor so that the code is easy to work with in future development.

Link to Blog: http://www.ericfeminella.com/blog/2008/02/02/principle-of-least-knowledge/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Refactoring is an important concept in software development that refers to the process of modifying and improving the internal structure of existing code without changing its external behavior. This can be a useful technique for improving the readability, maintainability, and performance of a codebase, and it is often an essential part of the software development process.

There are many reasons why a developer might choose to refactor their code. One common reason is to improve the readability and understandability of the code. Over time, as a codebase grows and evolves, it can become difficult to understand and maintain. Refactoring can help to clean up the code and make it more organized and easier to read. Another reason to refactor code is to improve its maintainability. As a codebase grows and changes, it can become more difficult to make updates and modifications without introducing bugs or breaking existing functionality. Refactoring can help to make the code more modular and flexible, which can make it easier to make changes and updates without breaking the code. Refactoring can also be used to improve the performance of a codebase. As code is written and optimized, it can sometimes become inefficient or slow. Refactoring can help to identify and remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a crucial concept in the field of computer science. As I read through the post, I found it to be very informative and well-written. The post clearly explained what refactoring is and described the various benefits it offers, such as improving readability, maintainability, and performance. I found the discussion of different techniques for refactoring code particularly interesting. Techniques like extracting methods or functions, renaming variables and functions, and restructuring code can all be effective ways to make code more modular, readable, and maintainable. I also appreciated the emphasis on maintaining the external behavior of the code during refactoring. This is something I will keep in mind as I continue to learn software development. Although refactoring wasn’t required in this class, I plan to use what I learned on future projects and when working with others on a team. I will refer to this resource as I continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022, https://medium.com/@liams_o/fundamental-software-architectural-patterns-663440c5f9a5.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

For this week, I chose to read the pattern ‘Create Feedback Loops’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, finding feedback on your progress. I chose this pattern because chapter 5 had the best info to digest, in my opinion, because I’m at that stage in my software craftsman career that where these patterns are the most relatable to me and will only prove to be more useful to me as time goes on. The context for this pattern is, not being able to tell if you’re unaware of how unskilled you actually are. By being unaware of your skill level, you are worse at assessing your own skills and when you do receive feedback, it’ll come as a surprise to your self assessment instead of a support mechanism to help you improve. I thought the context of this problem was spot on, the Dunning-Kruger effect came into my mind when I read this, sometimes people are too falsely confident of their own skills and clearly haven’t been told their real skill level on a certain subject matter. Ever since I became aware of the Dunning-Kruger effect, I’ve been trying to be more open minded to discussion and debate if I’m wrong on something.

For the problem of this pattern, it says your self assessment is only relative to the abilities you used opt have, you will always lack objectivity. I was not sure what this meant at first and I still don’t, however the next few parts that it describes I can relate to. It describes how being in a above-average team will make you feel like a superstar when in reality you’re more of a back up dancer, and how being on a below-average team will make you feel complacently smug. I can relate to this because in class, the backend team for the guest info system, they are definitely gonna go far in life as software craftsmen, I feel like they know what they’re doing which in turn makes me feel like I should know what I’m doing but, I’m just a back-up dancer.

For the solution of this pattern, you want to create mechanisms to regularly gather more or less objective external data about your performance. You will also want to be able to process the raw data from these mechanisms in order to get useful feedback about yourself. Honestly, the solution for this pattern was kind of confusing at first, I didn’t understand some of the mechanisms described but I’m sure in practice it is better than it is described.

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

The pattern I have chosen today is one about kindred spirits which is when one finds themselves in an unfavorable situation regarding the workplace they reside in or the kind of organization they work for, they should seek some sort of help from someone else. That someone else should be a mentor to you, someone that you want try to emulate, feel intimidated by while also feeling secure around them. These people will help you on your journey on becoming better software programmer whether it be by sharpening your skills or even just giving some extra motivation for you to push on.

The pattern mentions that on the long road, nobody walks alone and that some sort of cooperation is well needed for you to push on with your career. The path one has taken so far should be proof of that, you should have always had someone to help stimulate your learning with your teachers and classmates available for help. They have done a great deal of work helping you realize your career and you will soon see these go away as your enter your career. This means that you will need to start to put in work yourself to build new connections to new mentors and friends that have similar career interests. The sooner this is done, the better so that way the experience is gained earlier and you are setup before any new hardships happen.

I myself should start looking into different ways on getting of connecting to a camaraderie of those who are looking into similar lines of work regarding software programming. There are tons of different sites to look through and resources to use to obtain these connections and there are probably several in the university that I can use. The pattern does mention of it creating an irregular meetup of craftsman in the region that eventually becomes large enough to be self sustaining. I disagree on getting such thing to happen to be easier than one might think and that it is probably something the average craftsman wouldn’t be able to create. I myself don’t see myself creating such a group.

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

The pattern I read about this week is called Use the Source. This pattern is intended to show apprentices how to take advantage of the open source era. In the open source world, the ability of self-learning by reading and understanding source code is much more important than asking and waiting for answers from others. That is because only the code can tell you the truth, “the programmer’s intentions are irrelevant if the code disagrees”. That means it is always best when you can understand the code yourself without anyone telling you. However, the problem with this pattern is how to use the source, how to know if it is a good source and how to know if your work is good or bad when there are no exemplars or experts around you.

To answer those questions, the author has made many suggestions to help apprentices use the sources effectively. I can summarize them into two main ideas that an apprentice should adopt to become an expert. First, it’s about self-learning. All apprentices should seek out other people’s code to read and see the difference between the code written by all programmers. When you find any good programmers, you can learn to program like them. By reading the code, you should find out the intentions of the programmers, once you understand the codebase you can try to refactor them to ensure that you can build the projects independently. Taking the time to read and learn code written by other programmers is how you make other people’s tools your own; and that is also how you build your own toolbox, which is used to solve most of your career problems quickly and easily. Second, besides educating yourself from all the open source, you should learn from your community where you might have someone interested in reading your code and give you feedback. On the contrary, you should also be willing to read their code and be able to give them correct feedback or also be able to learn from their code.

In my opinion, Use the Source is the pattern that every programmer or every apprentice should use to develop their programming skills. That’s because I believe that reading the source is how you learn everything on your own; and this is also an opportunity for you to expose with other programmers to see their works and to also share your works to grow together. Moreover, as the author said that the software development field is lacking teachers; and there is no shortcut to learn all the tools for solving all the problems. So, I think open source is one of the most essential elements that no programmer can live without.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

I am choosing to write about this section this week because I can feel like I can relate to this topic deeply. In one of the opening statements of this section, the author talks about how people who have never failed or say that they have never failed have avoided pushing themselves or have just glazed over their failures. I agree with this statement. Another point that author brings up and I agree with is reflecting about your mistakes is not about ranting about the mistakes that we have made but rather it is a matter of character. We should be reflecting on our mistakes so that the next time we do something similar, we can make something better. This is a sentiment that I can really relate to because whenever I finish a project or assignment, even I did it correctly, I would look back at it afterwards and analyze my work to see what I could have done better or done instead. For example, if I barely finish something before the due date, I might look back at it and think to myself, “I wish I had more time and added this feature” or “this feature took a lot longer than I thought it would and that I should have managed my time better”. One point I disagree with is ranting about our mistakes. I think being able to identify the mistakes that we made is very important and when I talk or rant to someone about the mistakes that I made during a project, I am able to identify more mistakes that I had made that I did not realize before. Another topic that the author brought up in this section is the importance on certain skills or goals. I am finding myself agreeing more with this statement each and every day. I used to do the opposite and try to identify all of the skills that I am not good at and tried to get better at all of those skills at once. This did not end well. I often found myself spreading myself too thin. I found that I was spending too much time on one topic and not enough time on another. This led me to feeling that I had mastered no skills at all because I was trying to learn and master too many things at once. So, I am going to end this post by echoing something that was said in this section. At some point we need to realize we cannot excel at everything and that we need to know and accept our limits so that we can focus what we know we can improve.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.