Re: when to use component-based design vs. stayign with traditional OOP

Responding to Ojas...

First, I can understand component-based design when it is obvious that
components will likely be reused, or when we want to leverage existing
components.

Does anyone know of a good web page that nicely summarizes best
practices for when, and when not to, follow component design versus
traditional OOP? And are there different implementation levels that
one can follow when implementing a component?

Let me push back with a question: What is the difference between component design vs. "traditional OOP"?

At some level both approaches identify a subject matter, encapsulate it, and provide an interface to its properties that captures invariants of the subject matter. IOW, in both cases reuse is enabled by cohesion, encapsulation, and capturing invariants. Thus in the OO case reuse is just a byproduct of good OOA/D design. So if one is holding a Component in one hand and an Object in the other hand, there isn't a whole lot of difference in their essential natures.

It seems to me the differences are really methodological (e.g., problem space abstraction for OO vs. bottom-up composition for components) or supporting infrastructures (e.g., COM/ActiveX or SOA). So the question becomes: When should a standard OOA/D construction approach be used vs. a component-based construction approach?

I think a component-based approach is ideal when there is a limited number of narrowly defined and stable entities that can, if necessary, be cobbled together to form more complex entities. A classic example is a suite of small analysis tools for stock brokers. Each tool is discrete, narrowly defined, and unlikely to change. In addition the tools can be combined for more complex tasks like portfolio analysis. They can also be conveniently accessed by multiple clients.

OTOH, I would use an OOA/D approach when the entities are complex, are used in unique ways for different contexts, and have a tendency to change over time. IOW, one-size-fits-all creates unmanageable complexity. The forte of OOA/D is that one can manage complexity by providing different, simpler views of the same entity for particular contexts through abstraction.


Is there a web page anywhere that explains how to properly implement a
component? For example, should it thoroughly check all input
parameters, should it gracefully throw a published exception when
methods are called out of sequence, etc. To what extent should the
component be made idiot proof? I'm asking because this comes at a
cost in terms of development time, QA time, and processing overhead
(impacts performance).

Why:

I am working on a new product, and it is a product where nobody will
ever want to reuse any of our classes for other products.

In Visual Studio we've broken the product up into multiple projects
that use each other to simplify development on it given we have a half
dozen developers working on it.

This is a non-UI product, and it is highly specialized.

Assuming we do not need reuse of our large-grain components, for
example a component could be an adapter for reading and writing data
to a specific data source type (SQL Server), it seems like over-
engineering to have the main classes in these project files conform to
strict component contracts.

The public methods on our classes will never be used by anyone other
than the immediate small development team.

For example:

* do we need to have the component handle any invalid input values by
throwing an exception? For example, if someone passes a list, throw
an exception if any list element is null.

For your example, an exception is appropriate because your software should not have passed a null list. IOW, if you got a null list the software is already broken.

OTOH, using exceptions to manage flow of control for *expected* problems is a bad idea. Thus if the user can provide invalid input due to typos or asking for a DB record that isn't there, then that sort of problem should be detected and handled with normal flow of control because handling the problem is part of the requirements (at least implicitly with any user-provided data because users screw up).


* do we need to have the component gracefully throw exceptions anytime
a dev makes an incorrect call sequence?

I'm not sure what a 'dev' is here, but the basic rule is: raise an exception when the software itself has gone unstable and use normal flow of control for handling all other situations.


* should we add unit tests for every invalid and valid input parameter
combination we can think of? And of course add and test the software
to make all of these unit tests pass.

Is this a trick question? You are developing software. Software should be tested.

How much testing you do depends on your company's business model (i.e., the trade-off between cost of testing and cost of escapes). I don't see what this has to do with component vs. OO development. For that matter, I don't see how exception processing would change for OO or component based approaches.



--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Relevant Pages

  • Re: perf & Try Catch
    ... I'd read that paper and unfortunately the statement "you only incur the cost ... The cost of the exception itself only occurs when it is thrown, ... In most cases the perf impact of these hits are amortized over a much ... >> Most of the perf hit comes from actually throwing the exception, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: when to use component-based design vs. stayign with traditional OOP
    ... practices for when, and when not to, follow component design versus ... When should a standard OOA/D construction approach be used vs. ... throwing an exception? ... of control for handling all other situations. ...
    (comp.object)
  • Re: Java Exceptions cause performance hit?
    ... In your comparison the number of iterations ... > compared to the cost of creating and throwing the exception. ... enables.So why does hasNext() exist? ...
    (comp.lang.java.programmer)
  • Re: perf & Try Catch
    ... The cost of the exception itself only occurs when it is ... > try-catch or try-finally gets JITd (the runtime uses this to determine ... >>> small perf hit in the catch block when the exception is caught because ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: why does IndexOf still return -1
    ... then you must either incur the exception cost or incur ... the search cost twice. ... The max length of the string is effectively cut ...
    (microsoft.public.dotnet.languages.csharp)