To OO or not to OO

[Edward]

I don't know if this has been covered here, but a search didn't reveal
a good fit. Sorry in advance and all that.

SCENARIO. Small software house used to building small, bespoke apps
using VB6, Access VBA etc.

The customer has two related products built using VB5 and VB6, which
they wish to amalgamate into a shiny new product using VB.NET FYI, it
will use a SQL Server backend, Terminal Services etc. A thin-client
thang.

Three developers have been given the task of building this. One has
about a year's experience of ASP.NET, the other two are more or less
new to .NET None has any substantial OO experience. The required
system has the same forms and logic as the old system, so there is a
good chance that business processes can be just cut and pasted from
the previous apps.

The new app will have about 70 forms and 30 reports.

HOWEVER. The software company tend to build similar products for
different clients, and think that building up a set of generic base
classes for use in all projects would be a good idea. The bible for
this would be Rockford Lhotka's 1 on 1 VB.NET Business Objects. This
would require a) one or more people to design the classes and b) the
team doing the current project to be able easily to use them. The
team doing the project are nervous about this, and would rather just
build the app in the same old way that VB always worked, since that
would mean that the maximum code could be reused from the old system,
and would do away with the learning curve and debugging problems
associated with complex OO inheritance issues etc.

Any thoughts?

TIA

Edward

 

[_Andy_]

I don't know if this has been covered here, but a search didn't reveal
a good fit. Sorry in advance and all that.

SCENARIO. Small software house used to building small, bespoke apps
using VB6, Access VBA etc.

The customer has two related products built using VB5 and VB6, which
they wish to amalgamate into a shiny new product using VB.NET FYI, it
will use a SQL Server backend, Terminal Services etc. A thin-client
thang.

Three developers have been given the task of building this. One has
about a year's experience of ASP.NET, the other two are more or less
new to .NET None has any substantial OO experience. The required
system has the same forms and logic as the old system, so there is a
good chance that business processes can be just cut and pasted from
the previous apps.

The new app will have about 70 forms and 30 reports.

HOWEVER. The software company tend to build similar products for
different clients, and think that building up a set of generic base
classes for use in all projects would be a good idea. The bible for
this would be Rockford Lhotka's 1 on 1 VB.NET Business Objects. This
would require a) one or more people to design the classes and b) the
team doing the current project to be able easily to use them. The
team doing the project are nervous about this, and would rather just
build the app in the same old way that VB always worked, since that
would mean that the maximum code could be reused from the old system,
and would do away with the learning curve and debugging problems
associated with complex OO inheritance issues etc.

Any thoughts?

TIA

Edward

I'm an OO puritan. If you're going to go the OO route, it should be
designed by someone who knows OO very well. The application you
mention has quite a large interface, and that is always the slowest
part in development.

Your developers may or may not be aware that some things that used to
work in previous versions simply don't work in VB.NET. The language is
quite different (as well as the API).

The only way to ensure speedy development given your circumstances is
to reduce the height of the learning curve. Either abandon .NET (not
good), delay and retrain (quite good, if it's an option) or Skunkworks
the project from the outset (bad practice but, hey, that's how they
build Netscape).

There are a million documents on Business Objects, Object Layers,
Smart Objects etc. etc. but most papers are waste of time. Some design
patterns can increase developer workload by a factor of 20 - which
will slide any project. The basic OO approach is enough to get you
through anything, and there's less piss and wind.

I recommend a tight control approach. Get your technical lead to write
a coding standards document, and have weekly code-reviews after the
project has started, chaired by the same. The project manager or
stakeholder should not attend those meetings. Decisions in these
meetings can lead to production of reusable code, normalised standards
and dissemination of knowledge. All Good Things.

As a practical approach, the likes of Business Objects is not
warranted in these circumstances; you're doing what is essentially a
port, and not a complete redesign and redevelopment (that would be
nuts). To be crude: blat it out as fast as you can using any way you
can. Once done, factor the code (this minimises testing time by you
only unit-testing the objects that change).


Rgds,

 

[Cor]

Andy,

Nice written, I did try to write something like that, but was afraid to get
a long response from all OO puritans, so I stuffed it again.

Cor

 

[Edward]

On 29 Oct 2003 00:46:00 -0800, (e-mail address removed) (Edward) wrote:

<snip>
I'm an OO puritan. If you're going to go the OO route, it should be
designed by someone who knows OO very well. The application you
mention has quite a large interface, and that is always the slowest
part in development.

Your developers may or may not be aware that some things that used to
work in previous versions simply don't work in VB.NET. The language is
quite different (as well as the API).

The only way to ensure speedy development given your circumstances is
to reduce the height of the learning curve. Either abandon .NET (not
good), delay and retrain (quite good, if it's an option) or Skunkworks
the project from the outset (bad practice but, hey, that's how they
build Netscape).

There are a million documents on Business Objects, Object Layers,
Smart Objects etc. etc. but most papers are waste of time. Some design
patterns can increase developer workload by a factor of 20 - which
will slide any project. The basic OO approach is enough to get you
through anything, and there's less piss and wind.

I recommend a tight control approach. Get your technical lead to write
a coding standards document, and have weekly code-reviews after the
project has started, chaired by the same. The project manager or
stakeholder should not attend those meetings. Decisions in these
meetings can lead to production of reusable code, normalised standards
and dissemination of knowledge. All Good Things.

As a practical approach, the likes of Business Objects is not
warranted in these circumstances; you're doing what is essentially a
port, and not a complete redesign and redevelopment (that would be
nuts). To be crude: blat it out as fast as you can using any way you
can. Once done, factor the code (this minimises testing time by you
only unit-testing the objects that change).


Rgds,

Brilliant. Just what I wanted. If you don't mind, I will dolly this
up into a memo and this can form the basis of my thoughts (such as
they are) on the matter.

Edward

 

[Jay B. Harlow [MVP - Outlook]]

Edward,
In addition to Andy's comments, I totally agree, OO is the route!

In addition to Lhotka's book, which may be a good framework for the core of
your project. However an OO approach around DataSets may be an less time
consuming development route.

I would recommend (in this order):

"OOP with Microsoft Visual Basic .NET and Microsoft Visual C# .NET - Step by
Step" by Robin A. Reynolds-Haertle, from MS Press. Introduces the "how to"
of OOP in VB.NET rather well.

"Visual Basic Design Patterns - VB 6.0 and VB.NET" by James W. Cooper, from
Addison Wesley. Introduces the "how do I" of OOP design patterns to VB.NET &
VB6 rather well, its a good companion to the GOF Design Patterns

"Design Patterns - Elements of Reusable Object-Oriented Software" by the GOF
(Gang of Four = Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides),
from Addison Wesley. Introduces and documents the "core" design patterns,
think of design patterns as pre defined concepts in how to do things in OOP.
The Cooper book puts a VB.NET twist on this book.

"Patterns of Enterprise Application Architecture" by Martin Fowler, from
Addison Wesley. Introduces

"Refactoring - Improving the Design of Existing Code" by Martin Fowler, from
Addison Wesley. Introduces Refactoring http://www.refactoring.com which "is
a technique to restructure code in a disciplined way", which allows you to
take your existing code and carefully and methodically modify it to a more
OOP design. In other words you can upgrade your VB6 project, then over time
apply Refactoring to move it to a 'pure' VB.NET OOP design.

Of course there is a plethora of articles at http://msdn.microsoft.com &
http://msdn.microsoft.com/architecture

Hope this helps
Jay