Questions and Answers
1) Suppose that you finish your game app, it’s in the Google Play store, and you are making a small but steady income. Then the money suddenly stops and the negative reviews pile up. Before long, you understand it is because the new release of Android 6.0 is out on the street, and your app crashes all the time even during simple operations that always worked before! In what ways might you have suffered from Programming by Coincidence? What is your plan for solving the problem?
Programming by Coincidence is the dependent on luck and accidental success. To a programmer, this is a dangerous approach and should always be discarded in favor of a reliable approach such as deliberate programming. Coincidental programming is more dependent on luck and there are several instances that this may appear such as due to minimal testing (Pragprog.com, 2015). Coincidences should not be adopted in favor of well-stipulated plans. In this scenario, the coincidental challenge arose due to lack of proper evaluation and consideration of technological changes. Before the release of any new or upgraded operating system, news are released to prepare the stakeholders in the industry of any prevalent changes. Therefore, the release of Android 6 must have been preceded by some educative news of the imminent changes and what to expect and plan. However, to the programmer, this variable was not taken into account. It is for this reason that the lack of information positions the programmer in a programming by coincidence position. Through an implicit assumption that the application will work in the same manner in the new version as it did in the old version leads the developer to suffer from programming by coincidence.
In such a scenario, the damage has already occurred. Simple tasks no longer work in the new version. The foremost action is not to be a slave to history (Pragprog.com, 2015). Code refactoring should be done and is inevitable. The developer needs to be flexible and learn the changes present in the new version, new rules, and concepts and program implementation principles that have changed. After this, effort prioritization follows followed by a well augmented plan that aims at deciphering the cause of the problem and providing a plan for the challenge (Pragprog.com, 2015). The problems in this scenario are better understood by evaluating how the program worked in the previous version and projecting the reasons why it does not work in the new version. It is paramount to determine the operating principles of the new version and compare them with a conceptualization approach with those of the former version. Doing this will ensure that the program is re-coded to adopt to the new changes inculcated in the new version. Lastly being away of what one is doing will enable the creation of a comprehensive application that is well documented to handle operational errors.
2) Earlier in the course, we discussed coupling and cohesion, and we tried to factor out the rules of the Memory Game from the Android interface. In what way does this change improve coupling and cohesion? How could we further improve the coupling and cohesion of the classes that make up our game app?
Coupling is a matter of degree while cohesion is a matter of relation. In the latter, when two variables or class are related, a change in one causes a change in the other class that contributes to both adding new value. Proper code structuring makes it adaptive, easier to change and maintain in the future in the event that other externalities such as the operating system change or get upgraded. Coupling and cohesion are two vectors that address a number of design problems (Jha, Bali, Narula & Kalra, 2014). Coupling as indicated in terms of degree invariably shows the extent to which classes are interconnected. There are two types of coupling, loose coupling, and tight coupling. Tight coupling implies that the levels are closely related that they know the functions of each other. In this scenario, the rules of the memory game dictate that the classes should be closely intertwined to save on operational costs. The implication here is that the game parameters must explicitly know the functionality of each other to save time and memory. In a game, the users are more dependent on the response time of the game and the design of the interface. It is inherently important for the developer to adopt a tightly coupled approach that addresses this challenge. A change to the new operating platform improves on the coupling but due to the compression, some functions and methods of the game fail to work and coordinate.
Some of the ways that can be applied in the game app classes to enhance coupling and cohesion include the elimination of inappropriate intimacy. The removal ensures that harmful and tight coupling does not occur. Increased cohesion will further ensure that the methods, data and functions of classes are closely related in terms of functionality (Jha, Bali, Narula & Kalra, 2014). When the levels are closely related, they will have well-outlined roles in the game application. Cohesiveness and coupling can be achieved by make divergent changes, feature envy, and shotgun surgery. The latter implies that a logical function or idea id spread across multiple classes.
3) Testing; Would you need to refactor your code? Use particular new tools?
Modules and individual units of the source code are tested in this approach. In the Android game app, different groups that are independent may be tested together prior to linking them with other modules, classes or functions. Procedure, principles and use of data control are carried out in this module to ensure that they cooperate to provide the desired output. Different interfaces, procedures, functions and classes may be tested individually in the app to ensure they work correctly. The testing should be done prior to integrating the application. Such an approach reduces any future errors once the units are combined together. For the application, the programming interface will be used to test this outcome.
Units and modules are combined and tested as a group in this approach. It is an intermediate level of testing that occurs after unit testing, but before validation testing (Utting, Pretschner & Legeard, 2011). Code may be refactored to comply with the set standards. Either a top-down or a bottom-up approach may be used to guarantee the satisfactory performance of the application. The testing will be run both on the programming environment and on the operating environment.
A test carried out on a completed system to ensure that it is compliant with the set goals and objective of programming (Utting, Pretschner & Legeard, 2011). For the Android project, this process would be tested using different devices to ensure that it provides the expected result. Different models of smartphones and tablets running the new Android version will be used to enhance this testing model.
Testing the graphical user interface is essential to ensure that the expected results are displayed. The front-end interface and the backend interface are to be tested to ensure that the outcome of communicates the system requirements. Security, documentation, hardware and software are tested to guarantee a successful outcome (Ehmer Khan, 2011).
Ehmer Khan, M. (2011). Different Approaches To Black Box Testing Technique For Finding Errors.IJSEA, 2(4), 31-40. doi:10.5121/ijsea.2011.2404
Jha, P., Bali, V., Narula, S., & Kalra, M. (2014). Optimal component selection based on cohesion & coupling for component-based software system under build-or-buy scheme. Journal Of Computational Science, 5(2), 233-242. doi:10.1016/j.jocs.2013.07.003
Pragprog.com, (2015). The Pragmatic Bookshelf | Programming by Coincidence. Retrieved 8 May 2015, from https://pragprog.com/the-pragmatic-programmer/extracts/coincidence
Utting, M., Pretschner, A., & Legeard, B. (2011). A taxonomy of model-based testing approaches.Softw. Test. Verify. Reliab., 22(5), 297-312. doi:10.1002/stvr.456