Source: https://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/

The Law of Demeter Is Not A Dot Counting Exercise by Phil Haack on hacked.com is a great read on the applications of the Law of Demeter. Phil starts off by analysis of a code snippit to see if it violates the “sacred Law of Demeter”. Then proceeds to give a short briefing of the Law by referencing a paper by David Bock. He then proceeds to clear up a misunderstanding or usage of the Law of Demeter by people who do not know it well, hence the title of his post. “Dot counting” does not necessarily tell you that there is a violation of the law. He closes out with an example by Alex Blabs that when you apply a fix to multiple dots in one call, you effectively lose out on code maintainability. Lastly, he explains that digging deeper into new concepts is all and well, but being able to explain disadvantages alongside the advantages will show a better understanding of the topic.

Encapsulation as a concept introduced to me, is about encapsulating what varies. However, different applications like the Law of Demeter which is specific to methods. It is formally written as “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit”. The example in the paper by David Bock makes it easy to understand where this is coming from with the Paperboy and the Wallet example. Having methods that have access to more information is unnecessary and should be left out. Also, letting the method have direct access to changes made by another method is a bad idea. By applying the Law of Demeter, you encapsulate this information which simplifies the code in one class but increases the complexity of the class. Overall, you end up with a product that is easily maintainable in a sense where if you change values in one place, it will apply across the board to where it’s used.

Although encapsulation is not a new topic, knowing how to properly apply encapsulation for methods through knowing the Law of Demeter should be a good practice. This would be remembering that “a method of an object may only call methods of the object itself, an argument of the method, any object created within the method, and any direct properties/fields of the object”. For example, knowing that applying the Law of Demeter to a chained get statements is a good idea. Also, the importation of many classes that you won’t use is a bad idea. With this understanding, although incomplete, I will hopefully avoid violating the Law of Demeter and share it with my fellow colleagues.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

I chose the topic after googling about the different types of software architecture and realizing I’d never read about microservices. I chose this specific article titled “Microservices” because I know Martin Fowler’s blog contains reputable information as he’s also been referenced in class. Microservices architecture is a way of designing applications as groups or suites that can be deployed independently as a service. While he mentions there is no exact definition, this style usually has similar characteristics around capability, automated deployment, endpoints intelligence, and decentralized control of data.

The microservice style is a newer and more common approach for enterprise applications. It’s a single application as a suite of small services. Each service runs in its own process and usually communicates with an HTTP resource API.

One key feature of microservices architecture is componentization via services. The different services of an application are a way to break down the software by components. These services are out of process components that communicate using web service requests. An advantage of using services as components instead of libraries is that they can be deployed independently. Therefore only requiring a single service to be deployed when there is a change.

A second key feature of microservices architecture is that it is organized around business capabilities. This approach combats the negative effects of separate teams working on an application as management usually splits focus between the technology layer, leading UI teams, server-side logic teams, and database teams. Services allow teams to be cross functional and include a full range of skills as products can be split up by individual services and communicate via a message bus.

Some of the more brief features of microservices architecture include the idea that a team should own a product over it’s lifetime and not just treat it as a project. Additionally microservices usually follow a decentralized governance which is less constricting and allow each service to take advantage of different technology that best suits the service.  Lastly decentralized data management is common using microservices. Typically each service will manage its own database.

After reading this article I definitely have an idea of what microservices architecture is but I think I’d need a more beginner level article to explain it. There were definitely some terms and concepts that Martin referred to that I wasn’t familiar with. One thing I did like about the Article was that he mentioned how well known companies use some of the technology he was talking about such as Amazon and Netflix. Seeing as microservices are mainly used for enterprise applications I have yet to gain any experience with them but most likely will in the near future.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For this blog I’ll be covering the basics of functional testing based on the article I read titled “Functional Testing Tutorial“. Although this topic is a pretty broad topic, it will compliment my previous blog covering “What is non-functional testing?” Functional testing is when each function of an application is tested and verified that it satisfies the specifications and requirements. Most functional testing is black box testing and does not deal with any of the actual code. To test all of the functions in an application testers provide input to the function and verify the output with what is expected. This is carried out either by manual effort or automated testing.

Aside from testing each individual function, functional testing also checks system usability, system accessibility, and error conditions. Basically a user should not have difficulty using a system and in an error condition, the correct error message or procedure should be followed. In order to carry out functional testing there is a basic testing process that must be followed. First identify the test data or input, then calculate the expected outcome and values, execute your test cases, and last conduct a comparative analysis to make sure all expected outputs match the actual outputs.

The article moves on to compare functional and non-functional testing to give an idea when each is used. Functional testing is usually done first and can be manual or automated. The testing coverage is used to ensure business requirements are met based on inputs. Functional testing is more a description on what the product or system actually does. There are a lot of ways to implement functional testing for a system. Some of the most popular types are Unit Testing, Smoke Testing, Sanity Testing, Integration Testing, White Box Testing, Black Box Testing, User Acceptance Testing, and Regression Testing. A few of the popular tools used to execute these tests include Selenium, Junit, and QTP.

After reading this article I’m confident I’ll be able to classify a type of testing between functional and non-functional. The article didn’t go too specific into the execution of functional testing but that’s because there are just too many types to generalize the implementation. When I want to actually execute and implement functional testing I’ll have to read more in depth into one specific type in order to actually test a system. I think the most important concept of functional testing is to remember that the business requirements are most important. That being said it will be important to make sure the business requirements are fully understood through the development cycle to ensure proper test coverage.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

We’re beginning to work on our final class projects using Angular and TypeScript, both of which I was previously unfamiliar with before this semester. Since our projects will be implemented using the Angular framework and the TypeScript programming language, I want to learn more about the concepts behind these applications. I found an informative blog on the subject; it is entitled Angular: Why TypeScript? by Victor Savkin. The main topic here describes the benefits of using TypeScript in general, and how it is an efficient means of producing quality Angular projects.

Victor points out that while using TypeScript for Angular projects is not required, but is encouraged to be used within the framework for several reasons; many of which I will summarize here. I will also offer my personal thoughts and takeaways regarding the content.

Prior to reading Victor’s blog, I was not familiar with the fact that Angular was written in TypeScript. Now it makes more sense to me why we are going to be using TypeScript to code our projects; since Angular was written in TypeScript, it ought to have high compatibility with that particular language.

Another encouraging aspect brought up by Victor is the fact that TypeScript is equipped with many useful tools, such as “auto-completion, navigation and refactoring.” Based on his explanations, I feel that TypeScript is a very flexible language; for example, if we need to rename an instance, it seems that TypeScript will automatically change all implementations of that instance to its new name without having to do it manually. I find this to be a very powerful and efficient feature that I look forward to using while coding future projects.

Victor also eludes to the fact that TypeScript is actually a superset of JavaScript, something I was completely unaware of. I find this fact very interesting in the sense that it suggests that anything that can be done in JavaScript can be implemented in TypeScript. Victor even suggests we can rename a JavaScript .js file with the .ts extension, and with the proper annotations, the program could theoretically run completely in TypeScript.

Victor further explains that TypeScript simply makes code “easier to understand” rather than other languages such as JavaScript. I tend to agree with him in the sense that it seems that TypeScript offers explicit declarations, such as that of parameters, interfaces and abstractions. It seems that JavaScript does not offer much of this functionality. Victor offers sample code, first implemented in JavaScript, and then again in TypeScript. In my opinion, the TypeScript code is much easier for me to comprehend due to the explicit declarations that are lacking in JavaScript.

Reading Victor’s blog has made me further intrigued with the capabilities of TypeScript; I learned that it is even more flexible and powerful than I originally thought. Based on Victor’s insights, I feel that learning TypeScript will be useful to me during my professional career, since he states that it is widely used in the field of Computer Science.

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

We’ve been discussing the differences between stubs and mocks, along with the fact that many software testers may initially assume the two are the same concept. But as we have learned, mocks and stubs are not synonyms; they are two different techniques used within unit testing.

I wanted to learn more about some specific differences between stubs and mocks, such as potential advantages and disadvantages of using each of these techniques. Wojciech Bulaty has an informative article on the subject. Before getting into the pros and cons of each aforementioned technique, Bulaty explains the main concepts of stubs, mocks, and service virtualization.

He asserts that stubs use hardcoded data within the testing program itself, where the tests depend on this data. Based on Bulaty’s description of stubs, it seems it would be most beneficial to me to apply stubs when testing simpler code where no more than minimal implementation of an interface is required.

Mocks on the other hand seem to be most useful in situations for larger, more complex tests to “verify output against exceptions.” In my opinion, mocks ought to be used in addition to stubs to further satisfy the integrity of our testing. For instance, mocks may produce findings that stubs could not, due to the limitations of the hardcoded data within stubs. On the other hand, I feel it may be useful to use stubs as well, to help compare its findings with that of the mocks within our tests.

Bulaty introduces a third method to use within our unit tests: service virtualization. I found this particularly interesting because we haven’t discussed much about service virtualization in class yet, and this article helped me learn more about it. He explains that service virtualization supports testing through multiple protocols, and employs “test doubles” which are usually offered as Software as a Service (SaaS). It seems to me that service virtualization relies more on recorded data from a wide scope of different projects, whereas stubs and mocks are typically written by developers of their own projects.

My main takeaway from this article was recognizing some differences in particular between mocks, stubs, and service virtualization that were previously a bit unclear to me. Whereas stubs seem to concentrate on state verification, mocks tend to be more focused on behavior interactions within our code. I also learned which testing techniques may be most appropriate in regards to the particular code we are testing. For instance, if I am testing simpler tests with limited resources, based on what I’ve learned from this article, I will likely use stubs for my testing. But for larger, more complex tests, I feel I ought to implement mocks within my testing as well. Finally, when I am involved in large scale projects during my professional career, Bulaty’s article has convinced me that I should look into using service virtualization in addition to stubs and mocks when performing unit testing.

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

Chain of Responsibility

      This week I chose to write about a blog that talked about the behavior design pattern known as the chain of responsibility. The post explained that behavioral patterns are used to build foundations that allow objects to communicate and give each other jobs to do. The chain of responsibility pattern makes it easier to chain objects into an order set and when a logical requirement or command is sent through the chain, it checks through the chain until an object is found that fulfills this requirement or command. It then goes on to explain some real-life applications for this design pattern like government and business systems where there is high value in order of commands. The post also clarifies that in the chain of responsibility the order moves upward rather than downwards which means that it starts at the bottom of the list and moves up. There is code shown afterwards that shows how the pattern works in a programming setting using book titles as an example. Using book titles, authors, and cover types, a chain of responsibility is created and tested by calling those objects based off one of those specific properties.

      This post really interested me because it was noted as a foundational design pattern which made it seem important to learn. The examples were helpful in this post as they allowed an easier understanding of the material using real code. The analogies that were used could be a bit better but overall, they weren’t too hard to grasp. The real-life applications that were shown were interesting but in my opinion there could have been more explanation as to what specifically this pattern could accomplish within business and government. The blog helped me solidify the idea that the chain of responsibility is created with objects and goes through each object to find the specific requirement needed. I did not know that the chain started from the bottom and went upwards which is good to know but I would like to know more about the efficiency of the order in the chain. More specifically, is there a way to efficiently order the objects in the chain to make it run faster? Does the order matter within the chain enough to influence efficiency? These were some questions that I still had after reading this post, but it was a good source of information to help me get an introduction to the design pattern. This material affected me by showing be a new way to code using a foundational design pattern. This will affect my future coding practices as I can now identify situations where I can apply this pattern to make it easier to organize and run better.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.