How much is OOP being used in the business world, and how far could I get on VB6 or .NET alone?
Printable View
How much is OOP being used in the business world, and how far could I get on VB6 or .NET alone?
I use it pretty much exclussively. Everything else is just a script.
Do not ask how far you can get on .Net, ask how far .Net can get you. ;)
In modelling a high level application, OOP is very useful. I use it and modula programming in the sites that I make.
OOP is better than VB6. It lets you do things in a sensible fashion instead of thrashing a dead horse.
Object-oriented programming is a fad. It will die soon.
Hmmm...I believe the same thing was said about Rock N' Roll. :DQuote:
Originally Posted by yrwyddfa
I was going to say something along the lines of what wossname said, but he said it so much better than I would have.:DQuote:
Originally Posted by wossname
Yeah, perhaps you have a point.Quote:
Originally Posted by Hack
After all OOP has been around since 1965; no-one took much notice of it for another 25 years.
Perhaps it's because they were waiting for Moore's Law to come good to provide the vast numbers of transistors required for the huge code bloat these sort of practices require?
Perhaps it's because most of the seminal academics of the computer age agreed that the technology was of a very limited application?
Or perhaps it took off when IBM/M$ decided to make it look pretty, invest vast sums of money - equivalent to a small nation - to market the technology to anyone who was vaguely in hearing distance?
I wonder.
We used OOP disciplines in 1980 on mainframes when we developed our own RDBMS systems. The concepts are almost obvious.Quote:
Originally Posted by yrwyddfa
I just started a large scale commercial project in .Net and am using the strictest of OOP concepts that I can - I believe that's going to make the program develop quicker and less buggy - the separation of code/logic into proper objects almost delivers that for free!
Until you need to modify a superclass behaviour after delivery . . .Quote:
Originally Posted by szlamany
It should also make it tighter, easier to debug, more readible, and much easier to enhance and upgrade.Quote:
Originally Posted by szlamany
:lol:Quote:
Originally Posted by Hack
The only reason this could possibly be the case is because programmers are forced to actually think about design these days instead of just hacking out spaghetti code.
Those of us who have been using design techniques for years have never had the so called buggy/unreadable/unmaintainable code problems.
Having to modify a superclass after delivery might mean you should have thought out the architecture more carefully ;)Quote:
Originally Posted by yrwyddfa
Or charge more for the modification!
Using OOP can still be garbage for a poor programmer - thinking out the "whole concept" in advance is one of the most important aspects of design - that RESEARCH part of R & D.Quote:
Originally Posted by yrwyddfa
We took over a year developing prototypes in VB6 before we decided on an approach for our UI for maintaining data and displaying output queries for a user. With that done we can create new maintenance forms for any table structure without writing a single new line of VB code - that's well thought out system architecture!
Yeah :)Quote:
Originally Posted by szlamany
On a more serious note, and exactly in line with what you are saying, OOP delivers the goodies where a near-complete specification is known before the development effort begins.
If you haven't got one then you should be using component-oriented and interface based development.
It's a much more robust methodology for constantly changing software which is what IT departments in most businesses end up dealing with. After all, since when have users ever known what they really want?
If you want to use object-oriented techniques then you can hide the hierarchy behind the interface.
I work for a company where business needs change from month to month (some market driven, but most inept management :eek2: ) The IT team (4 of us of which two of us are developers - me being the senior one) get around two change requests a day. Doesn't sound a lot until you realise some 'easy' changes take days to complete, and test.
We are not allowed any IT downtime for maintanence during working hours (GMT 5:00->GMT 23:59) We have to implement any new software, whether changes or otherwise, during working hours (or get up really early) and whilst in use by our users.
Object-oriented programming is not suitable for this kind of work, nor will it ever be.
As a footnote: the implication of what I do is that I have to design for change. This is not a natural, nor implicit, feature of object oriented architectures. Sure, it may mean it can be changed, but let's face it you wouldn't want to unless to had to.
The systems I have designed are based on discrete component technologies based around COM+ (I know, dark ages and all that)If components need extended, GUI's need changing, implementation needs performance improvements - it's all easy.
One example, recently, is that I built a quotation system. The performance criteria was around 500 quotes/day.
But the users also had to fill in enquiry forms (by hand) and they insisted that they might as well do a quote whilst on the 'phone with a customer.
My quotation system, with a small performance analysis and improvement (the PCL rendering needed improving (string handling in VB6 is slow)) - which took around 3 hours scaled up effectively. It now handles 12k quotes/day, by fax, or by email with no additional hardware.
If I hadn't correctly factored the interfaces correctly or had inherited from goodness what it would've been much more difficult to plug in the new PCL string handling bit. (broken clients etc) With the recompilation, linking, and testing required I guess it would've taken days if not weeks.
We have the same "always" up requirements - that's why we took so long developing a user interface that "derives" what fields go on the screen from a table in the database.
There is absolutely no business logic in the UI - it's all in STORED PROCEDURES and TABLES in the SQL side.
If a fields validation changes, that's a simple adjustment to a SPROC on the server - can be done at any time - no system downtime.
If a new field must be added to a screen - we simply add a row to a FORM control table in the database and the next time the screen draws the field is on the screen. Change one or two INQUIRE and UPDATE SPROCS and the field is filled, validated and updated as if it's always been there.
We consider the separation of our extremely lightweight UI from the database-SPROC control layer to be n-tier in that the SPROCS are effectively acting as a data tier.
Many ways to skin a cat in this IT world of ours!
BTW - being a custom software shop means that all we get are requests for enhancements to software - that's how we make our bread and butter.
I've got a backlog of 6 months worth of work at any one time...
Where I said 'system' this means an n-tier system consisting of GUI, model, business, data.
I wish I had the luxury to fall six months behind!!!
Look how your personal vendetta against me crumbles when someone else agrees with something I say!! Now all I have to do to defeat you is say something sensible.Quote:
Originally Posted by yrwyddfa
Won't be easy. :D
Do I need defeating, then?Quote:
Originally Posted by wossname
EVERYONE does!!!
Ok, perhaps I don't know what OO means....or maybe I just don't know what it means to you.Quote:
Object-oriented programming is not suitable for this kind of work, nor will it ever be.
I realize there has been a long-running debate between OO purists who believe that everything must exist within a class hierarchy, etc, and those who believe classes can coexist with non-class based code.
It seems that if you are in the former camp, because I don't see how you can hold those views if you are in the latter. A "cherry-pick-the-useful-parts" approach doesn't seem to be consistent with your critisism of OO. I use a mixed bag, and I find it makes development both faster and cleaner.
If that last post was confused, I was interrupted several times while writing it. I ended up trying to figure out an ending to some of the sentences after my train of thought had struck a bread truck.
I don't see how my views are inconsistent.
What have I actually said?
(i) OOA/OOP cannot work without a full (or near full) specification at the outset
(ii) I use component oriented architectures
(iii) The components I use are well specified, so they can be implemented in an object oriented fashion
(iv) The components are protected behind a contract. That is the class hierarchy is always hidden behind binary compatible interfaces
Object orientation tends towards single applications not distributed ones.
What I meant, and perhaps didn't express well enough, is that for small parts (such as components, or light GUI's etc etc) object orientation is fine as long as the objects are local, private, or hidden, and solves many hard problems. I thing that for large distributed solutions the concept of a monolithic hierarchical architecture seems fundamentally wrong. It's just an opinion . . .
I realise that with .Net remoting this view is going to change. I think the jury is out on the efficiency of remoting objects over the wire (the proxy/stub architecture looks very similar to RPC, so I would assume that it has the same performance penalties as COM+ - you're going to have to find ways to marshal object state across the wire (XML serialisation?) and re-create a surrogate object on the client, I guess - just like VB6/COM)
I should clarify that this is a "single application" - and not a distributed one.Quote:
Originally Posted by szlamany
And the complexity of this single application - it's a Crystal-reports-like UI for editing report specifications - will benefit from the strictest of OO methodolgies (where is that SpellCheck - RobDog?)...
Even as we add layers and enhance the classes during development - it will still be easier to enhance due to OO concepts.
But then what do I know ;)
Object orientation is a superb mechanism for designing and building monolithic well specified applications - of which the vast majority of them are MS Word, Excel etc etc etc; even operating systems come under the same banner.Quote:
Originally Posted by szlamany
But for distributed, multi-server bespoke applications it's a real pain, and the only sensible way to go is to use component/interface oriented programming. Inside the components, of course, you can use object orientation to your hearts content . . .
:)
Do you like troll around stalking my old posts looking for something to post against?? :D ;)Quote:
Originally Posted by yrwyddfa
If you don't mind me asking but what the heck does that mean?Quote:
Originally Posted by wossname
Of course ;) :thumb:Quote:
Originally Posted by szlamany