This lesson was translated automatically – it may contain errors.
Before taking on the main part of the course, it is worth working out where we are standing. Three things: who an engineer is and what goals they set themselves, what a program is and what problem it solves, and why abstraction is the key skill in this profession. The definition of an object is built out of those three.
Who an engineer is
The word «engineer» comes from the Latin ingenium – «inventiveness», «wit».
An engineer is not someone who knows the formulas but someone who solves a practical problem under constraints. A bridge has a budget, deadlines, materials and a load it is obliged to carry.
An engineer’s task is not «build a bridge» but «connect the two banks» – and a bridge is only one of the options. Hence the work they actually do:
- understand the real problem – what is expected of the structure and how you will know it works;
- choose among possible solutions – a bridge, a tunnel or a ferry, each with its own price and its own consequences;
- fit within the constraints – budget, deadlines, materials, people; there is no perfect solution, there is one suited to these conditions;
- leave room to grow – the load will increase, the river will rise, the requirements will change;
- answer for the result – a bridge stands for decades, and somebody else will be repairing it.
None of those points is about knowing formulas. Formulas are a tool; an engineer’s work is to make a decision and justify it.
What a program is
A program is a formalised description of a solution, written down so that an executor – the computer – can carry it out.
For Ada Lovelace the executor was Babbage’s machine and the problem was mathematical. Our executor is the same one, but the problems come from the business, and the constraints are familiar from bridges: time, money and people.
Hence the main idea: a programmer is an engineer, and code is an engineering structure. A bridge is built once and maintained for decades. Code is the same: writing it is about 20% of the work, the other 80% is reading, changing and extending it. And it is people who read it, not the computer.
Remember that proportion: it explains nearly everything that follows in this course.
Abstraction
Abstraction is the deliberate discarding of inessential details in order to work with the essential ones. You use it every day: a metro map shows neither real distances, nor the curves of the tunnels, nor the depth of the stations – only lines and interchanges. That is exactly why it is useful: for the task «get from A to B» everything else is noise.
The catch is that abstraction can be done badly. A metro map drawn to real distances would be more accurate – and less useful. Code is the same: a poor abstraction either hides what matters or exposes what should have been hidden.
A good abstraction answers a single question: which details are essential for this task? Being able to answer it is the key skill of a designer, and no paradigm will answer it for you.
The definition of an object
Now the main term of the course can be defined.
An object is an abstraction of a part of the problem domain that unites state (data) and behaviour (operations on that data) into a single whole.
An order in an online shop «knows» its items and its total – and «can» pay for or cancel itself. Why uniting data and behaviour turned out to be such a powerful idea is the subject of the next module.
Why this matters in the age of AI
A neural network will write a class faster than you can finish reading this paragraph. But code is the lowest level of abstraction: above it are classes and their area of responsibility, modules, boundaries, services. The higher the level, the less the question is «how do I write this» and the more it is «what should be here at all, and why». That part stays with the engineer, and the price of a mistake there is different: a class is fixed in an hour, the boundaries of a system cost months of engineering time and hundreds of thousands of dollars to the business.
AI is an amplifier in all this: in a codebase with sound abstractions it speeds the work up several times over; in a swamp of bad ones it produces new swamp just as fast.
Learning this straight away on architecture is far too expensive – which is why classes and objects are the practice ground. The task on them is exactly the same: decide what is essential and what to hide. The only difference is the price of a mistake – an hour instead of months, and you see it right away.
You will be surprised how much of what we work through here carries over to other levels: what you learn on classes shows up in how modules, services and even teams are arranged. Understanding «purely OOP» abstractions makes you a stronger engineer – even if you never write a line of object-oriented code at work.