Do you recommend procedural methodology software developement for small database application in dot net?

Question

Hello

As a new entry to the software development industry I tried to develop my programming skill using different ways. One way I found out is as many suggests by reading code from other authors.

When I begin to develop, I want to use objected oriented design paradigm for any application. As a start I begin with small database programming project such as hotel management, payroll, sales application…etc. However, in my course when I searched in internet for source codes, I find out many programmers develop their source code in internet in procedural way for these type of small application. Although they use vb dot net or C# (objected oriented languages), they try to follow procedural such as they defining all global methods and variable in a one class then they call access the method from a particular form for a particular action.

E.g. for library management application the design may look like this

   //one global class for whole method and variable definition
Class globals {
//define  public variable and public function such as
//connection to db code
Public  void storebooks() 
{//code for storing books to db
}
Public  void  storeusers
{ //code for storing users to db
}
.
.
//code for searching books  …etc
}

Then a form uses a particular global method and variable for its operation just like module declaration in vb6.

My question is when I try to do the application I try to do using oop methodology by defining class object, attributes …etc. So am I on the right direction? Should I develop these type of application using objected oriented methodology (although small) or I should stick to the above type code I found on the web (procedural way)?

Please explain me in detail when to use oop methodology and when to use procedural if applicable in that respect. My intention is also to develop my software development skill as a graduate

Thanks

Answer 1

Although the debate "OOP vs procedural programming" is still alive, I doubt that for such small project a real methodology analysis is taken.

Many programmers that do simple ERP projects have a procedural background (Visual Basic <= 6, or even COBOL) and don't really understand the Object Oriented model. Therefore they use OO languages as some kind of "component oriented" system (i.e. they use prebuilt objects just for the GUI and not for the program logic).

The result is that these small softwares are a nightmare to maintain. However they would be a nightmare even with OOP correctly applied, because usually this programs don't have a design, lacks formal specification, have crazy schedules ans so on. So the programmer falls in the "code first, think later" methodology.

Answer 2

There is in fact nothing wrong with procedural development. You can write nice and maintainable applications with it. However what you often see is applying procedural practices to an OO language.

A cause can be that the programmer just comes from non-OO language like C and try to adapt his knowledge to a new language. It can also be that the application is so simple that the procedural approach fits best.

A valid approach in my opinion would be to determine what kind of application you want to create. If you know that you can choose a desired platform and language. But this is not always possible as the platform and language are already defined (by management or so).

To write a pure OO application is not so easy as it seems. Especially find out your model of the domain (on which you base your application design) can be difficult. But once you have this model in my experience it is fairly easy to create an OO application, small or big. Of course it is very important to know all the flows (use cases, processes/procedures(!)) to be able to define the relations in your model.

The big pitfall for OO is over design. Hundreds of classes with inheritance and stuff like that. Doing that you will end up with bloated applications for functionality that does not deserve this.

To make this long story short: make for yourself clear the nature of OO and the nature of other paradigms and consider what is best for the application you want to build. As a practice you can also create an application both OO and procedural and see what you can learn from this.

Speaking of myself I almost always use OO for applications in C# (or Java), also simple ones. The depth of the model varies also depending of complexity and maintainability. Usually I prototype with several options and after that decide about my final design (advice: always draw/design your models!). Still I don't believe the OO paradigm fits all.

Answer 3

A great resource for looking at procedural development evolving into object-oriented design is a book called "Refactoring in Visual Basic" by Wrox Publishing.

It goes through examples where you might quickly code procedural solutions to small, manageable problems only to have your customer ask for revisions and increasingly complex improvements, which in turn would benefit from the more autonomous nature of object-oriented development.

While this book isn't necessarily an overview of various development strategies and implementations, it does an excellent job of contrasting different techniques through the iterative process of refactoring.