Please note that this question is NOT about any particular pattern - but
about the general objective of separating out presentation logic from
everything else.

I'm trying to "get a grip" on some of the patterns (e.g., Model View
Presenter) or strategies for separating UI logic from the underlying
business rules and data.

As I understand it, the general intent of doing this is to reduce
dependencies amongst our classes in order to make the system more easily
extensible and maintainable. So in the case of Windows Forms applications,
we ultimately want a Form class that only deals with UI logic - while all
business logic is in some other independent class.

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?

For example, in the Model View Presenter (or Controller) pattern, where
would we instantiate the Model and Presenter (or Controller) classes? The
View is obviously the Form class - but where do we actually *instantiate*
everything else in order to maintain the independence we're trying to
achieve by breaking out these classes to begin with? My thought is that if
they get instantiated in the Form module, then the classes are not really
independent - given that the form class must know what object type to
instantiate.

What am I missing?

Thanks for your time and consideration.