Domain Niche Discussion
Domain Niche Discussion(Moved from BenefitsOfOo)
If you don't mind, I'd like to stay away from GUI engine design here and focus on biz domain objects (customers, accounts, invoices, etc.). For one, most custom app developers do not develop GUI widgets from scratch. Second, GUI's are a very long and involved topic. I'd suggest you visit ProgrammingLanguageNeutralGui if you are interested in such. --top
Interesting, so as soon as OOP is mentioned where it might even excel and have merit, you simply back off, move away, and go back to your PetProject?, PetTheory?, and HobbyHorse. Your favorite little niche seems to be very very domain specific and you seem to only see everything through the rose colored glasses of your particular industry related work and your particular domain of work. You reject OOP only because in your particular niche, you don't find it useful. So just because Bob doesn't eat peanuts, this means Bob should reject peanuts as a useful food for humans, since Bob doesn't have any interest in peanuts. You also mention domain objects which is quite interesting - seeing that you call them objects.
The gist of the argument was that "usefulness in GUIs shows that OO is globally good" (paraphrased).
You make things up - this is all in your mind. No one says OO is globally good - stop putting words in people's mouths. One of the person's here defending OOP and the person who started that GUI comment argument (defending OOP) page is a procedural/modular programmer, with a completely unbiased view on OOP. It is important to find examples of where OOP is handy, and not just outright reject it as if you are allergic to it. GUI gadgets were just one fricking example, and no one had got around to more examples - so you simply attack everyone and yell OOP IS NOT GLOBALLY GOOD and no one said that it was GLOBALLY GOOD. You're just a flamer who hates OOP, and you are barely even worth responding to.
Where are your disclaimers that set theory and table oriented design doesn't royally frick up your application in certain cases? How can you build a wood table or a button based on set theory? Where is your warning? Where is your disclaimer? Where is your warning that not all databases have proper fields to support all data (just integers and strings.. but can't store ploygons or squares or customer telephone numbers in a specific format. Where are all your warnings for this? What makes OOP require a big ass warning when relational databases aren't even really relational these days?
Further, I don't agree OOP is better at GUI's. Its just that we already have topics on OOP versus non-OOP with regard to GUI's (NonOopGuiMethodologies, ProgrammingLanguageNeutralGui) and I didn't want to flood this topic with a GUI-specific debate in order to keep it clean. If there is already a topic on GUI's and paradigms, then shouldn't the specific topic trump the more general one? This is perfectly rational and fair in my mind. Thus, I am not being bad. If you disagree with my topic partitioning suggestion, please say so without claiming ill intent. It is possible to convey disagreement over topic partitioning without claiming ill-intent in the other party (AssumeGoodFaith). Further, why are GUI's less of a HobbyHorse than custom biz apps? --top
[Who or what is going to put "big-ass disclaimers" on OOP? And where? Will you require that every OO text or software product box be stamped with "WARNING: The Programmer General has determined that object-oriented programming may cause industrial disease!"?]
At least something like: "Warning: the benefits of OOP are niche-specific and should not be applied in all circumstances." That is not an unrealistic request. Otherwise newbies go hog-wild with some BigIdea, which is a common problem.
[This seems to be a case of PersonalChoiceElevatedToMoralImperative, but even if there are valid, rational, scientific reasons to reject OOP, your alternatively confrontational and overly-casual presentation style,]
I'm sorry, but I don't find my style confrontational. I try hard to practice CriticizeDiplomatically and only vary from it when really angry. If I slip, please point out *specifically* where the slippage is rather than generalities, and I will happily correct it. I do not consciously be bad and mean. On the other hand, your style is clearly confrontational and I can point out the wording if you want. It would be pretty clear that you drew first blood.
[plus a lack of any rigorous support for your arguments, earns your viewpoint no credibility.]
No GoldenHammer proponent on this wiki has ever presented objective rigorous empirical evidence that their GoldenHammer is better. This smells like a double standard. If you chew me out for lack of slam-dunk math-solid rigor, then you must to it equally to all perpetrators, not just those who are skeptical of your pet technologies. Its not my burden to show OO is objectively better anymore. Benefits should be assumed equal or null until shown otherwise.
[In many cases, it seems you don't even understand -- at an elementary level -- concepts like OO, types, functional programming, etc. That's hardly a way to earn support, let alone win a debate. ]
Age-old copout for those who would rather insult than articulate their opinion better. If there were precise algorithms for determining if something was a "type", for example, then you simply reference the line-number in the algorithm or rule number from the list of qualifying rules that shows my statement objectively wrong. But you cannot do this because you mistake fuzzy notions in your head for rigor; projecting personal psychology onto the shape of the universe. If I say something objectively wrong about OOP, then please point out *specifically* what the error is. The topic is OO here, not types. Show you are smarter about these topics instead of merely claiming it by applying logic to specific rules. Everybody on the web thinks they are Einstein.
[However, if your views were presented in a soundly-defended theoretical and empirical context, with strongly-made cases and arguments (in the academic sense, not quibbles), it could be otherwise.]
I cannot do this because software engineering is mostly about psychology. WetWare makes a big difference because software is more for the human mind than for computers because computers don't "care" what language or paradigm we are using, as long as we define it clearly. It is impossible to provide objective evidence of subjective benefits (other than maybe output productivity metrics).
In short, your criticisms of me are as vague as your OO evidence. Fuzzy criticism is usually useless criticism. And you are wondering off topic, bringing past personal battles into this mix, repeating them over and over.
-Top
{Your style is more arrogant and hypocritical than confrontational, which raises a lot of barriers and draws you into one stupid argument after another. You also, regularly, imply that your niche is 'more important' and deserves special consideration more than others, which is insulting and rude and probably even wrong. Let me know when you start putting big "Warning:" disclaimers on all your ideas.}
It's the opposite: OO examples and books over-emphasize systems software, physical modeling, and GUI's. I'm just injecting diversity into the OO discussion. As far as "arrogant", that is often difficult to identify in writing, unlike confrontation, short of outright saying, "I am great". If you give specifics of me sounding arrogant, I'll explore alternative wordings. Past attempts to isolate the areas were very round-a-bout and indirect such that it was clear it was a personal interpretation that could have been ready many different ways. I believe that their personal distaste for me biases how they interpret what I write. Widening the paintbrush of perception is a common human foible.
{Besides, your argument regarding OO seems to be equivalent to me saying: "If I use relational in <this totally unhelpful way>, I don't see how it helps with my domain, so you should put disclaimers on it!" (This also gives rise to those 'JustDontGetIt' claims.) Experienced OO people don't create 'domain' objects. They create objects that represent parts of the computational model. A few objects in the computational model sometimes correspond to domain objects, but only insofar as data is grouped for processing. Only in simulations does the computational model really begin to match the domain model... but most businesses have no use for business simulators, and so shouldn't be creating tons of 'employee' and 'person' objects - not unless these objects serve some other computational purpose, such as temporarily storing query data for complex application-side processing.}
Your view about OO's intersection with biz domain modeling (or lack of it) is not a common one among OO proponents, or at least is far from a universal opinion. But you seem to be agreeing with me on the the "biz gap" of OOP more or less, so where is the disagreement? How often and strongly this gap should be noted in training material? --top
{Most active OO proponents aren't experienced programmers, just like most active Linux promoters aren't long-time Linux users. With experience people mellow out, become less excitable, and tend to have other ways to spend their time than converting people. I've worked with a number of skilled programmers who use OO, I've been informed that I should count myself among them, and it is quite clear: the 'objects' such programmers create are those representing components of the computational model found inside the application - whether these be tasks, job queues, communication pipes, messages, etc. Any modeling performed is in terms of communications between and actions upon these components. Only where the domain is or corresponds directly with the computations (e.g. this is true for simulations, and largely true for GUIs with 'clickable' buttons and such) do the objects match up with 'domain' objects. Most experienced OO developers find this so obvious that they don't even think to teach others about it; I've heard one say in response to this line of discussion: "I thought that was obvious. Don't most OO programmers already know this?". But there is confusion, especially among newbies. A lot of it exists because of the didactic examples used to teach OO seem to be simulation-focused (animal, cat, dog, bird, plane, etc.) rather than focused on more common classes of applications. And I'm sure a lot of the reason the didactic material is simulation-focused is because beginning OO users have a very hard time grasping the idea that a 'ReportBuilder' or a 'CommunicationPipe' or a 'Task' can possibly constitute 'objects'. My own opinion is that all OO training material that teaches OO in terms of ducks, cows, and dogs should be burned, OO should receive a name-change to 'ComputationOriented?' to remove focus on the 'object' which so confuses newbies, and training material should focus on the creation and destruction of computations and computational components (which would include design patterns).}
Well, we agree one some things.
{I'm not sure there is a real "biz gap" for OOP; businesses often create and use applications internally, and businesses are moving ever more towards SOA (though better concurrent and distributed-service support is also needed than most existing OOP languages offer). I sometimes think you have a biased view of what the "biz domain" actually is because you only ever work with a small fraction of it (what isn't biz domain?). It is true that OOP was never designed or intended for reflective DataManipulation which businesses need (ObjectVsModel), so OOP can't be expected to solve every business problem. But it does seem there is a great deal of TemporaryCargoCult when it comes to using OOP among businesses new to it.}
We all only live one life in which to experience as much as possible. I've been involved in a variety of projects and organizations over the years so feel I have a fairly representative view of the variety of custom biz apps out there even if it is not all-encompassing. But nobody's is. As far as what isn't the biz domain, lots of things come to mind like embedded programming, military equipment control, chemical factory control, weather prediction, systems software (OS's, database engines), PhotoShop, etc. (But there are also lots of gray areas.)
EditHint: Consider merging with OopBizDomainGap.
EditText of this page
(last edited November 3, 2014)
or FindPage with title or text search