 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Lucian
Guest
|
 Posted: Fri Jan 12, 2007 1:30 am Post subject: how to really start oop? |
 |
|
Hi,
This OO thing bothers me, it's been some time since I browse this
forum, I read some materials and ... shame on me, I still don't get it.
I mean, ok, I am programming since the eighties, followed all
Pascal-Delphi editions, I consider myself pretty good at what I'm doing
and because sometime I use some OO concepts (singleton, factory,
builder mostly, nothing fancy) .. I used to say at job interviews that
I am an OO programmer, and of course I failed hard core OO questions,
lol.
Anyway, to make it short, I did downloaded some framework that you guys
talk about in here and thought I could try to change some application
that I have, to make it fully OO.
Hey, wow ... is it me or the whole thing slows you down like hell, I
mean, why do you guys consider it is much better coding this way? Does
it make better apps? Smaller? Faster? If better, why do you think is it
better. I can come up with a pretty decent application, non-OO, in
about two weeks of full-time work, why would I stretch my mind so hard
to do the same thing in ... what it seems now for me, a lot more time?
Ok, yeah, I see you guys are very happy having what you call forms
without code. Of course I also have tons of non-ui code, but if I have
to show in the UI some listbox, I (am ashamed that I do) prefer
*seeing* the listbox and set its properties using the object inspector.
I really think I did not start this correctly and probably some of you
might now what i'm doing wrong.
regards,
Lucian |
|
| Back to top |
|
 |
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 1:50 am Post subject: Re: how to really start oop? |
|
|
| Quote: | might now what i'm doing wrong.
|
"Catastrophic failure" ... dunno why, but in 90% of the cases I do type
"now" instead of "know"  |
|
| Back to top |
|
|
Harley Pebley
Guest
|
| Posted: Fri Jan 12, 2007 2:01 am Post subject: Re: how to really start oop? |
|
|
| Quote: | Hey, wow ... is it me or the whole thing slows you down like hell, I
mean, why do you guys consider it is much better coding this way? Does
it make better apps? Smaller? Faster? If better, why do you think is
it better. I can come up with a pretty decent application, non-OO, in
about two weeks of full-time work, why would I stretch my mind so hard
to do the same thing in ... what it seems now for me, a lot more time?
|
Well, that's a pretty big topic for a news group thread. Many books
have been written on this topic. But here goes... There are lots of
reasons. A couple I consider fairly important:
1) Testability: Forms are hard to test automatically. The more logic
existing in the forms, the harder it is to test using a framework like
DUnit, NUnit, etc.
2) Decoupling of business logic from UI: If you want to have a
different UI (or multiple UIs) then you increase the amount of work
with forms which have more non-UI code in them.
That said, I find it much harder to work on code when it's all mashed
into a form unit. It's a big ball of mud, not clear what does what or
the interactions between things. When you have different objects, well
named, which do specific things, it's much easier to understand and
modify without side-effects.
Regarding speed of development, remember part of the slowness for you
is because it's unfamiliar territory; you're on the steep part of the
learning curve. As you get more familiar with how to do it, your speed
will increase. Over the long haul, including debugging and maintenance,
having a well factored code base is faster than the small increase you
may get in the original coding effort.
Regards,
Harley Pebley
www.skylark-software.com |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 2:48 am Post subject: Re: how to really start oop? |
|
|
| Quote: | reasons. A couple I consider fairly important:
|
Thanks for stepping in.
| Quote: | 1) Testability: Forms are hard to test automatically. The more logic
existing in the forms, the harder it is to test using a framework like
DUnit, NUnit, etc.
|
Ok. I admit I never used DUnit, NUnit. I sometime make mistakes and
when the stuff goes wrong in most cases I am able to fix a bug in
minutes. The exception is multithreaded apps, where I admit sometime I
am slower somehow. So, frankly I don't think I'm missing much here, but
that's just my opinion.
| Quote: | 2) Decoupling of business logic from UI: If you want to have a
different UI (or multiple UIs) then you increase the amount of work
with forms which have more non-UI code in them.
|
Ok, I was expecting this (and other stuff) and here it goes: why would
I want that? Once I finished an application, with a good UI, I can
hardly think I would change the whole thing. I agree this probably was
very usefull when people switched from DOS to Windows, but how many of
you were so good back than to do that, instead of simply rewrite the
whole thing? I know for sure that I re-coded many apps to Delphi 1, and
that was all about it. I once had a job where my main task was to
replace a devex quantum grid with some custom company grid. The code
was non-oo and it remained non-oo (obviously). In fact I dare to say
there are so few OO folks (like you guys here), that I might never get
to maintain in my daily job any OO code at all, for the rest of my life.
| Quote: | That said, I find it much harder to work on code when it's all mashed
into a form unit.
|
Yeah, I know what you mean. I saw that in my career. It's not my style
however and also it is not the style of many folks outthere. In fact
what's wrong having a form stuffed with controls, where all attached
events have say less than 10 lines of code? What's wrong with having
form inheritance and other custom components and all this actually
reduces the code you have in a form to a minimum?
| Quote: | When you have different objects, well
named, which do specific things, it's much easier to understand and
modify without side-effects.
|
You're right and I surely do have many different objects in my apps for
that reason.
| Quote: | Over the long haul, including debugging and
maintenance, having a well factored code base is faster than the
small increase you may get in the original coding effort.
|
I have to take your word for that (and others of course). I am however
having doubts. Using MadExcept and other debugging tools, I believe
debugging is the same, it doesn't matter how the code is written, you
get to the bug (AV or leak) almost instantaneoulsy and the fix is
history once you spotted the bug. "Faster code" would be reason enough
to go OOP way, but are there any benchmarks one can look at? Having
some testing code in every unit, wouldn't that make for example an
application to at least start slower?
Thanks,
Lucian |
|
| Back to top |
|
|
Harley Pebley
Guest
|
| Posted: Fri Jan 12, 2007 6:54 am Post subject: Re: how to really start oop? |
|
|
| Quote: | 1) Testability: Forms are hard to test automatically. The more logic
existing in the forms, the harder it is to test using a framework
like DUnit, NUnit, etc.
Ok. I admit I never used DUnit, NUnit. I sometime make mistakes and
when the stuff goes wrong in most cases I am able to fix a bug in
minutes. The exception is multithreaded apps, where I admit sometime I
am slower somehow. So, frankly I don't think I'm missing much here,
but that's just my opinion.
|
Using unit testing you get to know:
- during the development process that you have a bug rather than during
testing;
- during debugging and maintenance that changes which you just made
didn't break previously running code;
- that you have a fairly good interface on your objects. If it's easy
to test, it's going to be easy to use.
| Quote: | 2) Decoupling of business logic from UI: If you want to have a
different UI (or multiple UIs) then you increase the amount of work
with forms which have more non-UI code in them.
Ok, I was expecting this (and other stuff) and here it goes: why would
I want that? Once I finished an application, with a good UI, I can
hardly think I would change the whole thing.
|
A little bit ago, we changed our UI from having a standard Windows
look/feel to a customer's corporate standard. It would have been much
harder if our domain model wasn't separate from our UI model. As it
was, we found many places where we weren't as disciplined as we would
have liked to be in keeping things separate.
In today's environment it's pretty easy to see that someone might have
a Win32 app which needs to be migrated to both a web app and a .Net
app. Another possibility might be to support both WinForms and VCL
apps. If there isn't good separation, then this become much more
difficult.
| Quote: | That said, I find it much harder to work on code when it's all
mashed into a form unit.
Yeah, I know what you mean. I saw that in my career. It's not my style
however and also it is not the style of many folks outthere. In fact
what's wrong having a form stuffed with controls, where all attached
events have say less than 10 lines of code? What's wrong with having
form inheritance and other custom components and all this actually
reduces the code you have in a form to a minimum?
|
IMO (and there are others here who may disagree), there's nothing wrong
with that as long as the code that's on the form strictly has to do
with what's on the form and has nothing to do with the domain. One
example where it wouldn't hurt would be a form resize event which keeps
components sized correctly. An example which would be bad would be
setting a property on a domain object and doing validation checking on
the form rather than in the domain object.
| Quote: | When you have different objects, well
named, which do specific things, it's much easier to understand and
modify without side-effects.
You're right and I surely do have many different objects in my apps
for that reason.
|
I'm confused. I understood earlier that you said you weren't doing that
and didn't see a need for it.
| Quote: | Over the long haul, including debugging and
maintenance, having a well factored code base is faster than the
small increase you may get in the original coding effort.
I have to take your word for that (and others of course). I am however
having doubts. Using MadExcept and other debugging tools, I believe
debugging is the same, it doesn't matter how the code is written, you
get to the bug (AV or leak) almost instantaneoulsy and the fix is
history once you spotted the bug.
|
Exceptions are only one class of bug. There are many other classes of
bugs (in my experience the majority) which don't cause exceptions.
These tend to be incorrect behavior as an interaction among different
parts. If all the parts are in one big lump, then it's harder to see
(for me) what's happening. There are too many moving parts which I have
to keep track of. When things are separate, it's easier to isolate the
problematic bits.
| Quote: | "Faster code" would be reason enough
to go OOP way, but are there any benchmarks one can look at?
|
Do you mean execution speed? If so, then there probably isn't much
difference and in some cases OO might be slower due to an increased
number of function calls.
| Quote: | Having some testing code in every unit, wouldn't that make for example
an application to at least start slower?
|
Unit test code doesn't go in the units being tested. It goes in a
different unit designed for testing. Typically you have two
applications: your deliverable and your test app(s). The unit test code
is not bloating your deliverable app since it's only in the test
app(s). Actually using test code can make development faster. This is
because you test different parts of your application in isolation with
small test applications which start and run quickly. If you have a
large deliverable application, you don't need to start it and go
through a sequence to reproduce the problem each time you make a change.
Regards,
Harley Pebley
www.skylark-software.com |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:12 am Post subject: Re: how to really start oop? |
|
|
| Quote: | Using unit testing you get to know:
|
Ok. It really seems I should dig this stuff, I always thought it was a
waste of time.
| Quote: | A little bit ago, we changed our UI from having a standard Windows
look/feel to a customer's corporate standard. It would have been much
harder if our domain model wasn't separate from our UI model.
|
That's one thing I don't understand (believe) without seeing. I mean
with my limited or beter said zero OO techniques, I just can't see how
something like this would be "much harder". For me, if I'd have to
change the UI, copy-paste rulez. If the code copied was to ownerdraw a
listbox, it would work the same in a virtual tree, or paintbox or
whatever. Sure adapting the code will pose some problems, but the
issues will be considered bugs and get fixed pretty fast. Once again, I
can't see the "much harder" part.
| Quote: | app. Another possibility might be to support both WinForms and VCL
apps. If there isn't good separation, then this become much more
difficult.
|
That could be an issue, agreed. However I don't see that much action
around. I frankly believe Win32 will be around a bit longer than people
from .Net train tend to think, so
| Quote: | I'm confused. I understood earlier that you said you weren't doing
that and didn't see a need for it.
|
Well yeah, but I did not say I stuff all my code in one place. What I
am saying is that is very hard for me to grasp something like MVP or
other frameworks even more complex. My objects usually descend from
TCollection, TCollectionItem, TObject and VCL controls. That's pretty
much it. No MVP, MVC, OPF, etc. No Observers, Notificators, Accessors,
CommandSet, etc. What a heck, I am a Windows programmer, why should my
code tell Windows I selected an item in the listbox, when in fact it's
the other way around, Windows tells my code all about that stuf. Why
twist the messages and hard-core code all this stuff to make it look
like my hidden code commands the UI, when in fact is the other way
around (at least this is how it looks for *me*).
| Quote: | Exceptions are only one class of bug. There are many other classes of
bugs (in my experience the majority) which don't cause exceptions.
|
Hmmm, I have a complete different experience than. Biggest problems I
found at my daily job, maintaining older apps, seems to be crashes or
memory leaks. To write new features doesn't count as problem.
Ok, sometime, I have to make changes to the code that are quite
impossible without major rewriting ... but I guess if specs are unknown
or not complet, in the beginning of an app, even OO style might get
into trouble, right?
| Quote: | Do you mean execution speed? If so, then there probably isn't much
difference and in some cases OO might be slower due to an increased
number of function calls.
|
Yeah, I meant execution speed. Anyway, with CPUs getting faster by the
month, I wouldn't worry.
| Quote: | Unit test code doesn't go in the units being tested. It goes in a
different unit designed for testing.
|
Ok, I said I have no idea how DUnit stuff works. I'll try to make time
to get into that.
Thanks,
Lucian |
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Fri Jan 12, 2007 9:12 am Post subject: Re: how to really start oop? |
|
|
Lucian wrote:
| Quote: |
This OO thing bothers me, it's been some time since I browse this
forum, I read some materials and ... shame on me, I still don't get
it
[snip]
Hey, wow ... is it me or the whole thing slows you down like hell, I
mean, why do you guys consider it is much better coding this way? Does
it make better apps? Smaller? Faster? If better, why do you think is
it better.
[snip]
Ok, yeah, I see you guys are very happy having what you call forms
without code. Of course I also have tons of non-ui code, but if I have
to show in the UI some listbox, I (am ashamed that I do) prefer
*seeing* the listbox and set its properties using the object
inspector.
|
Ok, I'll byte. <g>
Just so you know where I'm coming from; from when I first learned to program
(in Fortran) to the time I first attempted to get my head around this OO
thing, was about 17 years,. While that is about, ummm, 18 years ago now
(wow!), I can still clearly remember both trying to get it - and trying to
get *the point* of it. It definitely took some time, but at some point it
happened - I found myself *naturally* thinking in terms of objects.
Taking your comments one at a time...
Slowing down? That depends on how you are coding things of course. How many
objects are you creating that your app would be noticeably slower? In
general, using OO is not going to make your app perform *faster*, but if
designed and coded well, it should also not be significantly slower.
Although various frameworks might introduce some overheads, at the pure
object level allocating an object generally has no more overhead than
allocating an equivalent record structure. One difference is objects are
typically allocated individually whereas it's easy and faster to allocate an
array of records in one go. But OO does not replace the responsibility to
code efficiently, you should minimize the number of objects you need to
allocate at any time just as you should minimize the number of records you
fetch from a database at any time.
Why is it better? Everyone that advocates it will probably say
maintainability is #1. The biggest reason for that, *even if you use nothing
else from OO*, is simply better organization of code - *encapsulation*. All
related methods that act on specific types of data are altogether in one
place instead of strewn around here and there in different units. Wherever
in an application you need to do something to some data, you should *not* do
it directly there, but call a method of the class representing that data to
do it. For both bug-fixing and later enhancements, that alone is worth it.
You'll always be able to see exactly all the functionality available for a
class of data and thus be able to make better decisions on how to change or
enhance things as well as it being easier to test.
The thing about forms without code? Forget it, it is a non-issue. While OO
can make such a thing easier to do, it has nothing to do with OO.
What is at issue at the GUI level is that it *is* a GUI - presentation of
data. Presentation should not be mixed up with *business logic (or rules)*.
There is lots of logic that is required at the GUI level, but it should only
be that needed to *present* the data and allow proper input from users.
If in a button click on one form, you write the code to calculate something
for your accounting app and write that to the database right there (or even
just update some set of global variables), and do various other such things
in different events strewn over any number of different forms, it very
quickly gets messy with everything dependent on everything else and no way
to see, in one place, all the related logic for specific kinds of data. That
kind of code *cannot* be reasonably maintained.
Now of course you can say such code can be better organized without using OO
and that's obviously true. Any number of discrete but related functions can
be coded in a single unit for the purpose, and limiting a single unit to
those functions for particular kinds of data - but then you are *logically*
using OO - the unit playing the role of the class. However, every function
either has to be passed all the data it needs to work on - which is really
much *less* efficient; or they operate on a single set of global variables
in that unit which means you can only have one.
By going the extra step and putting it together in a class, all the methods
know the data they are working on, there is inherent state among the
functions, and you can have any number of copies. Object constructors and
destructors also provide a consistent way to allocate and free that data,
whereas records can be allocated in different places without consistent
initialization.
When I was first reading about OO, the book said "...don't paint the shape,
tell the shape to paint itself". I threw the book across the room - I
thought it was stupid since I was still going to write the "same" code to do
the painting - I did not get the point. But it's really true, it is *that*
that makes the difference in organization. In my experience of working on
code originated by others, it's clear that many people miss this point.
Pretty much every project I've inherited fails on this very concept even
though the developer believed he was writing OO. The most recent example I
came across about a month ago was a set of classes done like this:
type
TConfigSettings = class
private
FDebugMode: boolean;
FDatabasePath: string;
{etc}
public
property DebugMode: boolean
read FDebugMode write FDebugMode;
{etc}
end;
Looks good so far - nicely hiding the data behind properties. But there's no
methods. Oh, here they are:
implementation
var ConfigSettings: TConfigSettings;
function IsDebugMode: boolean;
begin
Result := ConfigSettings.DebugMode;
end;
function GetDatabasePath: string;
begin
Result := ConfigSettings.DatabasePath
end;
{etc}
I happen to know the person that wrote this code has been using Delphi since
the first version. But he is still doing the the thing that I initially
didn't get when I threw my book back about 1988. These methods should be
*part of the object*, and there is no need to hide the instance of that
object (his way of enforcing a singleton).
Another common example of this issue:
Form2 := TForm.Create(Self);
Form2.Table1.Filter := 'blabla';
Form2.Table1.Filtered := True;
Form2.Table1.Open;
if Form2.Table1.RecordCount = 0 then
// message
else
Form2.ShowModal;
All this logic belongs in a method of Form2. Doing all these things *to* the
object is procedural coding. Asking the object to do the needed work
Form2.ShowProducts('blabla');
is OO. It lets Form2 control *how* it will show the data and creates
independence - e.g. if you decide Form2 needs to use a query instead of a
table component, or move from Paradox to Interbase, it all changes in one
place - Form2. All the places in the app that need to show products aren't
affected because they do not assume any *how* for Form2.
Of course the fact that there is a TTable in the form is another problem.
<g>
The next step is simply to apply that same single principle to "business"
objects - TProduct, TCustomer, TAccount, whatever.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"We've all heard that a million monkeys banging on a million
typewriters will eventually reproduce the entire works of Shakespeare.
Now, thanks to the Internet, we know this is not true." - Robert
Wilensky |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:12 am Post subject: Re: how to really start oop? |
|
|
Hi Wayne,
| Quote: | Just so you know where I'm coming from; from when I first learned to
program (in Fortran) to the time I first attempted to get my head
around this OO thing, was about 17 years,.
|
Hey, few hours ago I wanted to say almost the same things about me but
I took it out. Now that you mention it: I also started with Fortran and
it was about 22 years ago, writing code about 2-3 years later in both
Fortran and Pascal Oregon, but heck no, I am professional programmer
just since 1991, all about the same time :-)
Anyway, it's late now, I'll read carefully your post tomorrow and get
back to you.
Thanks for stepping in,
Lucian |
|
| Back to top |
|
|
Joanna Carter [TeamB]
Guest
|
| Posted: Fri Jan 12, 2007 9:12 am Post subject: Re: how to really start oop? |
|
|
"Lucian" <thanks (AT) nospam (DOT) com> a écrit dans le message de news:
45a6fc86 (AT) newsgroups (DOT) borland.com...
| For me, if I'd have to change the UI, copy-paste rulez.
And this is where, not just OO code, but even well-designed modular code,
wins out; you should *never* have to write the same logic more than once.
By copying, if you find a bug, you have guarantee to fix it in *every* place
that it has been copied. By using well-designed classes, you separate out
that logic into one well-encapsulated place; so that when you make a change
to logic, it is automatically propogated to everywhere that uses that method
of that class.
Initial development time, for those less experienced in OO, can be
considerably longer; hence the perception that OO is not as easy as the
copy/paste methodology. However, once you have a reasonable amount of skills
behind you, you will discover that you will write classes that can be used
in more than one place or even project.
In consulting for one company, their initial request was for me to design
"an OO GUI". what they thought they wanted was to separate out the UI
(written in Delphi) from business logic (written in Java). the first thing I
did was to define abstract Delphi interface definitions that encapsulated
the Java functionality. I was then able to write dummy Delphi classes, that
complied with those interfaces, to provide test data. Once the UI was built
and tested, it took a change in three (3) lines of code to make the whole
thing work with live data from the Java data engine.
What is more, once the UI was completed, the company realised that, due to
the modular design that I had achieved, they could use the major components
of th UI in, at least, two other applications, without any further
modification. this saved them tens of thousands of pounds of expenditure.
I now use the .NET framework; a well-designed and very comprehensive OO
class library. I have found many occasions when I would have normally
written my own little utility classes/routines, only to find that the same
functioanlity was already available in the .NET framework. The time and
money that this use of existing frameworks saves far outweighs the initial
learning curve.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:12 am Post subject: Re: how to really start oop? |
|
|
| Quote: | I'm confused. I understood earlier that you said you weren't doing
that and didn't see a need for it.
|
Looking at the questions in this forum, I feel awkward, like I'm
reading chinese. To list a few:
"What to learn first MVC or MVP"
"Lookup lists and an Object Edit form"
"How do you connect a model to a storage"
"ZeosLIB"
"Publish-Subscriber pattern"
"multiple level aggregation"
"can visitor return result"
etc.
I understand this stuff is ... hmm, hard, ok ... but where does it
start? I don't know, it's just seems to me the whole OO thing is a lot
of fuss and I really have the feeling the "OO code" is not easier to
maintain than the "not-so-much-OO code".
But than if I'm wrong, I'd really like to catch this train if
supposedly makes me life as a Delphi programmer easier.
thanks,
Lucian |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 8:43 pm Post subject: Re: how to really start oop? |
|
|
Hi Joanna,
| Quote: | And this is where, not just OO code, but even well-designed modular
code, wins out; you should never have to write the same logic more
than once.
|
I work full time and I am required to be light-speed fast. That's true,
bosses like stuff that's done in 5 minutes and I am giving them exactly
what they want. But then ... if I have to do the same thing a second
time, in 99% of the casses I do copy-paste, it's still faster than any
other method. And once again, if I have to do the same thing a third
time and I foresee it will happen again and again, that's exactly the
moment when I put all the eggs in one place, write a component or
something and throw it in my library and re-use it.
| Quote: | By copying, if you find a bug, you have guarantee to fix it in every
|
I know what you're saying. You are talking about bugs discovered in
copy-pasted code ... "later on". From my experience, it's not really
like that. When I do a copy-paste thing, most likely if I have a bug in
that code it will get corrected on the spot in both places, Writing the
same thing a third time, actually ensures that piece of code was 3
times supervised and usually reviewing the code for a 3rd time allows
me to end up with hard-core optimized code, where rarely or never I
have to look back.
| Quote: | separate out that logic into one well-encapsulated place; so that
when you make a change to logic, it is automatically propogated to
everywhere that uses that method of that class.
|
Which sometime does not work well. Never mind obvious bugs that get
fixed. Think of design flaws. So I have this "bad designed" application
that runs perfectly well on 2000 sites, now here comes my boss, wants
this thing in some other application and they both use a lot of code in
common. But in order to support the new features, you have to branch
the code because otherwise you break first app. It's a no-go and you
endup maintaing two branches of the code. Note, I said "sometime".
Otherwise you're perfectly right. Starting from scratch an app requires
you to do it nice the first time. In my career, only 15 years ago I was
required to write new apps from scratch. I used TVision and all was
fine. Since than, all the jobs I had, I was needed to maintain/improve
existing apps, some were bad designed, some were beautiful apps.
| Quote: | test data. Once the UI was built and tested, it took a change in
three (3) lines of code to make the whole thing work with live data
from the Java data engine.
|
Well ... "Once the UI was built and tested" ... I suppose those changes
were not exactly 3 lines. And how long it took you to make the new UI?
That doesn't count? Of course "when it was done", it took only 3 lines
and I wonder how you cut those 3 lines, why weren't those 3 lines
chewed up in the mix and so you can say "it actually needed no new code
to work with..."
| Quote: | I now use the .NET framework; a well-designed and very comprehensive
OO class library. I have found many occasions when I would have
normally written my own little utility classes/routines, only to find
that the same functioanlity was already available in the .NET
framework.
|
See, that's what diferenciate MS team and Borland (CG) team. Size. Of
course there is a lot of functionality in Net, compared to VCL. Stuff
that should have been in the VCL years ago and is not there now find
its way in .Net
| Quote: | The time and money that this use of existing frameworks
saves far outweighs the initial learning curve.
|
It really depends on the company. If, here were I work, all Delpheests
(about 4 from 30 employees) start learning OO, by the time we're done,
we will be out of jobs guaranteed. The company will probably sink in
the process. So, I have to learn at home, on pet projects, and I will
never have to make a living, for example using your MVP framework.
***
You guys are not really answering my question. All the stuff you are
trying to tell me about "why OO" and "what is OO" I already read from
many sources. My question is what a heck am I doing wrong, if, after
about 2 years of browsing this forum, I still have the feeling of
seeing Chinese in this posts :-(
regards,
Lucian |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:00 pm Post subject: Re: how to really start oop? |
|
|
| Quote: | To add to this... Now you wrote you wonderful application using
Forms as a GUI. Now the client wants the same, but web based. Now
all you logic you coded in your forms (button clicks, etc) need to be
found and reimplemented for the Web Interface.
|
Seems all you guys are contractors and you are talking about your
clients using "your existing code" in different ways. I truly believe
this is one best reason for going OO. For the full time jobs I have or
had nobody wanted to go web. Why would they? Just to access some
database that they don't have at home? The apps can simple connect to
wherever the database is, no web required. What other reason would
there be? Just to see your forms in IE, charge by the minute or number
of logins? That can also be incorporated in a non-web app. Easier
deployment? Maybe that's it. The thing is there are a lot of businesses
that dont or can't go web.
Lucian |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:15 pm Post subject: Re: how to really start oop? |
|
|
| Quote: | whole lot less than 25%. I'm guessing it was less than 5%. Does this
make it clearer?
|
Crystal.
| Quote: | have to implement this X times for each table on each form. With the
brokers, we just implement this 1 time in the broker.
|
Being there, done that. I just didn't know I was using "brokers". Are
you using something like what's called in here Mcv, MVP or other
framework for this big app with hundreds of forms? If so, was it done
directly this way, or how long it took to convert such a beast?
| Quote: | Duplicating code gets tagged with a priority 1 TODO.
|
Well ok, in my work it takes me a third time to have a TODO flag.
| Quote: | Have you ever thought about how they might have been written
originally to not require the rewrite?
|
Always. I rarely if never had to write an application from scratch, for
my day job. If I had to, they were small utilities, 10k-50k lines.
| Quote: | I think your premise is wrong. Speed hasn't changed much in the last
several years.
|
Yeah ok, I got that wrong. Truth is, for simple John Does, and usual
business, the speed CPUs currently have is more than enough. I'm not
talking games or big SQL consumers that will never have enough speed.
regards,
Lucian |
|
| Back to top |
|
|
Lucian
Guest
|
| Posted: Fri Jan 12, 2007 9:30 pm Post subject: Re: how to really start oop? |
|
|
| Quote: | of different programming techniques is OOSC/2 (Object Oriented
Software Construction 2nd Ed.) by Bertrand Meyer. It is a bit
|
Yes, thank you. I am also interested how steep the learning curve was
for you guys, when different approaches to learning were used. Beacuse
I don't suppose everybody learned OO the same way.
For example, will it take longer to learn OO by converting a reasonable
big app or learning in small steps get you there faster. It might seem
the second approach is more logical to follow, but if you end up in the
same spot faster, using first approach, I'd try that instead. I am sure
you guys have different experiences (in fact I'm kind of trying that
and got a little stuck).
Lucian |
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Fri Jan 12, 2007 9:31 pm Post subject: Re: how to really start oop? |
|
|
Lucian wrote:
| Quote: |
Seems all you guys are contractors and you are talking about your
clients using "your existing code" in different ways. I truly believe
this is one best reason for going OO. For the full time jobs I have or
had nobody wanted to go web. Why would they? Just to access some
database that they don't have at home? The apps can simple connect to
wherever the database is, no web required. What other reason would
there be? Just to see your forms in IE, charge by the minute or number
of logins? That can also be incorporated in a non-web app. Easier
deployment? Maybe that's it. The thing is there are a lot of
businesses that dont or can't go web.
|
The example of being able to very easily change the frontend is really just
a demonstration of the benefits, not the only purpose or goal. If you can
make it that easy to change the entire frontend, then by definition you have
made it that much easier to follow the logic, and therefore bug-fix,
enhance, and test that code in future even in the original forntend.
If the code is such that you have to basically rewite business logic (*not*
just strictly GUI logic) in order to move it to another frontend, then you
will have to thoroughly retest the entire business logic (are the right
things happening in the database?) as well as the new GUI logic.
In that case, even simply making changes to the *existing* frontend (but
which otherwise have not corresponding change requried to business logic -
i.e. no new fields or functions) means that the entire business logic also
needs to be thoroughly retested because your simple GUI change may have
inadvertently changed it too.
An example that has happened to me - client asks me to make a change so that
when they edit a particular field, focus is automatically moved to another
particular field rather than the next one in tab order. I make the change
thinking nothing of it, and later the customer calls back and says that the
calculated totals of yet another field are now wrong and the reports are
showing correct totals as well. Why? Because the original developer made it
so updating certain fields in the database was dependent particular events
of the controls and in some cases the order they took place. That is what I
mean by mixing GUI and business logic.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Some see private enterprise as a predatory target to be shot, others
as a cow to be milked, but few are those who see it as a sturdy horse
pulling the wagon." - Winston Churchill |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
