Many of these books claim that by creating these abstractions, in this example Person, you can “re-use” them in other projects. However, in 15 years of my professional experience, I have hardly seen many (or any) examples of such abstractions being used across projects in a useful manner.

At one point, I started creating a class library of these abstractions that I could share across projects. After a little while, that class library ended up being bloated with lots of unrelated abstractions and versioning it across different projects ended up being a nightmare. If you have done this before, you may relate to this story.

Once I was engaged as a consultant for a greenfield project, and in the introductory session, the data architect of the project walked me through tons of UML class diagrams (more than 50 pages). Every class was inheriting from another class and eventually, they all led to a class that was called “Thing”! No joke!

What text books tell you about inheritance in OOP is wrong
Mosh Hamedani

There are multiple GUID generation algorithms, but I’ll pick one of them for concreteness, specifically the version described in this Internet draft.

The first 60 bits of the GUID encode a timestamp, the precise format of which is not important.

The next four bits are always 0001, which identify that this GUID was generated by “algorithm 1”. The version field is necessary to ensure that two GUID generation algorithms do not accidentally generate the same GUID. The algorithms are designed so that a particular algorithm doesn’t generate the same GUID twice, but without a version field, there would be no way to ensure that some other algorithm wouldn’t generate the same GUID by some systematic collision.

The next 14 bits are “emergency uniquifier bits”; we’ll look at them later, because they are the ones that fine tune the overall algorithm.

The next two bits are reserved and fixed at 01.

The last 48 bits are the unique address of the computer’s network card. If the computer does not have a network card, set the top bit and use a random number generator for the other 47. No valid network card will have the top bit set in its address, so there is no possibility that a GUID generated from a computer without a network card will accidentally collide with a GUID generated from a computer with a network card.

Once you take it apart, the bits of the GUID break down like this:

• 60 bits of timestamp,
• 48 bits of computer identifier,
• 14 bits of uniquifier, and
• six bits are fixed,

for a total of 128 bits.

The goal of this algorithm is to use the combination of time and location (“space-time coordinates” for the relativity geeks out there) as the uniqueness key. However, timekeeping is not perfect, so there’s a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That’s where the uniquifier comes in. When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the “second time it was five o’clock” don’t collide with those generated “the first time it was five o’clock”.

Raymond Chen, devblogs.microsoft.com

Have you ever…

• Wasted a lot of time coding the wrong algorithm?
• Used a data structure that was much too complicated?
• Tested a program but missed an obvious problem?
• Spent a day looking for a bug you should have found in five minutes?
• Needed to make a program run three times faster and use less memory?
• Struggled to move a program from a workstation to a PC or vice versa?
• Tried to make a modest change in someone else’s program?
• Rewritten a program because you couldn’t understand it?

Was it fun?

These things happen to programmers all the time. But dealing with such problems is often harder than it should be because topics like testing, debugging, portability, performance, design alternatives, and style—the practice of programming—are not usually the focus of computer science or programming courses. Most programmers learn them haphazardly as their experience grows, and a few never learn them at all.

Kernighan, Brian W.. The Practice of Programming

It is hard to talk about a “chair” if nobody agrees on what a chair is. There is enough of a common example base in OO, the shape, animal, and device-driver examples; that one can start, but beyond that the nature of OO diverges from person to person.
I’ll take that challenge. Find a definition of chair. For any said definition of finite length, their is either an exception to the definition or a thing that is a chair that isn’t covered by the definition. And yet, we can still talk about chairs.

[A lot of this is because OO is a broad church embracing everyone from the prototype-based (Self, Io, JavaScript) to the class-based (Java, SmallTalk, etc ) to those who have built OO systems on top of other paradigms (CLOS, OCaml, various Scheme dialects, Python, Perl). Each of these have various flavors of usage as well so talking about OO without qualifying it usually becomes a meaningless debate about whose definition we shall use.

We can only talk about chairs if we first state that we’re only interested in wooden 4-legged chairs.]

I suppose we have beanbag chairs that are borderline “mini-couches”. But, this gets back to the need for a working classification system for OO. I don’t know if “modeling” can be separated from language or not.

Nobody Agrees On What Oo Is