Oop Team Size

Re: OOP seems to support a larger team of developers at one time as it (the application/system being developed) can be partitioned into distinct parts/modules/etc. easier. (from WhyOopIsBetter)

I've been hearing this claim more often lately. This suggests that procedural/relational projects cannot be partitioned into parts, which is flat false. In fact, I believe p/r partitions better because you don't have to deal with a BigSoupOfClasses. A good p/r system is like villages that live off of the Nile, where each village is a small application or task, and the Nile is the database. One mostly only has to know the schema(s) to contribute to the larger "system". In practice, there are some shared utilities, frameworks, or "helpers" (HelpersInsteadOfWrappers). These can be useful for common tasks, but are not necessary. In fact, the nile approach makes it easier to split a system into multiple languages. The database is the interface to the system, so anything that can query the database can be part of it. OOP might be better at building big apps, but p/r is better at avoiding big apps to begin with.

-- top

Top, your argument is interesting because I would use it to support my statement. With OOP, messaging becomes paramount and the villages only need to worry about the messages being sent and received. The BigSoupOfClasses is only big for the architect; the developers only deal with the ones in their village. [ScottNeumann]

Reread and noticed that Top had the database as the Nile. I think that might be where we diverge. I would actually propose that the business process is the river on which the villages rest. Also, I am leery of having intimate knowledge of the database schema be a requirement to work on the system/application. Experience has shown me that it is easier to understand a class representing the 'real' world 'object' than, for instance, a self-referencing lookup table holding related key/name pairs/hierarchies. [sn]
May I request clarification and/or examples of "self-referencing"? If the structure is messy under relational, it will probably be messy as an OOP structure also. Or, is this another navigational-vs-relational preference issue? Relational does not dictate presentation. If there is a nicer way to represent it, such as an outline tree or plot of links, then generally some kind of presentation tool or transformational query is used to make it presentable for a given need.
My approach is to embrace the database and make it *part* of the application, not a distant service. Otherwise, you end up reinventing and mirroring many features that databases offer, making more work, more code, and inconsistent conventions. And, OO offers no real way to manage links between bunches and bunches of objects/classes. It dumps a BigBallOfLinks on one's lap. -- top
Treating databases as services doesn't lead to reinventing or mirroring database features. I treat the print server as a service, and I don't reinvent the print server in my OO code. -- EricHodges
You OO'ers just ain't giddit: a DB is bajillion times more powerful, versatile, and useful than a piddly print server. If you're going to wrap something away, then wrap OO away. You didn't address the link issue. DBs are better at managing links and attributes than OO. Even if OO was better at behavior, as some claim, that does not make up for the other two liabilities. Note that we got off topics of team size, and back into a HolyWar. -- top
So because a database is more "powerful" than a print server, then treating it as a service will force me to reinvent it in my code? Does that make sense to you? -- EH
It is a bad analogy. For one, printing is only output. A better analogy would be treating every variable like a remote service. It is possible, but a pain in the keister. Tables are fundamental tools. The more you red-tape them, the more combersome they are to use. -- top
So you're dropping your first two arguments? -- EH
Which arguments are are you referring to? Perhaps we need to label or number the arguments.
The arguments you typed on this page. "Don't treat the database as a service, otherwise you will reinvent it" and "A database is more 'powerful' than a print server, so treating it as a service will force you to reinvent it". -- EH
I don't want to get into a LaynesLaw mess over "remote service". Suffice to say, the printer analogy is "bad". The OO urge to view everything non-OO as a swappable device driver can lead to beurocratic code. -- top
There's no LaynesLaw mess here. There's nothing about a "swappable device driver", either. Treating a database like a service is a software development best practice. It doesn't lead one to reinvent or mirror the database in code. -- EH
There are no "best practices", only fads. Anyhow, it is time to compare a specific example. -- top
No, there really are best practices. An example can't verify your claim that treating a database as a service leads to reinventing it. -- EH
You didn't read the whole thing. You took the words you wanted to and made your own wrong paraphrase. If you don't make a database "part of the application", then you would have to reinvent those aspects you leave out, such as concurrency management, cross-referencing, and general collection-orientation features. -- top
But I treat the database as a service and I don't have to reinvent those things. I use the database for them when appropriate. -- EH
Two questions: first, do you feel that treating it as a service adds to "bloat" in any way? Second, other than vendor swappability issues (we already have topics to debate that), what advantage does treating it as a service get you?

Self-Referencing, Lookup Table -

I brought up this only as example to support that sometimes having something interpret the data is good. It was a schema I inherited (<-- emphasis added). And, it was a confusing schema as, in some ways, the metadata was embedded into the data; the schema itself didn't impart any knowledge of the 'business' entities stored within it. See SelfReferencingLookupTable for further discussion on the actual table.

By creating the facade/wrapper class, the other developers were able to move forward with the other parts of the application as they could stub out the functionality of what I was developing. The 'complexities' of the schema were removed from consideration; they were able to focus on business logic and presentation. It worked well for us. [sn]

Without knowing what the schema is for, it is hard to comment on the value of its design or how to fix or wrap it (with OO and/or procedural). If you really need an interface or wrapper to help other developers, a procedural function wrapper could work just as well as an OO one (or perhaps views or stored-procedures). See HelpersInsteadOfWrappers. I've never claimed that direct SQL/queries is always the best way to go. -- top