GSoC 2018: First week reading

This post contains a summary of what I have read on the first week of GSoC. Blogging what I have done helps me learn better, so that why I am doing this! In addition, I will highlight the keywords that make this easier to read ūüôā

Principle of least privilege

In Computer Science, the principle of least privilege (PoLP, also known as the principle of minimal privilege or the principle of least authority) requires that in a particular layer of a computing environment, every module (such as a process, user or program) must be able to access only the information and resources that are necessary for its purpose.

When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run and also launch applications with as few privileges as possible.

Benefits of the principle include:

  • Better system stability. When code is limited in the scope of changes it can make to a system, it is easier to test its possible actions and interactions with other applications. For example, when we apply the PoLP to our code, the scope of the new code will have effect on only the assigned parts. Therefore, it will be so much easier to test our new code and the unexpected bugs on the other parts of the project won’t happen as much.
  • Better system security. When code is limited in the system-wide actions it may perform, vulnerabilities in one application cannot be used to exploit the rest of the machine. For example, if there is one part of the project has a security hole, we would know that other parts of the project won’t be affected since the vunerable part does not have anything to do with the others.
  • Ease of deployment. In general, the fewer privileges an application requires the easier it is to deploy within a larger environment.

This is important for a student developer to remember since it suggests that we only need to develop on the functionality that we aim for. In addition, we should always consider if the new code can have an unexpected effect on other parts of the project.


Loose coupling

In computing and systems design, a loosely coupled system is one in which each of its components has little or no knowledge of the definitions of other separate components. Loose coupling is the opposite of tight coupling.


  • Components in a loosely coupled system can be replaced with alternative implementations that provide the same services. Components in a loosely coupled system are less constrained to the same platform, language, operating system, or build environment -> Easy to replace.


  • If systems are decoupled (separated) in time, it is difficult to also provide integrity (being whole). Data replication provides loose coupling, but creates issues in maintaining consistency, which can lead to data unsynchronization.

Methods for decreasing coupling:

  • Loose coupling of interfaces can be enhanced by publishing data in a standard format (such as XML or JSON).
  • Loose coupling between program components can be enhanced by using standard data types in parameters. Passing customized data types or objects requires both components to have knowledge of the custom data definition.
  • Loose coupling of services can be enhanced by reducing the information passed into a service key data. For example, a service that sends a letter is most reusable when just the customer identifier is passed and the customer address is obtained within the service. This decouples services because services do not need to be called in a specific order.


Law of Demeter

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly OOP. In its general form, the LoD is a specific case of loose coupling. The guideline can be summarized in each of the following ways:

  • Each unit should have only limited knowledge about other units. Only units closely¬†related to the current unit have its information.
  • Each unit should only talk to its friends
  • Only talk to your immediate friends.

The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents). It may be viewed as a corollary to the principle of least knowledge, which dictates that a module possess only the information and resources necessary for its legitimate purpose.


  • The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable¬†and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
  • A lower¬†Response For a Class¬†(RFC, the number of methods potentially invoked in response to calling a method of that class) can reduce the probability of bugs. Following the Law of Demeter can result in a lower RFC. However, the results also suggest that an increase in¬†Weighted Methods per Class¬†(WMC, the number of methods defined in each class) can increase the probability of software bugs, since each components are separated from each other so we will need to define more methods in each class. Following the Law of Demeter can also result in a higher WMC
  • A multi-layer architecture can be considered to be a systematic mechanism for implementing the Law of Demeter in a software system. In a layered architecture, code within each layer¬†can only make calls to code within the layer and code within the next layer down. “Layer skipping” would violate the layered architecture.


  • Although the LoD increases the adaptiveness of a software system, it may result in having to write many wrapper methods to propagate calls to components; in some cases, this can add noticeable time and space overhead.
  • At the method level, the LoD leads to narrow interfaces, giving access to only as much information as it needs to do its job, as each method needs to know about a small set of methods of closely related objects.¬†On the other hand, at the class level, the LoD leads to wide interfaces, because the LoD requires introducing many auxiliary methods instead of digging directly into the object structures. One solution to the problem of enlarged class interfaces is the aspect-oriented approach, where the behavior of the method is specified as an aspect at a high level of abstraction. This is done by having an adaptive method that encapsulates the behavior of an operation into a place, with which the scattering problem (which is created by having too many methods) is solved. It also abstracts over the class structure that results in avoiding the tangling problem. The wide interfaces are managed through a language that specifies implementations.
  • Since the LoD exemplifies a specific type of coupling, and does not specify a method of addressing this type of coupling, it is more suited as a metric for detecting deeper potential problems as opposed to a methodology for building loosely coupled systems.

Leave a Reply

Your email address will not be published. Required fields are marked *