Design Patterns – Applying Different Taxes Based on Various Factors

You probably meant to have Environment as a Facade (facade pattern) and not to implement every detail in it.

Break out all functionality into other classes. Imho each of the responsibilities below should be handled by a separate class that the Environment class uses internally.

1. Keep information about services in the environment,i.e. environment definition (Service is another class)
2. Start/stop services meeting some criteria
3. Apply configuration changes to different service and keep list of updated services
4. Restart services with configuration change
5. Revert configuration changes at the end of session
6. Search/Give Service class based on criteria (name etc.)

Those should give you six new classes. It will probably lead to some other classes too so that you for instance can manage configuration from different classes.

Most of the patterns from the GoF book have the following things in common:

• they solve basic design problems, using object-oriented means
• people often face these kind problems in arbitrary programs, indepently from the domain or business
• they are recipes for making the code more reusable, often by making it more SOLID
• they present canonic solutions to these problems

The problems solved by these patterns are so basic that many developers understand them mainly as workarounds for missing programming language features, which is IMHO a valid point of view (note that the GoF book is from 1995, where Java and C++ did not offer so many features as today).

The iterator pattern fits well into this description: it solves a basic problem which occurs very often, independently from any specific domain, and as you wrote by yourself it is a good example for "separation of concerns". As you surely know, direct iterator support is something you find in a lot of contempary programming languages today.

Now compare this to the problems you picked:

• writing to a file - that is IMHO simply not "basic" enough. It is a very specific problem. Nor is there a good, canonic solution - there are lots of different approaches how to write to a file, and no clear "best practice".
• Painter, Encoder: whatever you have in mind with that, those problems look even less basic to me, and not even domain independent.
• having the "power" function available for different kind of objects: at a first glance, that could be worth beeing a pattern, but your proposed solution does not convince me - it looks more like an attempt to shoehorn the power function into something similar to the iterator pattern. I implemented a lot of code with engineering calculations, but I cannot remember a situation where an approach similar to your power function object would have helped me (however, iterators is something I have to deal with on a daily basis).

Moreover, I do not see anything in your power function example which could not be interpreted as an application of the strategy pattern or the command pattern, which means those basic parts are already in the GoF book. A better solution might contain either operator overloading or extension methods, but those are things are subject to language features, and that is exactly what the "OO means" used by the "Gang" could not provide.