Oo Is Not Anthropomorphic
Oo Is Not AnthropomorphicIn contrast to the view that OoIsAnthropomorphic.
ObjectOrientation as a technique is centered around inheritance and subtyping as a particularly efficient way to organize your program. It's all about organizing the many sorted algebra in a very efficient way (as UncleBob says, to manage code dependencies).
In layman's words a many sorted algebra is a collection of data types (aka sorts) and a collection of functions defined over them. Just what you have in any program or in any software systems. Where functional programming and object oriented programming differ in their approach is in the way they go about organizing these algebras (the totality of data types and functions in each program) into manageable parts.
ObjectOrientation is centered around subtyping and inheritance as the major mechanism to factor out complexity and redundancies among data types and functions, FunctionalProgramming takes more advantage of parametric polymorphism, and algebraic data types. Hybrids are possible, as for example in ObjectiveCaml, that supports both styles. There's nothing magic and anthropomorphic about either.
The inheritance and sub-typing centric way of organizing code is questioned by many OO and non-OO practicioners, I would note. See LimitsOfHierarchies and ThereAreNoTypes. Basically, the criticism is that the real world does not change in a tree-wise or subtype-wise fashion, and that these are artificial or local viewpoints of something.
The criticims is totally misguided, as well as exaggerated (the many OO and non-OO actually means TopMind and a handful of others maybe ?).
"Types" scored rather low on the OoBestFeaturePoll. Fans of dynamically typed OO languages, such as Python or SmallTalk, often do not subscribe to a strict subtype view, but rather concern themselves with wether an object answers a "message(s)" or not, not its place in a predetermined static taxonomy.
SmallTalk and Python do have single inheritance as far as the implementation of types is concerned. Since the many sorted algebra is entirely in one's head and hidden to the compiler when programming in dynamic languages, there is a perfectly valid subtyping relation in Python and Smalltalk (again, outside of the languages). "Objects that respond to the set of messages (m1, m2,... mk)" is a supertype of "Objects that respond to messages (m1, ... mk, mk+1, mk+p)". That's a perfectly valid subtyping relation, again it is hidden to the compiler, but is there conceptually, and programmers are aware of it.
The fact that you cannot introduce the perfect order on types, is in no way an argument not to introduce any order. Some orders are just good enough to have positive effects. For what cannot be encoded as polymorphic types we always have the good old if then else and all OO languages are turing complete.
Better yet, PutClassificationsIntoMetaData so that you can create virtual views without altering your code.
That's a dubious approach. Metadata is just another notation, just like the notation in the programming language. It provides mostly marginal benefits, while making it harder to reason on the properties of the whole program. It is useful in very limited situations, but the bulk of program properties are better put in code in a programming language.
MetaData can be dynamically or virtually manipulated in ways that is harder for code. Code generally does not allow "multi-indexing", hard-wiring in a single perspective. Hardwiring a viewpoint is an antipattern in my book. See CodeAvoidance for more. I supppose this is off-topic anyhow. I suggest you start a page OoIsAboutSubTypes? or something. Perhaps some people "think in code". I can't speak for all, but I grok tables better than code usually. Using your "Objects that respond to the set of messages (m1, m2,... mk)" example, suppose we wanted to query to see which classes/objects/modules/things responded to such messages. Querying meta-data in a database-like way is easier than doing such in code.
This claim is as bunk as saying that mathematics is hard wired to make 1+1=2. You cannot change the perspective on natural numbers. Some things are hard wired to have a very precise meaning. Not everything is parameterized in terms of everything else.
The problem with metadata is that while flexible, it has two consequences: a) it provides an extra level of indirection
Only if your starting point is outside of the metadata.
and b) it makes reasoning about program properties harder or impossible. If tables were as good as you claim, we'd put all the code in tables and substitute text editors with table editors.
I would like that to an extent. See FileSystemAlternatives. I suppose you could argue that such is a minority opinion and that LeftHandersTooCostly, but please don't extrapolate your own preferences to everybody else. The schools mostly teach a code-centric viewpoint. If they taught more meta concepts, then perhaps more developers would look to them. LispWeanie?s are quite adept at blurring the distinction between code and data.
Code or table, it is irrelevant, they are both the same mathematical concept: formal languages. If you express the same function: f x = if (x % 2= 0) then x/2 else x+1 in code or in tables, you get the same thing, the same result. In code you get a concise notation that is easy to reason about, in a table structure you get a mambo jumbo nobody will be able to figure out.
They each have their specialty. TheRightToolForTheJob. I never proposed putting everything in tables, just a lot more than current "best practices" proposes.
Even program to manipulate code structures are easier to write against trees, not tables, as LispMacros do. Programs that manipulate code structures in tables are a joke.
I have used tables to parse stuff multiple times before. Lookup of symbols is well-suited for such. It makes it far easier to study and dump the internal results. Performance is the biggest problem, not developer interfacing. I think the above is a case of LookingNearLampInsteadOfWhereLost. Trees are indeed simpler, but are messy in representing anything beyond the trivial. Forcing things into trees that are not really trees in reality is often worse than using a more flexible and more disciplined structure, such as a table(s). See also: LimitsOfHierarchies.
Sounds like a violation of OnceAndOnlyOnce. Related: AdvantagesOfExposingRunTimeEngine. As far as performance, this topic is about the human side of things, not the machine side. Besides, this sounds like it is turning into yet another "structure fight" HolyWar rather than addressing anthro stuff. This whole section may be misplaced topic-wise.
{OnceAndOnlyOnce also applies only to "the human side of things, not the machine side". It wouldn't be at all unreasonable to expect a development environment to load message names into a database so you can search for them there, and such would not be a violation of OnceAndOnlyOnce.}
I agree that OO is not anthropomorphic. I think objects are easier to anthropomorph than most common programming abstractions, though. It's easier to anthropomorph an object than a procedure because an object has its own data. It "knows" things. It's easier to anthropomorph an object than a record because an object has its own behavior. It can "do" things. Objects respond to messages. One object can "ask" another object to perform a task or "tell" it something. All of this tempts us to treat objects as people (usually very dumb people), especially during design when their behavior and knowledge is unrestrained. -- EricHodges
This answer seems to contradict itself. I request clarification.
[EditHint: Seeing people on both OoIsNotAnthropomorphic and OoIsAnthropomorphic saying 'yes it is' 'no it isn't', perhaps someone with more ability could create an OopAndAnthropomorphism? page?]
So a statement contradicts itself because both cannot be true? Take the following and apply ItDepends:
Statements have dependencies and do not stand in isolation from them (including this one).
Related:
-- DonaldNoyes.20111011 EditText of this page
(last edited October 12, 2011)
or FindPage with title or text search