decoupling

How to decouple a Mode (normally expressed by enums) from its implementation in commands and their relationship? Is their a good pattern describing the loose binding between a mode switch (int, enum, string, ...) and its command calls? I want to add modes via config, so this must be (dynamically) easy extendable (without programming). I already know the command pattern (ICommand in C#/.Net). It could be an Dictionary of Commands and their related mode number, but what about the switching logic? It is possible to decouple context (switching descission, parameters) from the strategy to solve the

I am using web forms, C#, Asp.net. As we all know, in this model UI and business logic are often mixed in. How do I separate these effectively? The example I would like to use is: I have a GridView and a DataTable (GridView binds to the DataTable and DataTable is fed from the stored procedure). I would like the GridView (UI) and DataTable (business logic) to be decoupled. Is it worth it to write an wrapper for DataTable? Are there practical patterns that have been proved and tested that you could recommend to be followed? If someone with experience could shed some light, that would be awesome.

I have a model that requires loading external data from an auxiliary source. A number of web services exist that my model can fetch the data from (swappable), but I don't want to create code that will make it difficult to change services (costs significantly differ based on variable and fixed usage and it is likely changing will be required). I would like to create a driver to perform the interaction (and then create further custom drivers if the service requires switching). Unfortunately, due to the tight coupling of the driver and model, it does not makes sense to extract the code into a

Lets say we have class A in package A and class B in package B . If object of class A has reference to class B, then the two classes are said to have coupling between them. To address the coupling, it is recommended to define an interface in package A which is implemented by class in package B. Then object of class A can refer to interface in package A . This is often an example in "inversion of dependency". Is this the example of "decoupling two classes at the interface level". If yes, how does it remove the coupling between classes and retain the same functionality when two classes were

I came across "Stairway" pattern description in the "Adaptive code via C#" book and I don't really understand how this is supposed to be implemented: ( source ) So I have client assembly: using ServiceInterface; namespace Client { class Program { static void Main(string[] args) { // Have to create service implementation somehow // Where does ServiceFactory belong? ServiceFactory serviceFactory = new ServiceFactory(); IService service = serviceFactory.CreateService(); service.Do(); } } } Service interface assembly: namespace Service { public interface IService { void Do(); } } And service

I have a Python project in which I am using many non-code files. Currently these are all images, but I might use other kinds of files in the future. What would be a good scheme for storing and referencing these files? I considered just making a folder "resources" in the main directory, but there is a problem; Some images are used from within sub-packages of my project. Storing these images that way would lead to coupling, which is a disadvantage. Also, I need a way to access these files which is independent on what my current directory is. You may want to use pkg_resources library that comes