A lot of procedural code is very OOP-like. Basically, instead of object.function(params), you do function(object, params). You can group your files accordingly.

However, what a lot of long-time OOP programmers don’t realize is how limiting it is that a function must belong to one and only one class, and that all such functions must be grouped into one file accordingly. Procedural-style allows for many other kinds of groupings that often fit better under certain circumstances:

• Combinations of two objects, like all functions dealing with both engines and transmissions.
• Collections of objects, like all functions dealing with lists of cars.
• All implementations of an interface. For example, the implementations of steer() for different kinds of vehicles could all be grouped into one file.
• Functions that convert from one kind of data structure to another. For example, functions that take a collection of parts and return a car.

Basically, all those times you couldn’t really figure out which class is the best fit for something, in procedural that’s not really an issue. Don’t get me wrong, the way OOP groups functions is successful because it’s a very reasonable default. That doesn’t make it the best grouping under all circumstances, though.

To be honest, this seems a bit like going backward and programming with one hand behind your back, but if by “structured”, you mean, like how people created programs before Object Orientation in procedural languages, then it’s about how you start thinking about the problem. In your fourth paragraph, you are essentially still thinking in an Object Oriented way. The way people wrote in languages like C, Pascal and BASIC back in the day was to start with the code not the data. An analogy would be that a computer program was like a recipe; a series of steps to follow.

So you wouldn’t say “Let’s say you wanted a struct to represent a Car”. You’d say “I want to transport myself to the grocery store”. You’d only start thinking about objects like “Car” when you got to the step that required it.

To use a more concrete example: Suppose you wanted to send a bunch of letters to addresses in a file. Thinking in OO, you’d probably first start thinking about things like address objects. But with old structured languages, you’d probably first think about the steps:

1. Open file
2. Read a address
3. Format address information
4. Print address
5. Go to 2

You’d devolve each of those into steps, like

4:

1. Print name
2. Print house number
3. Print street
4. Print city
5. Print state
6. Print zip code

To make all this easier, you’d almost certainly put the address data into some sort of struct to keep it together, but that would be driven by the steps you were taking. You wouldn’t start with that.

The thing is: this gets really hard to manage once you get to programs of any significant size. This is why nearly everyone thinks in objects these days unless they are writing a quick little script.

Start from data structures.

Write functions operating on those data structures.

If you want encapsulation, do it at the level of modules, not objects.

If you want polymorphism, use higher-order functions, not virtual dispatch.

That’s about it. OOP as practiced is not a significant departure from procedural programming. It’s primarily a set of reasonable defaults for constructing procedural programs.

The way we used to do sort-of OOP back in the days of C was by declaring a struct and then declaring functions that accept such a struct as their first parameter. Then sometimes the need for polymorphism would kick in, so we would have our struct contain not only data fields, but also pointers to functions. It is quite pointless, really, doing by hand what C++ would do for us with far fewer lines of code, more safely, more elegantly, and in a way that everyone who knows C++ understands, instead of each shop rolling their own.

If you really want to abandon OOP in favour of structured programming, you have to move away from objects, and start thinking in terms of modules, but you will soon see that you will naturally and inevitably gravitate towards OOP, and there is nothing wrong with that, because OOP is a very convenient way of thinking about programming, and I would even dare say a necessity in order to build complex systems.

Before C++ we used to write modules which exposed functions, and quite often these modules were managers which contained some plurality of entities, so they would expose some sort of ‘handle’ to let you indicate which entity you were referring to, as for example the case is with operating system “file handles” of old, which you may have heard of. That was already OOP, even though it was not called by that name yet. In the beginning the handle usually was an int and it was used by the module as an index into some internal array of structs, but at some point someone figured that since the user code is not supposed to try and interpret the handle in any way, the handle could just as easily be an actual pointer to the internal struct; nobody would notice, and nobody should mind.

So, in order to do anything a) useful and b) large-scale you have to think OOP, but if you don’t use an OOP language then your implementation will be behind some monolithic flat interface, and you will still have to do an awful lot of mindless manual work in order to achieve certain things like inheritance and polymorphism, (which you will need if you try to do anything of non-trivial complexity,) and which will be provided for you if you use an OOP language.

The bottom line is my brain has been wired to think about Objects, Encapsulation, Polymorphism, etc.. and I cant seem to wrap my head around anything else. How can I practice?

The biggest – if not the only – difference between procedural programming and object-oriented programming is the notion of inheritance.¹ For instance, it is straightforward to implement a polymorphic list type in C, but translating inheritance relations would involve a lot of work. As long as no inheritance relations are involved, writing

Car myCar;
myCar.start();

in C++ is just a fancy way to write

Car myCar = car_construct();
car_start(myCar);

in C. So in procedural programming, you solve problems by defining data structures and treatments on these data structures, and this works pretty similarly as in OO-languages, except that you cannot use inheritance-based abstractions.²

If you want to progress in procedural programming, I would suggest studying programs written by others and writing similar programs yourselves. You will learn a lot by comparing your solution to the other and asking yourself how important the differences are. Reading and writing shell scripts is probably a good step
to learn procedural programming, because this is a competence which is also useful on its own. You typically find a lot of scripts bundled with your operating system – and can find good quality scripts randomly on the internet.

It is also worth to note that one of the few³ widespread, of significant complexity and virtually bug-free program ever was written in a procedural language. The program I think of is TeX which was written in a Pascal-like language, and the code source is described extensively in a book TeX: the program which you could consider reading. It is easy to legally find or produce electronic copies of the book, and the nearest scientific campus will have a hardcopy in its library.

¹ Which you do not mention on your question!
² Inheritance is great to solve software engineering problems but it does not solve any practical problem. So in view of the problem solved by the software, inheritance solves meta problems.
³ I actually do not know another one!

The way I see it, to go from proper object-oriented programming to a procedural style, you need to:

• remove behavior from your objects; make them just containers of data (data structures)

• implement behavior in separate classes (services); they will take the data structures as arguments and perform some action according to application use cases

• use the same criteria of design quality you would use in OOP (cohesion, coupling, etc), only apply them to services

As others pointed out, this is probably a regression from OOP, especially for large projects. Could be a valid approach for simple scenarios.

What is this object representing? What can this object do? What do others need to be able to do to it? What do I expose, what do I hide? Etc

When you create a struct, the only thing you need to answer is what its data structure should be. It can’t do anything, it can’t hide anything, all it is is a convenient method of accessing plain memory. It may be a good idea to try to answer some more questions about the struct, but there is no formal grammar for writing the answer to those questions. (That is also true for a lot of good questions about OO objects.)

but where do functions go that should operate on a car type?

Wherever you think it fits best, the struct does not make a decision for you, it doesn’t even dictate that the relevant code should be a dedicated function. Decide on an implementation when you actually have to use it.

IS the idea of a member function totally thrown out the window?

It doesn’t have to be, the function(object, parameters) structure is equivalent to the basic use of member functions. It should compile to pretty much the same thing.

Encapsulation

A bit simplified, all encapsulation ever does is throw an error message if you try to break it. Sure it can be nice to have some formal guarantees about what code can’t do, but you mostly get the same benefits by defining non-compiler-checked boundaries. In any case, the only encapsulation method that you actually lose is private members and methods. In my experience, those are not nearly as important as variable scopes.

Polymorphism

The big case for OO. Solves a lot of weird problems, and doesn’t have any simple replacement. But there are lots of structures that do similar things, here is a few:

• Make a struct with space for all the data needed by any desired subtype, have a variable mark what subtype it is. You can use multiple such marks in order to make something that resembles multi inheritance. Rather than overloading methods, the code that deals with such structs must simply check the type and act accordingly. It may waste some memory, but in most cases that is probably not a big deal. If you have a lot of different subtypes it could however spread the code defining the differences between those subtypes all over your program.

• Include function pointers as member variables, these can be set to the functions matching the subtype.

• Include pointers to sub-structs, with memory for this specific subtype.

• Make all the desired subtypes distinct struct, and copy-paste any code that apply to all. Doesn’t sound good, but if the differences take up a lot more code than the similarities, it could be a reasonable choice. The don’t-do-this-at-home version is where you construct the memory layout so that the same code will work on different structs.

For learning purposes I think it is a wonderful idea to shelf an advanced feature, especially if it is one you tend to overuse. In real-world code, you should of course use the OO features where it makes sense.

I’d recommend reading some of the structured programming “classics”: books by Ed Yourdon, Larry Constantine, especially a lot of Dave Parnas’ stuff. They talk a lot about top-down design, using structure charts and data-flow diagrams, breaking code into modules and how to handle coupling and cohesion. It’s interesting reading, and some of the tools (e.g., data flow diagrams) can still be used today. I sometimes feel that a structured approach is a better fit to some problems (those involving parsing or state machines, usually), but that’s not a popular opinion.