Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

4 Symptoms Your Software Might be in Trouble

DZone's Guide to

4 Symptoms Your Software Might be in Trouble

Is your software in dire trouble? These eight symptoms can show you. Object instantiation, explicit operations and implementation, and tight coupling may be signs of troublesome software.

· DevOps Zone
Free Resource

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

" A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want" - Niklaus Wirth

Software is inherently complex, and so is its development. Careless development may produce the desired product and win you the satisfied customer. But when the customer comes back with new requirements/features to be added, then it may put you in a lot of trouble.

How do we know that our software can put us in trouble and it may require redesign?

Before you start blaming stakeholders, look at the following 8 symptoms of troubling software, which may become hard to evolve and change:

  1. Object Instantiation to Concrete Classes
  2. Using Explicit Operations/Implementation
  3. Building Hardware or Software Specific solution
  4. Tight coupling
  5. Inability to alter classes conveniently
  6. Extending functionality by Sub-classing
  7. Dependence on object implementations
  8. Dependence on Algorithm

In the first part, we will examine the first 4 symptoms.

1. Objects Have Neen Instantiated to ‘Concrete Classes’ Explicitly

Specifying a concrete class name when you create an object commits you to a particular implementation instead of a particular 'interface'. 'Abstract Factory' and 'Factory Method' design patterns can help you to avoid such situations.

Sample Code:

Image title

2. Using Explicit Operations/Implementations

When you specify a particular operation, you commit to one way of satisfying a request. By avoiding ‘hard-coded requests’, you make it easier to change the way a request gets satisfied both at compile-time and at run-time. Design patterns to use in such situations are: 'Chain of Responsibility' and 'Command'. Sample code is shown in above picture.

3. Building Hardware or Software Specific Solution

External OS Interfaces and APIs are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies. Design patterns to get help from are: 'Abstract Factory' and 'Bridge'

A very common mistake that developers commit, for example, to explicitly use specific Database Client (MySql, Oracle etc.) rather than using Abstract Database Client.

4. Tight Coupling

Classes that are tightly coupled are hard to reuse in isolation; since they depend on each other. It leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain. To decouple such systems, you may refer to: 'Abstract Factory', 'Bridge', 'Chain of Responsibility', 'Command', 'Facade', 'Mediator' and 'Observer'.

Sample Code: 

Image title



Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Topics:
software engineering ,design pattens ,programming ,coding practices

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}