State and decisions concerning OOP design

#1

Hello everyone. Recently I started working on a project, which can be summarized as follows:

  • there is a cartesian grid;
  • on this grid, there are warehouses;
  • these warehouses contain products;
  • the products are delivered to customers, who are also on the grid, via drones;
  • more stuff that isn’t pertinent here.

and was told, that I can use this resource as the blueprint for a solution:

https://eloquentjavascript.net/07_robot.html

Now, as usual, I have a go at projects without looking at a resource, especially a resource that is supposed to be a comprehensive one, and this time it was no different. I struggled my way through node.js concepts (I had no JS knowledge beforehand), did my usual OOP approach I learned in Python - classes and objects for everyone and everything! Then I got to the core algorithm for the deliveries, and decided to have a gander at the JS book. And lo and behold, there is this section, which took me by surprise (and also took the wind out of my sails completely):

"To be able to simulate this process, we must define a virtual world that can describe it. This model tells us where the robot is and where the parcels are. When the robot has decided to move somewhere, we need to update the model to reflect the new situation.

If you’re thinking in terms of object-oriented programming, your first impulse might be to start defining objects for the various elements in the world: a class for the robot, one for a parcel, maybe one for places. These could then hold properties that describe their current state, such as the pile of parcels at a location, which we could change when updating the world.

This is wrong.

At least, it usually is. The fact that something sounds like an object does not automatically mean that it should be an object in your program. Reflexively writing classes for every concept in your application tends to leave you with a collection of interconnected objects that each have their own internal, changing state. Such programs are often hard to understand and thus easy to break."

Somehow, while I was designing and working at the implementation, I had this feeling that I would have a really hard time making the different parts of it work together.

So I’m here now wondering, how do I learn this state-oriented programming? What am I missing here?

#2

Very good question. Experience, I guess…

Why don’t you write the thing once, using your initial design? Then take a step back, analyse, see what worked and what didn’t, and where it would make sense to not use classes, and why. It’s probably going to be a mess – but it’ll teach you a lot more than simply believing someone who tells you not to use OOP.

One rule of thumb: Classes are a way to closely link state and behavior of objects. If a simple data object doesn’t do much on its own (= no behavior), you might not need to make a class for it (though you might still want to define its shape/type, if your language has a way of doing that – which, in Python, might be to define a class for it…). So, you might ask yourself, what kinds of relationships and interactions between objects are relevant for my application, and how can I capture that in a simple data structure that fits the purpose?

I hope this helps a bit… good luck!

#3

Thanks for the reply. I’ll ramble on a bit…

In this particular case, the solution in the book was both very elegant and educational - it introduces the graph concept, how to build a graph, moving through a graph, etc, but also emphasizes the importance of state, and also retaining old states and calculating new states instead of having a continuum of multiple interconnected behaviours.
So anyway, state is something I’m aware of, but apparently not very good at controlling. I’ve yet to find a dedicated resource with examples where state is at the core of designing a project, and explicitly so. I suppose knowing and using different data structures helps for choosing the right one for the occasion, but ingrained behavior like applying OOP (or whatever it is one is used to) to everything needs to be challenged regularly in order to find a better solution.

1 Like
#4

What’s the goal of the project @OpenPyMind? Initially when I read the brief it sounded like that travelling salesman algorithm but you didn’t express what the goal was to achieve? Presumably something like; get warehouse drone to delivery to customer from nearest warehouse, accounting for stock level?

I’m interested as this is something UPS (I think) tried with interesting outputs.

#5

This was an entry level objective to get into a sort of recruitment bootcamp for an established automatization company. There were all kinds of problems with the whole endeavour, both on my part and from an organizational point of view. The latter is understandable, since it was a pilot project and they need to collect some experience of course. I’m not going to copy-paste the whole thing (not sure I’m allowed anyway), but eventually the app had to be able to visualize drone movements between customers and warehouses, as well as having the ability to accept orders while the app was running. I didn’t qualify, but I decided to continue to see how far I could get on my own. In essence, they were asking of the participants to implement this in 5 days, and if you didn’t have any experience in node.js, well, tough luck. Of course, they never mentioned to start learning node.js, nor any level of required competence prior to the recruiting event.
.

#6

So they were using the recruitment process to get free software. Out of order.

#7

Well, considering the bootcamp is free for the participants I guess it is alright, but in any case I doubt any of us managed to produce anything beyond the rawest of prototypes. In case you’re wondering, the company in question is this one https://www.ocadogroup.com/