EnvironmentalDesign

"is to be friendly to the environment, not pollute."

"The only alternative to co-existence is co-destruction." - Jawaharlal Nehru

A solution should be environmentally friendly. Not just jumping on the Green band wagon, but our new design should fit well, within the current software.

An Environmental design:
  • Must obey the design philosophy of code surrounding it.
  • Should always try to extend existing designs positively and not pollute it.
  • Does not pollute the environment by introducing bugs or impact negatively.
  • Tries not to duplicate artifacts, shadow or repeat them unless required.
  • Does not pollute the minimal and maintainable design principles.



Intent

The intent of EnvironmentalDesign is to promote the ideas of designing what is best for the software environment, not just what is best in theory. The software environment may have specific conditions that make a generally good idea, not suitable.



Motivation

There are many good design ideas, implemented badly within a certain piece of software. It was forced and shoved into place. The design was good, but it did not apply to the situation and technologies very well. For example, it is relatively always a good idea to build software so that it can be extended. However, if the software is in a financial institution and that plug-in is easy to drop into the app, it can create a security hole. Also in a multi-threaded process, built on the need to execute quickly, it would be silly to force a global variable into the mix, unless extremely necessary as it would have adverse effects on performance.



Solution

Do your research. Is there a style of coding? Does it use conventions. What does the Framework expect? Would your change affect the code around it in a negative way. The solution has to involve another pair of eyes. This can be a person, a code reviewer, a designer or fellow developer, or even tests. most of the time it will be a combination of all.

  • Unit tests, so you can tell if your code has broken something else
  • Performance tests, so you can tell if your code has impact.
  • Usability testing, does your code improve or degrade the experience
  • Read documentation and study the domain and code enough
  • Ask the original developer/s about the area you are writing in


Solution: Prevent bottom layers affecting higher layers

For example, Exceptions should not travel all the way to the client, because it would pollute the user experience. Likewise, if your layer is using a library, wrap the exception into an Exception type that your layer provides to callers. Thus you don't let Exceptions thrown from below, travel to the top, without you wrapping it, before bubbling or dealing with it in some other way.
Your Layer should have one main MyLayerException, which wraps all Exceptions before throwing. This provides a caller with a clean environment.

Solution: Don't talk to strangers

Your code should communicate with objects it already knows, before strangers. Think twice about referencing a new component. Think twice about passing a parameter to an object of a Type that is not in the appropriate layer. For example: A SqlDataReader should never be passed to an object so that it can build itself from the reader. Instead, provide simple parameters or properties and set the object values directly or via another object. Introducing a SQLDataReader to a Business Object is not a good idea, as it pollutes the Business Object with ideas it should not know anything about.

Applicable Patterns

Factory Method (GoF)
Builder (GoF)
Template Method
Bridge (GoF)
Mediator
Proxy (GoF)
Visitor (GoF)
Low Coupling (Grasp)
Polymorphism (Grasp)
Indirection (Grasp)
The Single Responsibility Principle (SOLID)
The Open Closed Principle (SOLID)
Feedback (XP)
Develop Overall Model (FDD)


Conflicts
MinimalDesign, ReachableDesign, AgileDesign

Ammerse Principles