I’ll be the first to say that this question is a bit… out there. But here are a couple questions I bear in mind :
Is abstraction continuous or discrete?
Is there a single unit of abstraction?
But I’m not sure those questions are truly answerable or even really makes sence. My naive answer would be something along the lines of abitrarily discrete but not necescarily having a single unit measure. Here’s what I mean…
Take a Black Labrador; an abstraction that could be made is that a Black Lab is a type of animal.
[Animal]<--[Black Lab]
A Black Lab is also a type of Dog.
[Dog]<--[Black Lab]
One way to establish a degree of abstraction is by comparing the two the abstractions. We could say that [Animal] is more abstract than [Dog] in respect to a Black Lab. It just so happens [Animal] can also be used as an abstraction of [Dog] So, we might end up with something like
[Animal]<--[Dog]<--[Black Lab]
With the model above, one might be inclined to say that there’s two hops of abstraction to get from [Black Lab] to [Animal]. But you can’t exactly tell somebody they need one level abstraction and reasonalby expect they will come up with [Dog] given they aren’t explicity given the options above.
If I needed to tell someobody in a single email that they needed an abstract class with out knowing what that abstract class is, is there a way to communaticate a degree of abstraction such that they might end up on Dog instead of Animal? As a side note, what area of study might this type of analysis fall under?
1
Is abstraction continuous or discrete?
Is there a single unit of abstraction?
I look at abstraction as a discrete thing, measured in “layers” that can only be counted based on your current point of view.
For the sake of example, let’s say an Animal is at the top of a class hierarchy.
If I call some method that expects an Animal, you’re looking down at the top and have absolutely no clue if what you’ve been handed is actually a Dog or an Aardvark. You shouldn’t care, either, because those details are hidden behind the abstraction. That barrier prevents you from measuring any deeper than Animal. The abstraction does allow you to know that every Animal has a sleep() method but not that it’s implemented as layDown(); closeEyes() (Aardvark) or turnAround(3); layDown(); closeEyes() (Dog). As long as the end result is a sleeping Animal, that shouldn’t be an impediment.
If I call a method expecting a BlackLab, you’re in a different position. By virtue of the fact that you know this class inherits Dog and Animal, you can measure that there are two layers of abstraction above you, but you’re still blind to anything below such as subclasses MaleBlackLab and FemaleBlackLab.
If I needed to tell someobody in a single email that they needed an
abstract class with out knowing what that abstract class is, is there
a way to communaticate a degree of abstraction such that they might
end up on Dog instead of Animal?
No, because your scenario is dropping not-so-subtle hints that implementation has started without having completed a design which would tell you how the class hierarchy will look
Without that context, the directions you’d give (“write a BlackLab class with two layers of abstraction above it”) would be ambiguous. The first several implementation possibilities that come to mind are these:
Animal/Dog/BlackLabDog/HuntingDog/BlackLabHuntingDog/Retriever/BlackLabCanine/Dog/BlackLabDog/BlackDog/BlackLab
Without an understanding of what kind of software you’re writing, any of those might be appropriate. Once you start to zero in on solving a specific problem, only one becomes the right thing:
- If your project is for the local animal shelter, which deals with many kinds of animals (dogs, cats, etc.), the first hierarchy makes a lot of sense.
- For the American Kennel Club (dogs only), it the second one might work better.
- For the North American Gun Dog Association (hunting dogs only), the third works.
You get the picture. Context is king.
As a side note, what area of study might this type of analysis fall under?
This is really basic software engineering, specifically the chapter on fully understanding the problem before you start work on it. 🙂