Oo Lacks Consistency Discussion
Oo Lacks Consistency DiscussionSummary of Claims
Definitions Inconsistent or Vague
Discussion about claims that OOP lacks consistency in definition and/or modeling techniques.
Hm. The way this discussion is going, it should be renamed to OoDesignLacksConsistencyDiscussion?. ChrisDate was criticizing mostly OO concepts and terminology (like that there is no consistent definition of what is a class and what is a type or whether objects are values of variables). When he discussed design (like the CircleAndEllipseProblem) it was only to show that OO foundations are weak.
Is there really a consensus difference? If the foundations are weak, how can the rest be strong? I suppose you could argue that OO can still be a UsefulLie without good foundations, but there are other useful-lies that do have decent foundations/constistency. In other words, there is not even enough consistency to safely separate "OO" from "OO design". Perhaps we need to compare a "brand" of OOP to relational so that we are clear what we are comparing.
Big Picture (macro-level-organization)
From ArgumentsAgainstOop:
Re: Every OO modeler ends up modeling their own head, so you have to learn a new head from scratch each time you encounter a new OO application.
Can you give an example? What program is not a reflection of what is in the programmer's head? Are you saying each problem has a platonic solution and some approaches allow you to get closer to that ideal regardless of the programmer?
I don't see much consistency to OO designs. Procedural generally will group and divide code by tasks, and leave other kinds of information to data handling systems. The separation of data things and task things creates a cross-developer consistency in most cases. And, on the data side there are things like relational rules and schema normalization rules that serve as a guide. However, I see nothing comparable in OO that is consistent cross-developer. Their model appears to reflect how they view the world. Perhaps it is something else besides their head model, but they have yet to identify it. Thus, if it is not their head model, I apologize, but still don't know what it is. Generally there will be at least one class per domain noun (entity), but beyond that it is all over the place.
Interesting, as an OO programmer, I see lot's of consistency between OO programs. Have you considered that you just don't understand OO well enough to see the patterns? Most OO programs are chocked full of standard patterns that make it quite easy to identify the big picture.
Do you mean like GOF DesignPatterns? If not, then what are the patterns or design rules? Note that common patterns and consistency are not necessarily the same thing. If a person used pattern X for A but another person uses pattern X for B but not A, then that is still a lack of consistency.
You seem to have a completely different idea of what consistency is than most programmers do. Listen, in any paradigm, if you give 10 programmers the same assignment, you'll get 10 different versions of the code. That's just as true for procedural as it is for OO. Procedural has standard idioms, and so does OO and functional. As long as others within the paradigm can understand and read the code, this isn't usually a problem. You aren't arguing about consistency, you're just trying to compare OO to relational and say OO lacks math. That's been done, move on.
Consistency is continuous. It was never suggested that two different developers would produce identical code. And, the "lacks math" discussion has been deleted by unknown individuals. This topic is a more general variation of that. Consider this. A typical procedural shop has this "design pattern":
[Many OO shops have the exact same basic plan, if they use a database.]
What makes it OO then? Because the "modules" are called "classes"?
[What makes it OO is that the programmers use object oriented programming techniques (encapsulation, polymorphism, inheritance, etc.) to accomplish their tasks.]
This appears to contradict your above statement. Specifics would be welcome. If you are using polymorphism, then most likely noun taxonomies are in the code, not the data. Where the taxonomy is "stored" is one of those wishy-washy issues in OO. If you use encapsulation, then you are not likely grouping by "task", but rather by noun.
[Noun taxonomies are wherever they need to be. There are multiple noun taxonomies, some from the problem (entity, company, client, distributor, etc.) and others from the solution (servlet, HTTP servlet, list, ordered list, etc.). The tasks are assigned to programmers ("Write the bit that handles security", "Write the bit that prints reports"). They may span classes just as they may span procedures, structures or tables.]
You seem to be confusing grouping programmer work by task and grouping code by task.
[In the examples I gave they are the same. "the bit that handles security" is a code task, and a programmer is assigned the task of writing it. You seem to be confusing the noun taxonomies of the product (house, room, living room, bathroom) with the noun taxonomies of the tools (spanner, straight spanner, straight C spanner, offset spanner, offset C spanner).]
But in some OO designs "the bit that handles security" may be spread to each class. Each class might end up handling its own security. You know, "responsibility-driven design" and all.
[Then refactor it to a common class. It doesn't matter. It's still a code task and a programmer task.]
Can be grouped by task and is grouped by task are different things. I don't dispute that some parts of OO designs are task-ish. But probably less than 50% in most cases. Thus, what is the other 50% and what consistent rules determine what they are rather than A, B and C be nouns in one OOP'ers design but tasks in another?
[Everything the computer does is a task. I don't understand what you see in OO designs that aren't tasks.]
So are you saying that procedural and OO are no different beyond minor syntax? If they are different, then what is that difference? You seem to be implying that "task" is the wrong word to describe the difference.
Re: Divide up code by tasks.
So all procedural programmers would decide to use the same tasks? They would use the same data structures? They would provide the same functions around the data structures? They would use the same call graph? The would use the same schema? They would use the same stored procedures, keys, indexes? They would use the same file names and directory structure? I guess we've worked on different code bases, because I can't imagine this being remotely true. If are considering tasks then I would expect the entry points to those tasks to look equally obvious. Below that, then, all bets are off.
This was covered above.
Not really. It sounds more like the usual whatever I understand is the best.
This is covered below.
A typical procedural shop has this "design pattern":
No. The second says nothing about what the code "looks like", how it is grouped, what principles its data organization follows, etc.
Neither does the first.
The first answers at least these:
A consultant can walk into most OO shops and know that the program units are usually divided up by related behavior
"Related" is usually multi-dimensional. There are multiple orthogonal ways to group code/software and we cannot group it all by these variables so must pick one. See GroupRelatedInformation.
and that non-trivial behavior will be grouped in packages and if there is a decent programmer, the code will be normalized more or less by established OO principles.
Which are? Each OO proponent seems to have one, but other OO proponents often don't agree. We have social models (responsibility), physical models (self-handling nouns), and weird mixes in OO design.
With procedural there are no consistent normalization rules.
Normalization of what? Normalization in DB's is mostly just practical OnceAndOnlyOnce, and RelationalAlgebra is better InterfaceFactoring of DatabaseVerbs. If you see duplication in procedural that OO can fix, what is it? Case statements? That is covered under SwitchStatementsSmell. (The bottom of ArgumentsAgainstOop also has a similar "duplication problems" list. Perhaps that list should be moved here, or perhaps create a new topic: OoDuplicationProblems??)
Just a bunch of brittle coupled procedures. One cannot say that the majority of the code will be normalized in any reusable runtime swappable way whatsoever.
Example? And, you seem to be implying that OO automatically guides one to write reusable code. In other words, bad OO is allegedly better than bad procedural and/or OOP coding allegedly automatically prevents bad coding.
I realize that some OO proponents claim that use of polymorphism instead of decision statements automatically makes code more reusable or more change-friendly. Is this what you had in mind? I disagree, as described under SwitchStatementsSmell. However, this topic is about consistency, not about being change-friendly or reuse. They may or may not be orthogonal issues.
Re: "There are no large-scale principles."
The large scale pattern is to let the database be the large-scale pattern. Each task is relatively independent and usually not more than say 500 to 1000 lines of code. DivideAndConquer. Use the principles of EventDrivenProgramming. (Batch tasks are generally longer than interactive tasks.)
Perhaps if one knows that a given shop uses any kind sensible pattern, you may have a chance. But, otherwise it is a shanty-town of code to the consultant. I am saying that procedures and RDBMS are rarely clean and well-factored, but even the newbie and hit-and-run designs tend to fuck up similar patterns of code organization and data and duplicate everything hundreds of times. The code is still divided by task, but it's mostly loosely organized crap. Fortunately, OO evolved to fix these problems.
Example? I agree that there are a lot of places where bad programmers duplicate code. But dupers can ruin ANY paradigm. Comparing bad procedural to bad OO won't get us anywhere. But even with poorly-factored procedural, you still get mostly smallish tasks that communicate mostly via the database. That aspect does not change much. You just lack good shared libraries.
All you are saying is "We write a bunch of code that operates on data in a database." If you're a DB consultant, this is probably a good thing.
Assume an application consultant.
Maybe this topic can somehow be merged with BigSoupOfClasses.
How about BigSoupOfTasks??
At least you know you are dealing with units divided up mostly by tasks. That is better than just units of who-knows-what. A big pile of nails is easier to deal with than a big pile of miscellaneous things like paper clips, screws, bolts, etc.
It's always a big pile of something. There aren't any shortcuts to understanding - you have to be able to read the code.
I am not saying that there are not ways to better organize/catalog the code. I am only saying that a p/r solution is more likely to start out with or share a common organization pattern: grouping by tasks, compared with OO. "It has classes" does not tell you anything about what the classes represent. There are more potential likely variations.
No it's not. Procedural solutions make sense to a procedural programmer, OO solutions make sense to an OO programmer, just because you don't grasp OO doesn't mean anything, it's your failing.
If you know the common guiding large-scale rules of OO designs, please list them. I did for p/r shops above and in ProceduralMethodologies. Can you provide the same, or not? If not, then why not? If that knowledge is locked inside your head, it won't do any good for anyone. Your viewpoint in this is then nothing more than ArgumentFromAuthority. Your position appears to be, "Yes, most OO does have a guiding large-scale organization principle, but I cannot or will not give it here because [???]".
You listed the most general obvious rules possible. They in no way would help anyone create a program.
The important thing is understanding a newly encountered program, not so much creating it, although that is part of it. Perhaps you are suggesting that some or most of p/r design is so "natural" and/or fundamental that it does not warrant mention? (See section below about step-wise refinement.) If OO has nothing comparable, this would appear to back the title's claim. Note that lacking consistency does not necessarily doom OO by itself, but making up for the lack in other ways is for other topics (if so claimed).
They've been explained to you over a 1000 times in the last several years Top, you just don't get it. And you've provided nothing by the way, you say group by task, I say group by behavior, neither help you write code.
The explanations given so far appear to be internal to OO proponent's heads, and inconsistent between OO proponents. I cannot translate it into anything meaningful or substantial. It is vague or elusive. ProgrammingIsInTheMind. Also, explaining benefits and explaining consistency are two possibly different things. As far as writing code, yes, it does help. Most experienced coders don't even have to think about task-divisions because it is common in schools or those starting out. However, being ingrained does not make it non-useful. Knowing that the code grouping is dominated by "tasks" helps reign in the possible variations. Less surprises and side entrances. You know you are looking at tasks and only tasks for the majority of the code.
Normalized tables are about as far away from tasks as one can get.
That is part 2. I was talking mostly about the code-side. But the "far away as you can get" is part of the relatively clean SeparationOfConcerns and DivideAndConquer that tasks+DB gives you. I can't consistently find something similar in OO. It is all intertangled and nobody here seems able to provide guidelines for figuring it out, let alone showing that the divisions are fairly consistent.
It is claimed by some besides me that StepwiseRefinement is easy and natural for most people, and perhaps fairly consistent. I agree that it was taken too far in the late 70's, but anything can be taken too far.
It is my contention that most people would produce roughly similar refinements, and thus the consistency of task-based code division. The consistency does tend to break down at the larger level, especially for interactive apps, but this is where databases and EventDrivenProgramming frameworks help.
Maybe we should approach this a different way. Going back to the "walk-in consultant" scenario, what physical and mental steps would one take in an OO shop to start to grok the software?
I've been following these discussions for their entertainment value, but it gets pretty sad after awhile.
Using a database directly from procedural code can be a lot like having "a big pile of writable global variables". If you don't know why "a big pile of writable global variables" is a bad thing, you aren't going to understand why classes are a good thing.
I guess I don't get your version of OO then. However, the key here is "your version". Many OO proponents will disagree with your assessment of databases being like a bunch of global variables. (Moved rest of "global" discussion to bottom of GateKeeper. DatabaseNotMoreGlobalThanClasses may also be related.)
...
Use the appropriate tool for the job: not every tool or methodology works well for every problem. However, if the problem is small and simple enough, almost any tool can be made to work.
Not every programmer thinks the same way: background and experience, and literal brain structure, affect what tools a programmer will choose, and which tools a programmer is likely to be able to use well.
There is a large class of business applications that can be built solely with database tools (I've written my share of Access hacks). These kinds of applications are usually not very interesting, and not very big. The problem with these tools is, as soon as you need to do something outside the scope of the tool, you're screwed - you can't get there from here.
Some people grasp OO methods quickly, some just think "why bother?". It can take a certain kind of experience to really understand the _motivation_ behind OO approaches. If you have worked on a large program, you probably have run into the kinds of problems that OO tries to solve. If you haven't, you may still wonder what all the fuss is about.
Depends how you define "large application". The very way one measures system size seems to be yet another twisty mental-view trap. See SystemSizeMetrics and OopTeamSize.
I define "large application" as something in excess of about 300,000 non-blank lines of code. How do you define it?
The "something" is indicative of the problem. Do you count every line of code in the company? If not, what is the smaller unit you are using? I find "application" not a very useful nor stable division of software in many cases, as described in SystemSizeMetrics. I have worked in companies where one would be hard-pressed to cleanly identify "application" boundaries. Web and pre-client/server systems seem more this way than client/server-era arrangements, perhaps because of issues of storing and distributing EXE's in c/s tend to force one to draw boundaries.
I agree it is tricky, largely because each company has a different "culture" with regard to the way they divide and manage software and/or organize people and departments (WaterbedTheory). Thus, we should probably focus on specific scenarios and explore the possible permutations of those.
But for the most part, custom biz applications tend to match the grouping of people in the organization. The payroll department has a payroll application, the benefits department has a benefits application, sales has a sales and leads tracking app, etc. This is perhaps somewhat arbitrary, just like organization divisions, but humans often need to divide things up in order to better manage and track them. It is a UsefulLie. The app partitioning/dividing might as well match this since it needs dividing for similar reasons.
--top
From: ObjectOrientationIsDead:
Because most of us OO guys think that T+DB (tasks and database) are riddled with obvious flaws, that's why we chose OO, to escape them. As far as we're concerned, a database is a big global variable, and comes with all the problems of global data. It also has no decent way of encapsulating varying behavior dynamically. OO fixes these problems for us.
Well, since this topic is consistency, let's move the drawback issues to FundamentalFlawsInProceduralDesigns. Alleged benefits in other areas aside, do you agree that OO lacks consistency in comparison?
Also, I would like clarity on what is meant by "encapsulating varying behavior dynamically". Is it perhaps related to DeltaIsolation?
If you subtract from RDB that columns must be basic types, OO and RDB work well together. What is a basic type anyway? Computers only handle bytes, not bits. Numbers, strings, etc. are not built-in types for the computer, they are abstractions built on top of bytes. ADT (AbstracDataTypes?) are similar, the only difference being that they are created in software instead of on hardware.
It depends on your flavor/definition of OO. OOP can be made to closely mirror relational, but that is not the way it is often done in practice, and thus the inconsistency light. Further, there is still the open issue of whether to use RelationalAlgebra for DatabaseVerbs or OO methods. (Attempts to do both have been ugly, as described in ExpressionApiComplaints.)
Relationships Between Classes
In OO there are no consistent rules for managing the relationships between classes. Thus, the designs tend to be inconsistent from developer to developer. If there were a clear benefit to abandoning consistency, then it might be worth it to toss it, but I see none. Further, relational consistency allows one to more easily query structures to search and view them from different angles. Some of you don't seem to value that, but I find it very useful for myself.
Some will argue that the pattern movement introduces consistency into OO, but I find many of the "patterns" either reinventions of ER thinking, or just plain messy, such as Visitor. Some will say that OO patterns at least better integrate behavior and data, but in practice that is not true because most biz data is still in RDBMS. Until that changes (common OODBMS), the smooth integration will not exist in practice. Few OO proponents see O-R mappers as an ideal situation. -- top
(Some of this may repeat existing statements. I will refactor it later.)
ChrisDate explicitly states in his books that any comments he makes regarding OO are only to be considered in the context of writing custom business software for dealing with persistent data--the natural domain of relational databases. Date makes no claims about OO vs databases for any other programming domain.
Do you have a page number, by chance?
See also: ProceduralMethodologies, ExtremeNormalFormCommentary, ArgumentsAgainstOop
EditText of this page
(last edited November 21, 2014)
or FindPage with title or text search