no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Making Design Decisions ======
+When designing software, you are constantly looking for solutions for certain problems. But when you have found one, it is still necessary to decide if it is a good (i.e. appropriate) one. If that's not the case, another solution has to be found. So how to assess if a solution is good?
+{{ :about:deciding1_bad.png?nolink&600 |}}
+Principles explain the aspects which can be considered for this kind of assessment. Principles tell good solutions from bad ones. And principle languages guide you to find the fitting principles for a given design problem.
+{{ :about:deciding1_good.png?nolink&600 |}}
+Sometimes there are several possible solutions. Maybe a colleague came up with an alternative solution or you had several ideas for yourself. Also in this case some kind of assessment has to be made.
+{{ :about:deciding2_bad.png?nolink&600 |}}
+Similarly to the scenario above the principle language shows which aspects to consider for deciding which of the given solution is the best (most appropriate) one.
+{{ :about:deciding2_good.png?nolink&600 |}}
+In general principle languages point to certain aspects and can be used as a guideline for designing software.
+{{ :about:deciding3_bad.png?nolink&600 |}}
+{{ :about:deciding3_good.png?nolink&600 |}}
+Principles are not patterns---rather they are "reasoning patterns". A design pattern is a solution but it needs assessment if it is appropriate to use a pattern in a certain situation. A principle is not a solution but a reason for preferring one solution over another one.
+{{ :about:deciding4_bad.png?nolink&600 |}}
+Patterns should only be applied with a good reason, because they typically also have drawbacks (most often complexity; see [[principles:Keep It Simple Stupid|KISS]]). Principles show the benefits and liabilities of using a pattern.
+{{ :about:deciding4_good.png?nolink&600 |}}
+In general principles are for solution //assessment//, not for solution //generation//. They tell if a solution is good or better than another one but they don't guide in constructing solutions directly.
+{{ :about:strategies_bad.png?nolink&600 |}}
+Nevertheless the wiki has a for each principle a "strategies" section, which gives hints on how to improve or refactor a solution in order to better adhere to the principle.
+{{ :about:strategies_good.png?nolink&600 |}}