Page 1 of 1

The Object Oriented Design Process

#1 Martyn.Rae  Icon User is offline

  • The programming dinosaur
  • member icon

Reputation: 545
  • View blog
  • Posts: 1,420
  • Joined: 22-August 09

Posted 19 July 2017 - 10:45 AM

Introduction

On the 18th June 2017, garbus posted an item in the C++ programming section voicing their concerns regarding the object oriented design process here. That got me to thinking about knocking together this tutorial. Having started software development around the same time that Kernigan and Richie's C programming language and the C++ programming language were in their absolute infancy; watching the latter gradually overtake the former in terms of popularity, I am in a fortunate situation in being able to discuss this subject with some authority.

Procedural versus Object-Oriented

Even before C++ began to take grip on the programming community, it was recognised that grouping procedures that processed individual or similar entities into either subroutine libraries or their own source files was a positive move. So, for example number conversion routines would form either a subroutine library or be placed into a source file rather than be randomly sprinkled around a number of source files. This helped us isolate and find specific areas of code rather than raking through (often hundreds of thousands of code lines), looking for a routine that provided this or that number conversion. Sometimes such routines would start with the same prefix e.g. customer_..., so developers maintaining the code could have a pretty good clue as to what a routine did without actually looking for the code itself. Structures in C that carried data would normally be labelled customer_name, customer_address etc, so again maintenance was simplified as a field in a structure called customer_details that was labelled customer_name would be extremely clear as to what was going on! As you can see, there is not a great difference between the following code written in C:-

typedef struct customer {
    char * customer_name;
    char * customer_address;
    ...
} CUSTOMER;

char * customer_get_name(CUSTOMER * details) {
    return details->customer_name;
}



and the C++ code:-

class CUSTOMER {
   private:
       char * customer_name;
       char * customer_address;
   public:
       char * get_name() {
           return customer_name;
       }
}



This then, in simple terms, was a formalism taking procedural development mechanisms and using the language constructs to express the data and the routines (method) that worked on said data into a common place known as a class. That alone, was an excellent reason for moving from C to C++, and as you have guessed, is the main reason as to why object oriented programming languages are more prevalent today than procedural languages.

Designing an Object-Oriented system

OK, let's consider a concrete example of designing an object-oriented system. Let's design a public library system and identify potential objects (classes). Obviously, we would start with a top level object we shall call libraries. This will be a container object that contains a 'list' of individual library buildings. A library building will have a location and various other details such as staff etc. Let's not worry about such details here, and concentrate on what a library contains. Well it will certainly contain shelves, and each shelf will contain one or more rows of books. There is in actual fact, no difference at present between how a procedural developer and an object-oriented developer would tackle the design. Next we have to consider the person borrowing the book. This means we will have a container object called customers containing a list of individuals that have a valid library card. We now have the ability to tie an individual book to not only a shelf within a specific library, but also it's state e.g. on the shelf or borrowed by an individual customer. We could go on and on developing this overall design, identifying objects without having much idea about the data that needs to be held by individual object classes, or specific methods that an object class has. This is what I would call a top-level design and must occur using procedural design as well as object-oriented design methodologies!

The Difficult Dilemma That Object-Oriented Design Faces

At this point, the object-oriented designed and the procedural designer will part ways. The procedural designer, would concern themselves with the data, the flow of data, the controls, the states and the transitions that exist between the identified building blocks.

The object-oriented designer will continue to look for objects within the overall design that are not necessarily there. When do you stop trying to identify objects in a design?

I have seen the most deplorable systems where even the parameters that are passed between one object class and another object class are in themselves encapsulated into objects converting an elegant top-level design that is easy to understand into a spider's web of objects that confuse everybody including the designer.

Conclusions

This may be a controversial statement, but there is NO difference between procedural design and object-oriented design! You have to be fully aware of the key players (libraries, shelves, books and borrowers in our example above), their associativity, along with the data and control flow before you stand a chance of identifying data items and methods that process the information. Without this understanding, you don't stand a chance of producing a decent design that can be implemented as coherent code.

In other words, forget the whole procedural versus object-oriented approach to the design of a system! Concentrate on the building blocks, that seem to fit together to produce the whole. Take those building blocks, the data they operate on and the flow of said data between the identified building blocks then start looking at how those building blocks can be implemented using an object-oriented approach of classes, data and methods.

Is This A Good Question/Topic? 0
  • +

Replies To: The Object Oriented Design Process

#2 jon.kiparsky  Icon User is online

  • Screw Trump (before he screws you)
  • member icon


Reputation: 10622
  • View blog
  • Posts: 18,178
  • Joined: 19-March 11

Posted 19 July 2017 - 01:03 PM

Quote

This may be a controversial statement, but there is NO difference between procedural design and object-oriented design!


I don't know if "controversial" is the term I'd use, but that statement is not one that I would subscribe to.

I would agree that object-oriented design in a basically procedural language like C++ or Java has a lot in common with procedural design. "Object-oriented" is not an antonym of "procedural", it's just a design pattern. Using the OO pattern, we choose to encapsulate data in particular ways (which are usually only minimally binding - the encapsulation is more or less formal, depending on the language) and to associate that data with functions that work on it. These functions, in a basically procedural language, are procedural functions, but that's just a happens-to-be-true-here fact, not a necessary fact about the OO pattern. If you were to build OO patterns into a language that was basically functional, its methods would be basically functional (see for example the various object-oriented descendants of ML, OCAML and Scala and so forth)
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1