How to successfully progress from procedural to OOP style?

Question

In the past I had some trouble to grasp why we even need classes and don't just write functions.

In the meantime I learned to see how it makes sense to protect certain data and tie related functionality to it; I also learned how to write classes (in my case in Python).

But when I want to apply it, I often get the feeling that something's not quite right:

Either my classes do too much and suck up the functionality and data of the whole application, effectively making the class 'wrapping' effectless.

Or they do too little so that they look like functions in a pretty dress, useless again.

How can I, step by step, understand better how to write *meaningful* classes, how to model their relationships to other classes, free functions or free data, how to make it all interact properly and, well, reasonably?

Answer 1

That's all opinion, but I roughly have 3 types of classes I write:

- "Just Data" classes (or "beans" in Java-speak), which consist only of properties and a bare minimum of methods. They are pure and possibly immutable. In some languages they may not even be classes at all (c.f. ADTs).

- "Library-style" classes, that solve a specific task and are very general, in that you could just take them and pop them into another project. (Reusability!)

- A minimum amount of classes that do the actual business logic and tie it all together. They should read like a recipe and rely on the library-classes to do the heavy lifting.

(And a class called Utility where all the stuff goes that I can't fit anywhere, but don't tell anyone.)

For example I wrote parts of a jpeg parser, which involves snooping around in an array of binary data. Some classes include:
- Bean: JpegTag, a class that contains a single piece of jpeg info
- Library: ArrayReader, which is the array and a pointer that knows how to move left/right etc. It knows nothing about jpeg.
- Tying it up: Another class used those 2 to solve the actual problem of parsing jpeg.

At the end of the day, you should probably practice writing large-ish projects and you will get a feel for which abstractions are necessary so you don't go insane because the complexity is all over the place. Overgeneralizing is also bad.

PS: Inheritance is taught everywhere but it's often too rigid. I think practice has shown that interfaces/mixins are a better fit for most (but not all) problems.

PPS: Forcing everything into OOP patterns is not a good idea either. I had to unlearn a lot of bad OOP habits I picked up. "Execution in the kingdom of nouns" is a fun read if you're into that kind of stuff!

</walloftext>

Answer 2

Great topic. I know how you feel.

My teacher said:

OOP we need to spent more time to plan your code.

Procedural you can make it more fast.

About Maintenance, OOP is better than procedural because It is clean, like human language.

OOP is better when you need to associate a database.

Answer 3

Great topic, horrible medium to properly cover thoroughly.

There is so much I want to say, but it will take much time to breakdown - especially typing on a phone.

I almost wish this could be done via a live round table discussion.

This leap from procedural to anything more abstract is a critical step in your growth as a software developer that takes time and practice, and for many, the proper guidance from an experienced mentor over a period of time.

Answer 4

peter, in a way, it helped me to understand the beauty of OOP when I mixed some C into my studies:

Doing it raw, you constantly have to worry about overflow, missing the target while indexing, handling functions with mile-long parameter lists, stack and heap stuff...

Suddenly you look at Python's ints that don't overflow, lists you never can miss, pointers that never dangle because you never handle them yourself and all of that with different eyes.

Unfortunately it's one thing to enjoy well-designed abstraction, and another thing to design it yourself.

Answer 5

lol@physchology the head of the clinical dept tried to test me like Sheldon so i played along i did have serious injuries. he goes we would like you to write the biggest number you can using 5 digits, my mind was already going this loony wants me to write 99999 so i shall play him at his own game. you go first mr prof of medicince lol so he did start to write and he got four 9s down before i laughed. he looked confused as i said you have already lost. told him turn the paper. all he saw was FFFFF and then got asked ever heard of hex? at no time did he say it was base 10 or not fluid. he entered my comfort zone lol

Answer 6

Check out my code the Pokemon battle stadium it uses OOP

Answer 7

Thanks peter and Schindlabua for the reply. I’ve never used flow charts either but many of the ‘learn to code’ books I’ve read in the past encouraged it. Always thought I must be doing it all wrong. Never thought of writing programs to generate flow charts based on my code though😂.

Answer 8

ever looked at Delphi? if anyone does these days a good lesson is looking behind it where it churns out the pascal. one year in college i’m making the hangman game in Pascal, the following year the course thows Delphi in and i’m redoing the same game in mins using the classes and functions i had spent ages doing the year before. watching the interaction between them comparing it to just how productive RAD and OOP were was an eye opener. OOPs classes and off the shelf packages saves us time trying to reinvent the wheel as the wheel works fine lol

Answer 9

HonFu hmmm hard to say. I've written single 150-line functions before but I've also crammed 10 classes into the same space.

Theres this psychology factoid that the average person can hold 7 (+/- 2) things in memory at a time, Miller's law or something. For programming that probably roughly translates to variables or functions in scope, so if your programs have a lot of moving parts, encapsulation starts to make sense.

Just push yourself out of your comfort zone I guess :P

In functional programming you hear about the "expression problem" a lot which talks about which kinds of problems functional code or OOP code can do well but I'll not go into it to save space :)

Answer 10

The way I understand it, OOP is mostly relevant for largish programs/projects, often but not necessarily, maintained by multiple programmers over a relatively long period of time like a banking application. It's also relevant for programs with a fair amount of complexity, be it written by a single person or a team, like a video game. Often when there are entities or actors which act upon or get acted upon by other entities, it makes sense to encapsulate the actions/functions as well properties of these entities into classes. In other cases, the use of OOP will be too much bloat.

Answer 11

Jordan Monk iirc, in "The mythical man-month" Brooks even jokes that when project management forced programmers to flowchart each function, they would write programs that generate flowcharts from code.

I never plan with flowcharts and diagrams because code reads like a flowchart anyway, and I usually just keep a big todo list that gets constantly updated. But also my largest work-related project involved 3 people so I would't know better.
I'd imagine if you work with dedicated architect or analyst people and have to orchestrate 20 nerds in a meeting it's more common.

Completely planning out a project is also impossible, because project requirements usually change during development ("BDUF" has gotten a bad rep, "agile" is all the rage now)

Answer 12

HonFu Very very roughly speaking, the expression problem says that in functional programming, adding a new operation on a datatype is easy (you add a new function), but modifying your datatypes is hard (you have to touch all functions that use it). In OOP it's the other way around, you can for example tack on a new subclass to accomodate new data, but to add more functionality you have to touch all the subclasses.

Now there are ways around it (OOP can model higher order functions with things like Java Runnables, functional code can model classes as F-Coalgebras) but I'm going on tangents of tangents of tangents so I'll really stop now :D

Answer 13

Schindlabua thank you for your own real life experience with its mixed-in honesty about not always finding the perfect pattern.

About the 'large-ish projects': Is it possible to stick a number on that (arbitrary as it may be), like at which lines-of-code mark OOP's advantages will make themselves heard loud and clearly?

Answer 14

Schindlabua, 'kingdom of nouns'... that was a nice read, summing up many of my doubts about OOP.

That fits my thinking a lot better: Let things be things and action be actions!

'The expression problem' needs more experience on my side; I'll probably just have to - as you suggested - write more and bigger code until I get a feeling for when what is better.

Answer 15

Sorry, AZTECCO, I thought my question made clear that I'm not completely new to writing classes at all... did I sound too naive? :(

I can design a single class and decide what's private and what should be touched; I think I could also decide what and how to inherit in most cases.

But how to cook up a whole program with a structure of classes, functions and free data that actually makes sense - that's the hard part (for me (right now)).

Answer 16

I really enjoyed reading over the thread. Thanks everyone for all the excellent input (tips/tricks/experience). Great topic HonFu .
I’ve always found it helpful to view my classes as physical objects like parts of a machine. Designing each one to accomplish its specific task. I’m not employed as a programmer but I work in the HVAC industry. Programming is a hobby I’ve enjoyed for decades.
Question for those of you who are employed as programmers: Does anyone consistently plan out a new project on paper/whiteboard using flow charts and such?

Answer 17

lol think we call that things like feasibility study and structured english then its the flow charts and critical paths in project management, i just ignored all that i belonged in the rear with the gear either coding it or fix it til it breaks testing ideology lol

Answer 18

peter, you bully! 😂

Answer 19

brainstorming face to face sessions were always very productive and eye opening. back to hangman the game as my class were busy coding it in pascal, we were gradually being exposed to Delphi both the Turbo and procedural without at first being aware. most folks were talking about arrays file writing the course content getting applied really. i was away in a world of my own thoughts partially taking part as the lecturer took notes from class members on the plan. all that kept ringing in my head was the same lecturer when he taught Delphi used to always go on about not having to know whats inside a magic box just what its methods handle and he had a thing for the term paramater passing. by the time he got to me, asking what way i was thinking of approaching it i was inside pascals help files scrolling away as i just mumbled about am looking into Sets. will never forget the little smirk type of smile he gave me as he just left me alone, nor did i miss the light switching on in the eyes of others. that was all delphi’s doing really and the lecturer, never learned more off anyone else and IBM came and head hunted him so we lost they gained. the collaboration approaches in his brain storming sessions yeilded great results esp in team building in later projects. geek.get.together.com we have the ideas someone just needs to get us together more lol

Answer 20

Pedro H.J, have you read the article Schindlabua talked about above? About the 'kingdom of nowns'? ^^

It's interesting: The author talks lengthily about how in (from my perspective) radical OOP langs like Java, nouns suppress verbs to a degree that it's actually very far from natural language.

Teachers of good writing style in natural languages tend to stress the importance of verbs very much.

I always thought that this, too, can be driven too far, since sometimes things are really things and not actions.

That's why my sentence above:

Let things be things and actions be actions!

Multi paradigm languages like C++ or Python let us have both: We don't need to compress the life out of an action until it is a thing - we can use free functions in combination with classes.