For the last and final blog post in my capstone class, I focused on the apprenticeship pattern of “Retreat into Competence” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about perhaps how you are overwhelmed or beginning to realize how little you know, or perhaps you have taken on a new challenge and things are not working out so well. However, getting back into something you are good at is a nice way of regaining your composure. I completely agree with this statement, sometimes all we need a just a pullback to launch forward towards the goal. The quote provided at the beginning of the section is what stood out to me the most. It states that “You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been, and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.” This got me thinking very deeply about the past four years of college and my CS Journey. I have no idea what the future hold, but one day I will look back to see where I have been and possibly see a pattern emerge.

The author also mentioned how apprenticeship is a roller-coaster ride, you will experience the thrill of new technologies, but you will also experience struggles as just how little you know compared to the craftsmen and experts you meet along the way. It is important that Sometimes you need to take one step back to take two steps forward. But it is essential to move forwards as quickly as possible because the forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday. Another important aspect the author mentioned is how to seek support from your mentors, with their support and boost you can be on the right track again and display competence. In this way, you will be more equipped for future challenges. The patterns displayed a lot of insights towards my career and on a personal level. I will certainly be reading more patterns from this book even though this is my last and final blog post for the CS-448 class.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

The section “Be The Worst”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on situations where you aren’t able to learn much from your environment. Being on a strong team has its benefits, other members can cover areas where you are weak on and catch you before making mistakes among other things. Ideally, a team member should be able to take a step back from their team to accurately assess their skill and knowledge. In the case where the gap in skill or knowledge between yourself and other team members in vastly in your favor, then it’s likely that you won’t be able to grow much as a software developer. Because of this, it’s best to start out as the weakest member of a team, hence “Be The Worst”, in order to have room to learn and grow. Emphasis on “start out”; the weaker members of a team should work more to catch up to the rest of their teams. If they don’t bother, then the “Be The Worst” pattern kind of loses its whole point.

Fortunately, or unfortunately depending on how you look at it, I’ve never felt that I was the strongest in a team skill wise. Some of the people I’ve worked with on a team do things super quickly so I had to adapt by starting tasks early and refamiliarizing myself with certain concepts. I guess you could consider that a method of catching up with other team members. In a team setting, I don’t actively try to “Be The Worst” but I at the very least understand why it’s a pattern. If people aren’t challenged, then they’re tempted to stagnate and it becomes all too easy to end up as a big fish in a small pond. When someone better inevitably comes along, then those who’ve done nothing to improve are thrown for a loop and can’t easily adapt to that change. Though, people could also be motivated to do the opposite; work catch up or even surpass their peers in order to not be seen as the weak link.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

The section “Rubbing Elbows”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on a learning technique similar to “Record What You Learn” pattern which I wrote about during week 12 of this semester. To “Rub Elbows” in this context means to sit next to a fellow software programmer and exchange ideas. This could range from simply talking to each other during a lunch break to peer programming which is when two or more developers physically sit side by side and collaborate while they develop software. In any such case as these, a software developer will likely pick up on the small micro-techniques that are too trivial to be covered during active teaching. However, these techniques can add up and significantly contribute to the development of a software programmer. And when even if one were to disagree with their peer’s methods, they at the very least have gained a new perspective to view from. The same can be said in the case where there’s a knowledge gap between peers, which forces both of them to take each other’s viewpoints into consideration.

Again, like the “Record What You Learn” pattern, I’ve experienced and used “Rubbing Elbows” to an extent. In recent memory, me and a peer have helped each other study and do the work in classes that we share. We weren’t able to physically meet up since the pandemic but we occasionally talk to each other online through discord. I remember one conversation where he mentioned Python and I didn’t really know much of the language so I asked him what separated that with programming languages like C and Java. That got me interested enough to the point where one of my final projects for this semester partly uses Python code. There’s also a pet project that I’m toying around with, something to do with chess; I’m kind of tempted to research more of Python so I can write the code entirely in that language. It’s not what I’d describe as a micro-technique, but it’s something that I picked up while “Rubbing Elbows” with a peer.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

As I was reading about coupling and cohesion, I also came across the Principle of Least Knowledge, which just so happened to be on our list of topics in the syllabus.

The Principle of Least Knowledge (or Law of Demeter) was first discussed in 1987 at Northeastern University. It states that an object should never now the internal details of other objects, which makes sense given the name. It is used to promote loose coupling in software designs.

The article also gives an example using 3 classes – A, B, and C. Each class has objects objA, objB, and objC. objA is dependent on objB, which in turn composes objC. In this scenerio, objA can invoke methods and properties of objB but not objC. Say C has a method M. If you make a objC called O, the Principle of Least Knowledge says O can access

• The same object, i.e., the object “O” itself
• Objects that have been passed as an argument to the method “M”
• Local objects, i.e., objects that have been created inside the method “M”
• Global objects that are accessible by the object “O”
• Direct component objects of the object “O”

A code example is also given to illustrate the concept.

public class LawOfDemeterExample

    {

        //This is an instance in the class scope

        //and hence this instance can be accessed by any members of this class

        AnotherClass instance = new AnotherClass();

       public void SampleMethodFollowingLoD(Test obj)

        {         

            DoNothing(); //This is a valid call as you are calling a method of the same class

             object data = obj.GetData(); //This is also valid since you are calling a method

            //on an instance that has been passed as a parameter           

             int result = instance.GetResult();  //This is also a valid call as you are calling

            //a method on an instance locally created

        }

        private void DoNothing()

        {

            // Write some code here

        }

    }

After, an second example is given to illustrate what not to do.

var data = new A().GetObjectB().GetObjectC().GetData();\

In this example the client depends on all three classes A, B, and C. If any of the three change you will run into issues.

This principle will definitely be important as I continue my career in software development. As the ode I write gets more complex, I have to be wary of violating principles like this to maintain low coupling. The author also mentions testability being improved with this principle and the loosely coupled code it encourages. Next semester I am taking the software testing course; right now I have next to no knowledge about software testing. I only know how to just test units made for me in java. Hopefully I will see how loosely coupled code compared to tightly coupled code in testability.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

This week I wanted to learn more about coupling. The article I found happened to be about both coupling and cohesion.

Coupling and cohesion are both terms that refer to the modularity in a system. They help measure how complex the design of an object-oriented system is. Good knowledge of both is needed to build scalable systems that can be extended and maintained over time.

Coupling is how interdependent software modules are. With high coupling, software modules are very independent, and they need each other to run. There are several types of coupling:

• Content coupling — this is a type of coupling in which a module can access or modify the content of any other module. When a component passes parameters to control the activity of some other component, there is a control coupling amongst the two components.
• Common coupling — this is a type of coupling in which you have multiple modules having access to a shared global data
• Stamp coupling — this is a type of coupling in which data structure is used to pass information from one component in the system to another
• Control coupling — this is a type of coupling in which one module can change the flow of execution of another module
• Data coupling — in this type of coupling, two modules interact by exchanging or passing data as a parameter

Cohesion is how intra-dependent a software module is. High cohesion is a software module that forms its own meaningful unit. There are also different types of cohesion:

• Co-incidental cohesion — this is an unplanned random cohesion that might be a result of breaking a module into smaller modules.
• Logical cohesion — this is a type of cohesion in which multiple logically related functions or data elements are placed in the same component
• Temporal cohesion — this is a type of cohesion in which elements of a module are grouped in a manner in which they are processed at the same point of time. An example could be a component that is used to initialize a set of objects.
• Procedural cohesion — this is a type of cohesion in which the functions in a component are grouped in a way to enable them to be executed sequentially and make them procedurally cohesive
• Communicational cohesion — in this type of cohesion the elements of a module are logically grouped together in a way that they execute sequentially and they work on the same data
• Sequential cohesion — in this type of cohesion the elements of a module are grouped in such a manner that the output of one of them becomes the input of the next — they all execute sequentially. In essence, if the output of one part of a component is the input of another, we say that the component has sequential cohesion.
• Functional cohesion — this is the best and the most preferred type of cohesion in which the degree of cohesion is the highest. In this type of cohesion, the elements of a module are functionally grouped into a logical unit and they work together as a logical unit — this also promotes flexibility and reusability.

Tight coupling makes maintenance difficult as all the components depend on each other.

This article was helpful in explaining these two concepts. As we develop increasingly complicated software in our courses and careers it is important to learn more abstract concepts. These were things I have never really thought about before. Usually I write code just so that it works. If I am going a step further I might try to make it “look good” and be neatly indented with as few lines as possible. Especially going into the capstone course, I will have to evaluate my code for things like low coupling and high cohesion.

https://www.infoworld.com/article/2949579/design-for-change-coupling-and-cohesion-in-object-oriented-systems.html

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.