OOP or COP?

[Guest]

There has been some debate at my job as to whether we should use object
oriented or component oriented methodologies when developing our .NET
applications. i.e., A) developing generic, reusable classes that can be
used/reused and inherited from in any number number of discrete applications
or B) creating completely encapsulated, application-specific DLLs that use
common classes purely by taking an existing class that is stored in
SourceSafe and insering it into a project.

Does the COP method really bear any significant advantages over OOP that
would outweigh its drawbacks? What is Microsoft's recommendation on the topic?

Thanks!
-Jamie

 

[Stephany Young]

Sounds like the debate may be affecting productivity at your 'shop' rather
than the benefits of using methodology A over methodolgy B or vice-versa.

My view is that both methodolgies are equally valid and the question should
be which one should I use for a specfic prupose.

For some tasks, the answer may be that A is better than B, for some B may be
be better than A and for others a combination of both may be the appropriate
approach.

Be careful that you don't let philosophical correctness override common
sense.

 

[JiangZemin]

Hi, it really depends on what type of applications youre building, and also
the experience level your team has with both OOP and the specific business
domain you need to deal with.
Here is MSFT's application architecture guide (if you search for the term
"object-oriented" in this article it should narrow down to your interest):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/AppArchCh2.asp

Note: you could apply both approaches you describe. For example, you can
use approach (A) for more generic "helper"-type stuff. But the application
specific DLLs in (B) either reference the compiled classes from (A), or just
are "shared" thru SourceSafe (i assume you would not be making a separate
copy of that class in each project). this isnt very object-oriented... but
one thing to beware of is if your team members insist on a certain approach
"just because".
ie. this type of conversation:
Programmer A: "Hmm, maybe we shouldnt try to impose a stateful
object-oriented model on this set of web services we're trying to build".
Programmer B: "But then it wouldn't be OOP! And I know how to properly
design object models because we did a lot of them in Computer Science
class."

 

[Guest]

Thank you all for your input. Very good points. I guess I just needed a smack
in the head to realize I was being silly about it.

-Jamie