Posted on

The Singleton Design Pattern

The Singleton Pattern

The singleton pattern is one of the simplest design patterns in Java. This design pattern is considered a creational pattern, as this pattern provides one of the best ways to create an object.

Sometimes it’s important for some classes to have exactly one instance. There are many times when we only need one instance of an object and if we instantiate more than one we’ll run into all sorts of problems, like incorrect program behavior, overuse of resources, or inconsistent results. You may require only one object of a class, for example, when you are creating:

Posted on

Logging As a Last Resort

Motivation

In software development one often finds themselves investigating issues. Depending on the type of the application, various sources of informations can be available: 

  • screenshots
  • verbal description of the problem
  • metrics
  • logs (application, framework, container, application server, OS, ...)
  • thread and heap dumps

In an ideal world, the exact inputs that caused an issue and the code that failed would be immediately available. In a typical case though, it can take hours of digging through logs and code to understand what happened. Would it not be nice to avoid that?

Posted on

Scalability :  Think in Terms Of TCO

A system that has the ability to easily scale resources to meet the increasing workload without affecting the performance is known as a scalable system. The workload could refer to anything from an increase in users, storage, or a number of transactions.

To make an easy-to-scale system, it is crucial to have an evolutionary way of thinking about the software development cycle. An architect should focus on designing a scalable software architecture from the early phase of the product life cycle.

Posted on

Coupling and Cohesion: Confounding Yet Critical Concepts

A deep but often-overlooked problem that perennially plagues software is that of high coupling and/or low cohesion. The underlying concepts are foundational to good software engineering, as they impact how hard it will be to comprehend, extend, and maintain a particular piece of software. Yet they can be quite confusing, and attempts to deal with them can be very misguided. Because a shallow understanding can do more harm than no understanding at all, the subtleties of these related concepts need to be explored.

To review very briefly, coupling is the degree to which distinct classes, modules, etc., are tied together, such that a change to one requires changes to others. Cohesion is the degree to which a class or component deals with just one thing. But rather than thinking of cohesion as tight internal coupling, think of it as the conceptual purity of a unit of software. This avoids some misunderstandings that can arise otherwise. I won't dwell further on the definitions, as others have done a good job of that.