Submit My Question - Recent Questions - Recent Answer

Msdn Tech >> Architecture >> Architecture General

Advantages of OOP ?

Hello,
Im a fun ofOOPdesigns. I design my bussiness classes when I start a new project. Then maybe I will writemapperclasses for bussiness classes to mapDBtables or using anO/RM tool or anODBMS.
Think that this project is big one and it has long deadline. You will develop it 2 or 3 years. Requirements will be changed. To develop this project with OOP designs andn-Tier application design is good idea. But I am asking myself this question "Why am I choosing this long way ?".
I think the advantages of OOP arere-usable and flexible(when there is a new requirement). OOP makes less code behind user-interface. But I dont understand the flexible.
Procedural coding style makes spagetti and silly coding. There will be repetition of code. It isnt flexible. You have to change everywhere if u had a new requirement.
Can somebody tell me if there is a new requirement won't I change anything in OOP design ? or do I think wrong ?
And If you need performance the fastest solution is procedural coding. OOP makes it slow.
At this point, Maybe you will use Dataset for procedural coding. What is the difference between to filldataset->datatable->datarowsand yourcustom collections ?
If you are working on huge data, dataset is always the fastest one.
If you are working onobjects, It usesCPUmore then dataset.
Im sorry but Im confused. I love OOP design coding but Procedural coding passes me.
And they say OOP isoversold: http://www.geocities.com/tablizer/oopbad.htm
And C#3.0 knocking the door. OOP world is improving I dont think Procedural will improve.
What do you think ?
(Sorry about my simple English)

[2774 byte] By [DogaOztuzun] at [2008-1-1]

«« Slow Startup from Idle
»» SqlServer PrimaryKey is not recognized by VS2005

# 1

just for helping the oop in this comparations i want you to say that: "procedural coding" is just a mess in a big project. In a big project is essential having a good documentation (teams will change), and clear ideas. If you make something like services, not soa, but clear oop design it will help you in re-utilizing the code and understand your system at the end.

If you make an spaghetti coding, in two years you won't understand the code, and as we say in Spain you will be doing blind punching, you just won't know what is wrong and what is OK.

I don't agree in what you say about performance.

creaturita at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 2

Doga Oztuzun wrote:

What do you think ?

I think you need to provide facts or benchmarks to back up your claims that "OOP makes it slow" and "dataset is always the fastest".

MattiasSj?gren at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 3

>>>I think you need to provide facts or benchmarks to back up your claims that "OOP makes it slow" and "dataset is always the fastest".

First of all yes! Typed dataset is really concrete and it is not flexible to your requirement changes.U even might lose staff when u have to regenerate it.It is far away from perfect.

1.But U can easily see design time errors.

2.They also provide rich data for paging,sorting and all kind of UI staff.

3.For requirement changes,for performance and also for JOINS u should use VIEW's in database modelling.U can also use VIEW's with typed datasets in ADO.net 2.0.

But I think your aproach with object modelling does not make sense.To access collections u have a custom collection where the WORST thing u can do in the business software development in terms of performance.Such as 12 million ORDERS can have 55 million ORDER_DETAILS and 5 million CUSTOMERS and no LAZYLOADING can help u.Object models tend to use RAM and CPU resources.U can have a more complicated object graph if u like...(slower)

Object oriented modelling is a nice theory.(...idealism does not work in practice).if u really go into object domain modelling.U will end up with all these things which are really not neccessary...

U have to deal with

A.identity Maps(read objects only once)

B.UnitOfWork(Transaction mechanism for your objects)

C.Topological Sort(To have right insert ,update orders)

D.Mappers(OR/M buy or build it...MS did not do objectspaces which was a cool decision)

E.Repositories(common place to retreive your collections,if u can...)

F.Specification patterns / Query objects(filtering mechanism in objects,POEAA)

G.Metadata Techniques.(some cool SQL reuse that makes the system slow,through code generation)

H.Design Patterns like FACADE to put everything under the rug...

Do u think is it worth it?

Alsoat the end of the day u will face the fact that u need performance.(as the users say so...)

Carefully looking at your UI code,u can easily find out that every user interface in your application has different aspects of data.And there is no ONE important aspect.(Like u have to love your mum and dad the same level...)

Object Models are not build to have many aspect of data as when designing them people don't think in a tabular way,they do think in a object way which is slow as their logic is eating RAM and CPU resources which are expensive.

So every VIEW must be differently aligned for your business application user interfaces.Yes typed dataset approach is not the BEST, but people should also know what they are getting into object world.

I don't mean do not use OO, we should use OO for some UI staff, but it is just no GOLDEN HAMMER that can solve every problem.

PS:Object collections are really small when compared to the collections in RDBMS.

Myth: OR/M vendors might claim if u don't do OO , u will end up with a non adaptable code.

Adaptability is in your head not in your code...

Tried Procedural with No analysis ...>> failed!,
Tried OR/M with custom business objects ...>> failed!,
Tried ObjectDatabases with generic object frameworks ...>> failed!,

Code ReUse OUT ! , Logic ReUse IN !

erdsah88 at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 4

"Adaptability is in your head not in your code..."

Does that mean that when I move on to another project the last project's adaptability goes with me? They'll never let me move on if that is the case...

"Code ReUse OUT ! , Logic ReUse IN !"

What is the persistent form of your Logic? (mine is code...)

Myth: OOP equals OR/M equals all those other things you've mentioned above.

YoniRapoport at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 5

>>They'll never let me move on if that is the case...

Nope! if u can't move on that means, u have failed in the analysis phase of your project...

>>What is the persistent form of your Logic?

The logic existed before c# and it will exist after c#,,java...etc.

Aristo did not need any computer code to express himself.U can express your self by code,that is your choice.

The Failure of OO systems is that they are tend to be seen as a GOLDEN HAMMER.

The business software development has many aspect that it is not wise to build an "OO Domain Model" where it sees the world in objects.

The simpliest example when u go to a train station , u never see OO chart of trains,the thing u see is a table with coloumns and rows telling u where to go and when to go.

The mind can absorb so much , and the aspect are so unique in business software development.Sometimes it is wise to use OO for UI staff,but not smart to reinvent the RDBMS for the sake of using objects...

I have written my Mappers and used commercial OR/M tools.

They mostly provide the same thing.

__Read the table from the database.
Put that into a some HELPER thing.(DAO,DAL,ORM)
_Put that into your custom business object
__Read from your business object.(if u can :) )

I see NO REASON for this "Unnecessary Pull and Push".

Can anybody explain me why we shouldn't use a typed dataset and go to OR/M?

erdsah88 at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 6

"Aristo did not need any computer code to express himself.U can express your self by code,that is your choice."

Being able to express myself is not enough in this case, I need the machine to be able to manifest my ideas at runtime. This requires a form of communication generally refered to as code. There are, of course, other forms of computer documents which can be processed to produce a running software - but again you would use code to process them...
I've yet to come up with a way the computer can read my mind and use my ideas to produce a running software, have you?

"The simpliest example when u go to a train station , u never see OO chart of trains,the thing u see is a table with coloumns and rows telling u where to go and when to go."

Welcome to the future - columns and rows are dead. Today I want to see a map of the stations, click my destination and receive information (hopefully vocal) on the next train's departure time and fee. I don't have the time to search table rows for information anymore and certainly not to remember identifier numbers as RDBMS's usually use. The fact is you see neither OO charts nor RDBMS tables anywhere because these are software related concepts and not real world concepts. OOP is a design methodology, RDBMS is a software tool (Procedural Programming is a design methodology).

I would use a DataSet (not a typed one) over OR/M. I would use it only when the data needs to be held in memory for some reason, in other cases I would use the RDBMS directly (SQL).

YoniRapoport at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 7

>>I don't have the time to search table rows for information anymore and certainly not to remember identifier numbers as RDBMS's usually use.

UI is not equal to database.Do some analysis no UI is equal to a table...

>>Welcome to the future - columns and rows are dead.

Tables are everywhere in business enviroment.Table is an abstact logic to organize data.

erdsah88 at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 8

I believe that from the day C++ was invented everything is OO in the computing world. What is a DataSet by the way? If you look at it closely, you will see everything OO inside it. It contains Columns, a collection of Column objects, Tables a collection of DataTable objects and so on. They are all object oriented. Correct me if i am wrong?

What would you do if there was nothing like the wonderful DataSet? You will create classes. Wont you? OOP is everywhere. Moreover business is mostly (rather always) communicated in terms of Objects and NOT DataSet or DataTable. You would say Customer, Order (as you stated in one of your earlier posts) and not CustomerDataSet or OrderDataSet.

DataSet is one of the ways to represent the data and NOT to represent the entire business/domain model. DataSet has its own advantages and disadvantages. OO model on the other hand has its own advantages and disadvantages. It merely depends on when to use what. You want to pass data between tiers favor DataSet for its efficient serialization techniques. Objects on the other hand are easy to understand and best when running in-process.

BadriNarayanan at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 9

I agree with the fact that business is based upon objects not rows.

I highly recommend you buy a copy of Domain Driven Design by Eric Evans and read the first few chapters where he covers this very thought. One of the main benefits that he brings up is the creation of an ubiquitous language; a language shared by domain experts and the object model. The value of this is beyond measure. This is not likely to emerge from a table based dataset.

Cheers,

Greg

GregYoung at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 10

also "Can somebody tell me if there is a new requirement won't I change anything in OOP design ? or do I think wrong ? "

I will give an example of the difference ... say I have 227 places in my procedural code with a switch { } as opposed to a factory pattern in an OOP system. Which will be easier to add a new requirement to?

Object orientation does not necesarily give such benefits .. good design does. In fact with the OO system; the factory is most likely dynamically loading objects which means that you could make the extension without changing the original code base [see dependency injection http://www.martinfowler.com/articles/injection.html]

You could create a similar design in procuedural code using a table of function pointers ... of course it is alot easier to do in objects.

GregYoung at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 11

>>>DataSet is one of the ways to represent the data and NOT to represent the entire business/domain model. DataSet has its own advantages and disadvantages. OO model on the other hand has its own advantages and disadvantages.

Agreed! Love to use dataset object, but not custom business entities!!

>>I highly recommend you buy a copy of Domain Driven Design by Eric Evans and read the first few chapters where he covers this very thought.

I did! He also does accept that the RDBMS is a fact of life...(it is real!,not like a fantasy delivery-cargo project)

if u liked eric evans try this links to see that world is not just black and white.

www.essentialstrategies.com/ publications/objects/umleco.htm

www.geocities.com/tablizer/top.htm

>>I will give an example of the difference ... say I have 227 places in my procedural code with a switch { } as opposed to a factory pattern in an OOP system. Which will be easier to add a new requirement to?

Objects are not a GOLDEN HAMMER that can solve business problems in the programming world of the enterprises!
.U got to change as many places as it takes,if your requirement changes.I have do some generic object frameworks for my part.Some of them are really adaptive.(www.adaptiveobjectmodel.com)

But seeing the object orientation as an alternative to RDBMS by creating custom business entities is reinventing the wheel for NO PURPOSE.U should use objects for UI staff and u can use dataset objects.Introducing "custom business entities" to business software is one of the worst things u can do by your self.Arrays are evil!And u are creating them with your hands.

The world organizes data in a tabular way which is called TABLE and that is the reason that excel sells so much.Over beleiving in object paradigm takes us away from the requirements of the project.At the end of the day that is the most important thing.

PS:if u have many problems with procedural codes,u probably missed the anlaysis phase of your project...

erdsah88 at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 12

Perhaps we should just sing an ode to transaction script and call it a day?

GregYoung at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 13

>>>Perhaps we should just sing an ode to transaction script and call it a day?

The enterprise patterns in POEAA are no silver bullet.

U can use transactionscripts in > DTS, business rules +etc

u can use domain model > For some staff like a USER class(logging ,sec).

u can use table module > For business aplication development.

For software engineering we need "mix designs".Doing everything as an object and avoding the existence of RDBMS and procedures are seeing the world as in black and white.

PS: world is a colorful place. :=)

erdsah88 at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

# 14

"U got to change as many places as it takes,if your requirement changes"

This makes maintainance a living hell and is one of the top reasons for projects failing and major rewrites.Requirements change all the time. "Analysis" is done on a daily basis and so are changes. Localizing changes is the main goal of OO (the Once and Only Once principle) just as data normalization is a goal of Tabular Data Driven Designs.
In addition, localized variability provides for better reuse than delocalized variability. Namely, if something appears in code only once, it is more reusable than if it appears twice.

YoniRapoport at 2007-9-12 >

top of Msdn Tech,Architecture,Architecture General...

Architecture Hot Topic

Architecture New Topic

Architecture

Java / MSDN / Linux Tech / PHP Tech / MSDN DotNet / MSDN TECH / Health Library / Programmers Tech / visual basic Tech / Developer Tech / Ipod faqs / Msdn China Tech

Site Classified