Category Archives: CS-343

The Law of Least Knowledge

The Principle of Least Knowledge can go by many different names but the most common name today is the Law of Demeter. The Law of Demeter for Functions/Methods (LoD-F) is a design principle which is used for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.” This principle/law is more of a guideline than anything else. Some of its guidelines may include, each unit only having a limited knowledge about other units or objects and they should only be units or objects that are closely related to the current unit, each unit should communicate with its friends while not “talking to strangers”, and should only communicate with immediate friends.

The main idea behind this principle is that inside of our applications, the code that we write should only express knowledge of its surroundings. The guidelines of LoD promote a notion of Loose Coupling in our codebase, which can lead to cleaner code with more maintainability.

If we had a class that would implement a method, then the method should only be able to call a few objects. These include:

The object that owns the method.
Objects passed as arguments to the method.
Objects that are dependencies of the owner instance, which are held in instance variables.
Any object which is created locally in the method.
Global objects that can be accessed by the owner instance within the method.

On the other hand, if an object was to know too much about another, then this could be considered a bad design as the object would then have to traverse from top to bottom of the chain to get actual dependencies it needs to work with.

Overall, The Law of Demeter gives us a guideline on how to achieve loose coupling in our code and helps to properly encapsulate the knowledge of some complicated operations or logic into the places where they should be. By keeping this law in mind when producing our own codes and programs, it is sure to help us have cleaner code with increased maintainability and can help benefit the code we are producing when running it.

Principle of Least Knowledge

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Software Development Approaches

A software development approach is a methodology that is
used to guide the processes involved in the development of a software system.
Different software development approaches provide different ways of organizing
and coordinating the activities and tasks involved in the development of
software. Some of the most common software development approaches include Agile
development, Extreme programming (XP), Lean development, Test-driven
development (TDD), and Waterfall model among many much more. These are just a
few of the many different approaches to software development. Each approach has
its own unique set of principles and practices that help guide the development
process and ensure the successful delivery of high-quality software.

Agile development is a software development approach that
emphasizes collaboration, flexibility, and continuous improvement. Extreme
programming (XP) is a software development approach that emphasizes
collaboration, simplicity, and feedback. Lean development is a software
development approach that emphasizes the elimination of waste and the
continuous improvement of processes. The Waterfall model is a software
development approach in which the development process is organized into
distinct phases, and each phase must be completed before the next phase can
begin.

Test-driven development (TDD) is a software development
approach in which tests are written for a new piece of code before the code
itself is written. The goal of this approach is to ensure that the new code
meets the required specifications and behaves as expected. In TDD, developers
write a test that defines the desired behavior of the new code, and then they
write the code itself. Once the code is written, it is run against the test to
see if it passes the test. If it does, the code is correct and is ready for
integration with the rest of the system. If it does not, the code is revised
until it passes the test.

I selected this
blog post because I am interested in learning more about Test-driven
development. After reading this blog post, I learned about the principles
and practices of TDD and how it can be applied in the software development
process. I also learned about the steps involved in TDD, including writing a
test that defines the desired behavior of new code, writing the code itself,
and running the code against the test to see if it passes. I found this process
to be logical and straightforward, and I can see how it would be a useful
approach for ensuring the quality of new code. I made use of this method (to a
degree) while working on the homework assignments for this class. I believe
that it significantly simplified the process as having a set goal in the form
of tests, made it easier to update/ add code that will work with it. Overall, I
found this blog post to be very informative and useful. I learned a lot about development
approaches, and I plan to use them for my future projects.

Source:

Top 6 Software Development Methodologies