Now you're not worried about encapsulation -- you're worried about the very concept of AOP. AOP allows you to insert new behavior almost _anywhere_, not only into new parent classes. You could use an aspect to insert the new behavior directly into the original parent without ever creating the inserted parent!
The trick is that this is very well defined behavior. Worrying about it is very much like refusing to use subroutines because some programmer might change one of them while you weren't looking -- better to keep all your code in one function so that you can SEE the changes people might make!
If I wrote a function that didn't do bounds checking on a passed-by-reference array before it returned it, and it overran array bounds, there's no possible work around possible. It WILL bomb.
Okay, if that's the case, then there's no problem -- nothing to fear. Aspects won't change any "impossible" into a "possible".
Quite seriously, though, of COURSE it's possible to workaround almost any single bug. Programmers do it ALL the time -- usually one of the ways to find a bug is to first find a workaround, and only by carefully examining the workaround does the true cause become evident and fixable. Lazy programmers often just implement the workaround without bothering to fix the bug. Like I was saying, that sort of laziness is just as possible with AspectJ as it was with Java or C. No change.
And the preprocessor analogy isn't quite apropos, because with preprocessor directives you see something in the code that tells you something is happening at that point. It sounds like with aspects you don't get any corresponding cue in the code.
Not at all. Aspects can use more _subtle_ cues, yes; such as assignments to variables of a certain type, or calls to methods whose names match a regex; but the cues are all contained in the text. The analogy is very precise: AspectJ is a very powerful, semantically safe preprocessor for Java.
Perl does automagically fix stuff - overrun an array bounds?
Actually, that IS new since I learned the language; I can't say whether or not I like it, but I'm a bit suspicious.
Let me say, however, that what he did isn't illegal; anyone can declare a derived class, and a derived class has every right to access a protected variable. That fits the API of the original class perfectly well. And the subclass getting the new parent really had the right to access the private variable all along, so it's not doing anything wrong either.
No, this makes perfect sense. It fits with object orientation and aspect orientation, even if it seems a little roundabout at first. The object should be able to access the protected variable, but the aspect shouldn't be allowed to. Thus you introduce an object which can legitimately access it, and use it to build an API for the aspect to use.
And if it is a team of programmers and someone wrote an aspect to "silently fix and keep running" these types of problems, then I may be in a world of hurt later on. And finding a bug that was thus hidden would be a nightmare.
No doubt if you were on the same team and someone wrote a function to work around a bug (rather than finding it and fixing it) you'd be in a world of hurt, too. It's possible, but it's no more possible now than it was before.
I mean, if I really want my program to handle "errors" in an "intuitive manner" and keep going, I'd write in Perl. (N.B. I *LIKE* Perl, but only for certain types of things).
You're confusing "aspects" with "magic". They don't fix errors for you. They don't "silently fix and keep running," any more than a text editor silently fixes your code and keeps it running, or the C preprocessor silently fixes C code and keeps it running. They only do what you code them to do.
In fact, the comparison to the C preprocessor is a very good one. The C preprocessor (cpp) searches through text for simple text patterns and replaces them; AspectJ searches through your program's parse tree for simple semantic patterns and augments them.
Actually, AspectJ strictly observes encapsulation, so you're okay. (Or at least it did when I learned it -- there was some debate even at the time, since it's obvious that being able to pointcut on private variables is useful.)
I'm definitely on the side of forbidding breaking of encapsulation. There's too much coupling otherwise.
The relational model offers logical advantages that cannot be found in ANY other system. If any other system achieved those advantages, it would become de facto relational. End of story.
Definitely. But the advantages that are exclusive to the relational model are in the realm of generality and ad-hoc querying, not in ease of use or anything else.
Look for the whole logical-physical confusion thing;-).
Yes, a relational database with a good optimiser could do a lot, given a known query pattern. Guess what: a human can do more given a known "query pattern". And since there are no relational DBMSes, the human's so far ahead of the pack it's silly.
Yes, it has many languages, but if you try to access your Java Prevayler application data from PHP or Perl, you are going to have to re-implement all your integrity constraints in those languages. That's my point. No longer will you have a single point of control for your business rules, or the logical model of your data.
Look again -- if you didn't implement the Command dispatcher, you didn't even come CLOSE to implementing Object Prevalence. There can be only one command dispatcher; in the long run it's responsible for all integrity constraints. All languages have to go through it.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there). Huh? This is the most obvious one of all. With SQL, my VB, Java and Perl application could all interact with the same DBMS without needing to talk to each other. Thats a perfect solution in the real world.
In other words, if you adopt a single common language and include that language in everything you write --- yes, of course.
(I think I made a typo in my parenthesis about SQL. I can't tell what I originally meant, but I'm guessing it's the opposite of what I said -- SQL, like ANY common interface, naturally helps different languages work together.)
But SQL is ____far____ from "the perfect solution for the real world." Maybe you live in a far happier world than I, but embedding SQL code in C is a royal pain in the butt; maintaining it is _terrible_. It creates horrid coupling, and isn't easily debuggable, especially since the compiler can't check your work.
But that's my whole point. Separation of operations. Your data should have a single point of control for the logical constraints in the data, and that point of control should be a logical firewall between the data, and everything else that happens in the application.
SQL seems to place the dividing wall in the wrong place. It takes a LOT of effort and careful design to avoid sprinkling literal SQL code throughout C. Object Prevalance isn't a holy grail either, but it places the same dividing wall in a different place, and seems to work a _whole_ lot better for cohesion and coupling.
Also, in the end there is also nothing that an OO DBMS can do that a truly relational DBMS can't.
It sounds to me like the main selling points of AOP are that you don't have to design things well in the first place, because if you missed something, well then you can change how your objects behave without redesigning them.
No; of course, that won't work. Bad design can't be simply patched over; you'd have to edit the original source.
However, it _does_ mean that you don't have to write your function to include everything that your function has to do. You can code the function in a simplistic way, ignoring boundary cases, odd memory management quirks, and esoteric optimizations: just make the code say what it does. Then write an aspect to be the optimization, and another to handle memory management in that and similar code, and another to handle the boundary cases, and so on.
You're 100% right on both caveats (although the first one only applies when you're 'cheating' by trying to dispatch multiple read commands at the same time, so isn't really a weakness of the solution itself); and either one in the wrong circumstances can indicate that object prevalence isn't the right solution for you.
Agreed entirely. Now I'm going back to my cubicle to write some more ODBC; when I finish, I'm going home to finish converting the savefile system for the game I maintain to use object prevalence. Enough of hearing about crashes but not being able to reproduce them... This time if it's my fault, it should happen every time, AND be possible to back out of.
Excellent summary -- I see the problem. The other articles on the subject are written in a much more usable manner. Let me cover the ACID test, though.
1. Atomicity is implemented at the method-call level; there's no notion of a transaction (even a read transaction) that can be open while others are open too. The exception to that, of course, is if you write methods that read values from the business objects WITHOUT using doing it inside a Serializable subclass, in which case you've lost your atomicity anyway.
Commands are atomic (note the technical term "command"). It's possible to get around this; multiple read commands can be permitted at the same time, and don't even have to be journalled, but that's an optimization that's explored elsewhere in the OP literature (and has obvious shortcomings in that you give up Isolation).
2. It appears that there is no declarative data consistency checking; that's left up to the individual programmer accessing the Java objects directly.
Yes, because OP isn't declarative. A system can be added to any language you desire to give you preconditions, postconditions, and invariants; this is an old problem.
3. It appears that there is no transaction isolation; any code can read from the business objects directly.
Not really. Commands provide isolation; you're not supposed to access business objects outside of the context of a command.
4. There is a journaling mechanism that does provide durability.
Right.
Seriously, I agree with you on C; otherwise, prevalence seems to handle AID, and consistency can be handled with differing ease depending on your design.
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem. Really? Sub-selects are atomic at the object model level? Come again?
I don't understand how you managed to read into my message the exact opposite of what I was saying. NO, sub-selects are not atomic at the object model level. NO, NO, no. That's the problem; that's why relational databases have to include the concept of transactions, to group primitive queries together into a single imitated atom. Meanwhile, the prevalent system doesn't support that type of grouping, and doesn't need it because its commands are all already atomic.
So some new Object database tarted up with fancy-schmancy new terminology suddenly makes transactions easy?
No -- it tries to do without them instead. This is classical engineering -- don't try to add more features to solve a perplexing problem; instead, try a new solution.
Multiple updates to an object graph from multiple threads in a transactional manner become, somehow, easier? _rolls eyes_ Riiiiiiiight...
Nope; this method does NOT work with simultaneous updates (whether they're done in a "transactional manner" or not). If you need them, this is NOT for you. On the other hand, if your database can fit the requirements of this, it's possible that you won't need true simultaneous updates; if an update takes a millisecond instead of a second, it's likely that your second update can just wait.
Oh wait, daily hot backups kinda suck to be around for.
I hope you're not seriously complaining about them -- they're lifesavers. If you're trying to sarcasticly imply that object prevalence doesn't handle those things, or makes them harder to manage, all I can say is that you have no idea what object prevalence is. An Oracle-trained DBA wouldn't know how to set up a hot backup for one of these systems; but let the programmers show him around the system for a short while, and he'll be up to speed (although he won't be using any of his Oracle training, so you'd be better off hiring someone else).
And chucking stored procs for intensive operations kinda sucks.
I've worked with stored procs, but I've never done anything with them that I'd call "chucking". Is that some terminology I'm just unfamiliar with?
Unless you mean "I don't want to stop writing stored procedures." In which case -- well, I don't know why you're complaining. Object prevalence really is one huge stored procedure.
Well, you'll forgive me if I'm not impressed. Get all users?
Not impressive code. I agree. But keep in mind that all the user records are in memory -- getting a list of them, or a reference to the master index of them, isn't a challenge. Asking the master index to look up a user based on his login isn't a challenge either -- perhaps that's done via hash table, perhaps via ternary search tree.
And what about in big ol' databases, when not everything can live in memory?
Great question -- according to the authors, you don't use object prevalence for those. It gives no advantages in those cases, and huge disadvantages. Simple question, simple answer.
The problem is, of course, that sometime's the answer's not so black and white -- suppose, for example, that your database barely fits into memory. Do you use object prevalence? If you know your application well, you can answer that a lot quicker -- for example, it's possible to use an object prevalent system as an index to a much larger datastore, but that's only worth considering if your application uses the data appropriately. Otherwise, go DIRECTLY to relational tech, do not pass "GO", do not pay the OODB people any money.
Huh? The relational model does not include indices at all. And any sort of processing of large amounts of data benefits from indices. You just have to build them yourself without a database system.
Sorry, yes. You're right.
Let me back up and try again, this time without misreading "indices" as "keys". Whoops.
Indices are useful to speed access to data. They're not the only way to do so; a more appropriate data structure will speed access far more than any index could. The entire point of prevalence is that you get to choose the most appropriate data structure, rather than shoehorning the data into rows and columns.
we don't need trasactions because our commands are already atomic. Which means you have to write all of the roll-back processing by-hand if you want any non-trivial commands. By the way, atomicity is only one aspect of a transaction.
The reason to want transactions isn't non-trivial commands; those are already handled correctly, since commands are atomic. (Please read the article!) You might want transactions if you need parallel commands, since you definitely need to rollback if your commands try to overlap -- but you might not need parallel commands if you're using object prevalence.
1) SQL is incredibly powerful. You give up *a lot* of power when you go from sql semantics to object semantics. Sub-selects, group bys and optimized stored procedures, to name just a few things.
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem.
Ditto for transactions.
2) You immedately make a massive reduction in the number of database administrators who will be willing and/or capable of helping you out in your project.
Instead, you have programmers who can do all that work. It's what they're paid for.
3) Scaling is always a question. With oracle, it just isn't.
The first part is true. The second part is laughable.
4) Backup, redundancy, monitoring, management, etc. Most mature relational databases have very good tools for doing these infrastructure activities.
A good part of the purpose of this solution is to make those possible. The article discusses them in depth.
The persistent store is quite language-specific. It doesn't allow for a Python application to access a Java store, for instance.
Nonsense. It's application specific, not at all language specific. No, it doesn't predefine how to link Python with Java; learning how to do THAT is up to you. (Hint: it's not hard, and has been done often before.)
It also doesn't seem to allow concurrent access to data, which would require significantly more than 350 lines of code.
Concurrent queries are easy; the site explains several ways of doing them. Concurrent updates are simply not possible given that scheme, though. If you really need them, perhaps you should be looking away from this and toward a system which has transactions (so that you can run your query at any time, and just allow the read to fail if something writes in the middle of the read).
But then, if your queries and updates are 9000 times faster, perhaps you don't need true concurrency anyhow.
I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this, you would be running no faster than a typical SQL DBMS
Chalk up one more person who's missed the point.
This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all.
Someone's been reading DBDebunk.com again.
Great site. I read it all the way through, hard reading though it is.
This is language-specific, or application-specific.
Oh? Which one, then? Language, or application? Have you read the page?
It's application specific. That's the point -- it includes only the code your application needs, and winds up being as reliable as relational would be, for FAR less overhead.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).
Your other problems are real, of course; but they're also very real for any real database, relational or otherwise.
Um... Sorta. It doesn't have SQL queries. Instead, you talk to your program's API to find out things from your program in the usual coding way.
So you DO have queries. You just don't have SQL queries. Instead you have Java queries, or C++ queries, or whatever language you're working with. You don't express them in SQL; instead, you express them using whatever API the author designed for queries.
what real project doesn't eventually need indices, transactions, or other features of a real database system?
You've got SQL blindness.
Yes, SQL needs indices because they're required to meet the relational model. If you're not relational, you don't need them.
Transactions are there primarily to allow relational actions to be grouped together to allow them to simulate the commands that would otherwise be more natural. Well, again, we're not relational; we don't need trasactions because our commands are already atomic.
All the examples you gave are features SQL had to add to overcome "problems" SQL has. Remove the problem, and you remove the need for the feature. (Of course, we know that those aren't problems with SQL, they're just characteristics; but nonetheless they DO create problems that you have to add features in order to solve.)
Don't get me wrong; I use SQL all the time; it's useful and powerful. But it's not _everything_. Object Prevalance is another tool in the kit, to be used when you don't need some of the things SQL provides.
Not really -- although the one I had was the cheapest Lexmark, the others spec out similarly in terms of cost-per-page. The Canon I got is not just lower cost-per-page, its cost per page is lower than any other printer I could calculate for, whether or not I calculated assuming third-party ink.
Canon already does this -- the low cost per page is one of their major selling points (even without paying attention to third party cartridge sources).
I had a Lexmark (came "free" with my computer), until I realised (after two refills) that buying a new Lexmark would be the same cost as buying a new refill. At that point I decided to see what was REALLY available. My new i550 kicks my old Lexmark's butt in _every_ way: faster, cheaper ink, uses less ink, monitors actual ink levels instead of trying to track in the driver (which utterly fails for network use), four independant ink cartridges, higher res, replacable print head,...
There HAS to be a catch:-). I haven't found it yet.
In XP, implementation is cheap up to a certain point where suddenly refactoring becomes imperative. Refactoring is then a very painful process given a very short iteration cycle.
Wow. I bet you'd also say that design is cheap, up to a certain point where testing becomes imperative. Or perhaps that implementation is cheap, up to the point where you have to integrate with the other programmers.
Wrong. Testing, and refactoring, are imperative from day one, according to XP. Before you add code, you start with cleanly factored code; if it's not clean, refactor it until it is. Then write the first component of your design in the form of a test. Next implement the code to make that test pass. Continue writing down more of your design in the form of a test and making the tests pass.
Once your design is fully expressed as tests and the tests all pass, refactor the code *immediately*.
Note how testing and refactoring are intermingled with coding? If you put the testing, coding, or refactoring off till later, you'll quickly find that your work becomes painful.
Integration should be constant as well -- the entire product should be ready to ship at least once a week, and should be built and tested in full at least once a day. If you put this off, you'll be creating work for yourself and setting yourself up for an expensive failure.
The practices try to make it easier to produce good code design, but they could be applied to any design methodology. You could do XP Object-Oriented or not, with Java, COBOL, perl, basic, or assembler.
You do know that those aren't design methodologies, right? XP is a lifecycle methodology, and thus includes a design methodology, as well as systems and practices which attempt to ensure that the methodology is followed.
There is nothing to make your software design good or bad except your skillz and the developer sitting next to you.
Wait, don't forget about all the other developers who'll be refactoring your code, and the tests which serve as much to document the original intent of changes as to test the continued validity of the changes, and the constant integration which keeps your code polished, and weekly or biweekly product deliveries that keep your customer in the feedback loop, and the planning game that makes sure important requirements are found and developed for, and...
So, I'd say XP doesn't enforce any coding methodology
You'd be right, but this is the first time you've said that; you've been talking about design methodologies before.
, but tries to create an environment that encourages good habits.
Nope, not XP's job -- that's for the team to do. You could say that XP describes a set of "good habits", and how they interrelate to reinforce each other.
I was talking about the methods for designing at a fairly low implementation level the actual code that makes an application work
Do you know the difference between "design" and "implementation"? I ask because in the above sentance you mix them up.
the parent comment here expressed concern about code made under XP being sloppy.
The parent comment poster should speak for himself, but I have to say that I did NOT see that in his post at all. What I saw was that he felt that code produced using XP would be unreliable: in other words, it would fail to meet requirements all or part of the time, either due to bad understanding of the requirements, bad solutions to the requirements, or bad implementations of the solutions.
That's what I meant by design.
Well, that's not design. That's coding standards. XP addresses those too, but leaves all the details to the team doing the actual work.
If you talk about RUP or Waterfall as a design methodology then obviously they are incompatible with XP.
So are you agreeing that XP includes design methodology?
BTW, minor point: RUP is a flexible system which can include XP. See Rational's own website for what I'd consider dramatic proof.
Somehow, I would never trust an "extreme programmed" program.
Would you ever trust any other program in this sense? Just curious.
I feel (perhaps just a prejudice) that
Sounds that way. Unless you have some facts that you haven't shared with us...
extreme programming is a "do now, think later" kind of approach.
No, it's the other way around -- "think now, do now." You're supposed to do things as you think of them -- when you come up with a clever design, don't write it down and walk away; instead, codify it as a test and then implement it. All the practices of XP are supposed to come together to prevent premature or delayed action: pair programming ensures that every idea put into code is understood enough to be explained to your peer; TDD ensures that every change made to code actually _adds_ some functionality; and so on.
I'd be interested in knowing if there have been studies with respect to reliability of extreme programmed projects.
A very interesting question! I think that we'll have answers on that in about five years. XP as a movement is a little new; very few companies have had a chance to adopt it, and only a few formal projects have been run with it.
Until then, any XP shop wishing to perform a high-reliability-required task would be wise to adopt some of the known reliabilty practices -- formal reviews, for example.
I guess my issue is that the XP approach does not dictate anything about design.
Actually, it explicitly does. One of its practices is Testy Driven Design: every element of the programmer's design is expressed in the form of a test, written in automatically executable form before anything is added to the code.
Another rule XP requests is to minimise Big Design Up Front: don't do design on something else else until you've proven the design for what you just did. In other words, don't design something and then leave it unimplemented; let every implementation be completed as close to its design time as possible.
I don't use XP, since my company has its own methodology (CMM level 3); I do use Test Driven Design. It works extremely well, and has the pleasant side effect of producing tests to hand in with my code for no additional effort. Given what I've experienced with TDD, I would take up XP in a heartbeat.
So, I think of XP as a set of tools, none of which restricts or prevents good design.
XP is not a set of tools, although there are one or two practices in XP which make sense outside of XP (for example, pair programming can be imagined in another context, and TDD works very well without XP). Rather, it's a complete methodology, much like the Spiral methodology or the much-feared Waterfall (and no, waterfall isn't a myth; I've seen it used a couple of times, and most of the rest of the time it's a good approximation).
This is just another twist on the old "guns don't kill people, people kill people" argument.
I can see why you say that (considering my post), but it's not really pertinent. The Unabomber says that technology makes our lives more complex; Lewis says that the dominion of Man over Nature (a phrase more used in his time than in ours) is actually, in the final analysis, the dominion of one man over every man. Both are considering technology; the Unabomber treats it as an abstract entity in its own right, while Lewis considers its qualities when seen as a means and an end.
It's as if someone wrote an essay claiming that guns were destroying our lives, and someone else wrote a book examining how the pursuit of guns was motivated, and speculating on the results of such motivation and actions. The analogy is perilously close, except that the Unabomber went on to murder a large number of people, something that most anti-gun people wouldn't consider (to say the least:-).
The guns-don't-kill-people analogy doesn't even come close here; Lewis isn't claiming that technology is harmless; instead he's looking past the technology to the motivations of the people using and developing it.
Put another way, who we are is inseparable from our technology. Technology is our adaptive response to the problem of survival. It is what makes our species unique on Earth. Talking about humans without reference to their technology is like talking about sharks without reference to their teeth.
Humans have MANY sources of adaptive response to problems of survival. Lewis doesn't talk about humans without resource to their technology; actually, he considers it as part of the issue, a larger issue, of how and why humans use technology and science in general.
Slashdot Mirror
Now you're not worried about encapsulation -- you're worried about the very concept of AOP. AOP allows you to insert new behavior almost _anywhere_, not only into new parent classes. You could use an aspect to insert the new behavior directly into the original parent without ever creating the inserted parent!
The trick is that this is very well defined behavior. Worrying about it is very much like refusing to use subroutines because some programmer might change one of them while you weren't looking -- better to keep all your code in one function so that you can SEE the changes people might make!
-Billy
If I wrote a function that didn't do bounds checking on a passed-by-reference array before it returned it, and it overran array bounds, there's no possible work around possible. It WILL bomb.
Okay, if that's the case, then there's no problem -- nothing to fear. Aspects won't change any "impossible" into a "possible".
Quite seriously, though, of COURSE it's possible to workaround almost any single bug. Programmers do it ALL the time -- usually one of the ways to find a bug is to first find a workaround, and only by carefully examining the workaround does the true cause become evident and fixable. Lazy programmers often just implement the workaround without bothering to fix the bug. Like I was saying, that sort of laziness is just as possible with AspectJ as it was with Java or C. No change.
And the preprocessor analogy isn't quite apropos, because with preprocessor directives you see something in the code that tells you something is happening at that point. It sounds like with aspects you don't get any corresponding cue in the code.
Not at all. Aspects can use more _subtle_ cues, yes; such as assignments to variables of a certain type, or calls to methods whose names match a regex; but the cues are all contained in the text. The analogy is very precise: AspectJ is a very powerful, semantically safe preprocessor for Java.
Perl does automagically fix stuff - overrun an array bounds?
Of course it does. I never said otherwise.
AspectJ doesn't and can't.
-Billy
Actually, that IS new since I learned the language; I can't say whether or not I like it, but I'm a bit suspicious.
Let me say, however, that what he did isn't illegal; anyone can declare a derived class, and a derived class has every right to access a protected variable. That fits the API of the original class perfectly well. And the subclass getting the new parent really had the right to access the private variable all along, so it's not doing anything wrong either.
No, this makes perfect sense. It fits with object orientation and aspect orientation, even if it seems a little roundabout at first. The object should be able to access the protected variable, but the aspect shouldn't be allowed to. Thus you introduce an object which can legitimately access it, and use it to build an API for the aspect to use.
-Billy
And if it is a team of programmers and someone wrote an aspect to "silently fix and keep running" these types of problems, then I may be in a world of hurt later on. And finding a bug that was thus hidden would be a nightmare.
No doubt if you were on the same team and someone wrote a function to work around a bug (rather than finding it and fixing it) you'd be in a world of hurt, too. It's possible, but it's no more possible now than it was before.
I mean, if I really want my program to handle "errors" in an "intuitive manner" and keep going, I'd write in Perl. (N.B. I *LIKE* Perl, but only for certain types of things).
You're confusing "aspects" with "magic". They don't fix errors for you. They don't "silently fix and keep running," any more than a text editor silently fixes your code and keeps it running, or the C preprocessor silently fixes C code and keeps it running. They only do what you code them to do.
In fact, the comparison to the C preprocessor is a very good one. The C preprocessor (cpp) searches through text for simple text patterns and replaces them; AspectJ searches through your program's parse tree for simple semantic patterns and augments them.
-Billy
Actually, AspectJ strictly observes encapsulation, so you're okay. (Or at least it did when I learned it -- there was some debate even at the time, since it's obvious that being able to pointcut on private variables is useful.)
I'm definitely on the side of forbidding breaking of encapsulation. There's too much coupling otherwise.
-Billy
The relational model offers logical advantages that cannot be found in ANY other system. If any other system achieved those advantages, it would become de facto relational. End of story.
;-).
Definitely. But the advantages that are exclusive to the relational model are in the realm of generality and ad-hoc querying, not in ease of use or anything else.
Look for the whole logical-physical confusion thing
Yes, a relational database with a good optimiser could do a lot, given a known query pattern. Guess what: a human can do more given a known "query pattern". And since there are no relational DBMSes, the human's so far ahead of the pack it's silly.
Yes, it has many languages, but if you try to access your Java Prevayler application data from PHP or Perl, you are going to have to re-implement all your integrity constraints in those languages. That's my point. No longer will you have a single point of control for your business rules, or the logical model of your data.
Look again -- if you didn't implement the Command dispatcher, you didn't even come CLOSE to implementing Object Prevalence. There can be only one command dispatcher; in the long run it's responsible for all integrity constraints. All languages have to go through it.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).
Huh? This is the most obvious one of all. With SQL, my VB, Java and Perl application could all interact with the same DBMS without needing to talk to each other. Thats a perfect solution in the real world.
In other words, if you adopt a single common language and include that language in everything you write --- yes, of course.
(I think I made a typo in my parenthesis about SQL. I can't tell what I originally meant, but I'm guessing it's the opposite of what I said -- SQL, like ANY common interface, naturally helps different languages work together.)
But SQL is ____far____ from "the perfect solution for the real world." Maybe you live in a far happier world than I, but embedding SQL code in C is a royal pain in the butt; maintaining it is _terrible_. It creates horrid coupling, and isn't easily debuggable, especially since the compiler can't check your work.
But that's my whole point. Separation of operations. Your data should have a single point of control for the logical constraints in the data, and that point of control should be a logical firewall between the data, and everything else that happens in the application.
SQL seems to place the dividing wall in the wrong place. It takes a LOT of effort and careful design to avoid sprinkling literal SQL code throughout C. Object Prevalance isn't a holy grail either, but it places the same dividing wall in a different place, and seems to work a _whole_ lot better for cohesion and coupling.
Also, in the end there is also nothing that an OO DBMS can do that a truly relational DBMS can't.
Agreed. And OP isn't an OODBMS.
-Billy
It sounds to me like the main selling points of AOP are that you don't have to design things well in the first place, because if you missed something, well then you can change how your objects behave without redesigning them.
No; of course, that won't work. Bad design can't be simply patched over; you'd have to edit the original source.
However, it _does_ mean that you don't have to write your function to include everything that your function has to do. You can code the function in a simplistic way, ignoring boundary cases, odd memory management quirks, and esoteric optimizations: just make the code say what it does. Then write an aspect to be the optimization, and another to handle memory management in that and similar code, and another to handle the boundary cases, and so on.
-Billy
You're 100% right on both caveats (although the first one only applies when you're 'cheating' by trying to dispatch multiple read commands at the same time, so isn't really a weakness of the solution itself); and either one in the wrong circumstances can indicate that object prevalence isn't the right solution for you.
-Billy
Grin -- you got me there.
Agreed entirely. Now I'm going back to my cubicle to write some more ODBC; when I finish, I'm going home to finish converting the savefile system for the game I maintain to use object prevalence. Enough of hearing about crashes but not being able to reproduce them... This time if it's my fault, it should happen every time, AND be possible to back out of.
-Billy
Excellent summary -- I see the problem. The other articles on the subject are written in a much more usable manner. Let me cover the ACID test, though.
1. Atomicity is implemented at the method-call level; there's no notion of a transaction (even a read transaction) that can be open while others are open too. The exception to that, of course, is if you write methods that read values from the business objects WITHOUT using doing it inside a Serializable subclass, in which case you've lost your atomicity anyway.
Commands are atomic (note the technical term "command"). It's possible to get around this; multiple read commands can be permitted at the same time, and don't even have to be journalled, but that's an optimization that's explored elsewhere in the OP literature (and has obvious shortcomings in that you give up Isolation).
2. It appears that there is no declarative data consistency checking; that's left up to the individual programmer accessing the Java objects directly.
Yes, because OP isn't declarative. A system can be added to any language you desire to give you preconditions, postconditions, and invariants; this is an old problem.
3. It appears that there is no transaction isolation; any code can read from the business objects directly.
Not really. Commands provide isolation; you're not supposed to access business objects outside of the context of a command.
4. There is a journaling mechanism that does provide durability.
Right.
Seriously, I agree with you on C; otherwise, prevalence seems to handle AID, and consistency can be handled with differing ease depending on your design.
-Billy
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem.
Really? Sub-selects are atomic at the object model level? Come again?
I don't understand how you managed to read into my message the exact opposite of what I was saying. NO, sub-selects are not atomic at the object model level. NO, NO, no. That's the problem; that's why relational databases have to include the concept of transactions, to group primitive queries together into a single imitated atom. Meanwhile, the prevalent system doesn't support that type of grouping, and doesn't need it because its commands are all already atomic.
So some new Object database tarted up with fancy-schmancy new terminology suddenly makes transactions easy?
No -- it tries to do without them instead. This is classical engineering -- don't try to add more features to solve a perplexing problem; instead, try a new solution.
Multiple updates to an object graph from multiple threads in a transactional manner become, somehow, easier? _rolls eyes_ Riiiiiiiight...
Nope; this method does NOT work with simultaneous updates (whether they're done in a "transactional manner" or not). If you need them, this is NOT for you. On the other hand, if your database can fit the requirements of this, it's possible that you won't need true simultaneous updates; if an update takes a millisecond instead of a second, it's likely that your second update can just wait.
Oh wait, daily hot backups kinda suck to be around for.
I hope you're not seriously complaining about them -- they're lifesavers. If you're trying to sarcasticly imply that object prevalence doesn't handle those things, or makes them harder to manage, all I can say is that you have no idea what object prevalence is. An Oracle-trained DBA wouldn't know how to set up a hot backup for one of these systems; but let the programmers show him around the system for a short while, and he'll be up to speed (although he won't be using any of his Oracle training, so you'd be better off hiring someone else).
And chucking stored procs for intensive operations kinda sucks.
I've worked with stored procs, but I've never done anything with them that I'd call "chucking". Is that some terminology I'm just unfamiliar with?
Unless you mean "I don't want to stop writing stored procedures." In which case -- well, I don't know why you're complaining. Object prevalence really is one huge stored procedure.
Well, you'll forgive me if I'm not impressed. Get all users?
Not impressive code. I agree. But keep in mind that all the user records are in memory -- getting a list of them, or a reference to the master index of them, isn't a challenge. Asking the master index to look up a user based on his login isn't a challenge either -- perhaps that's done via hash table, perhaps via ternary search tree.
And what about in big ol' databases, when not everything can live in memory?
Great question -- according to the authors, you don't use object prevalence for those. It gives no advantages in those cases, and huge disadvantages. Simple question, simple answer.
The problem is, of course, that sometime's the answer's not so black and white -- suppose, for example, that your database barely fits into memory. Do you use object prevalence? If you know your application well, you can answer that a lot quicker -- for example, it's possible to use an object prevalent system as an index to a much larger datastore, but that's only worth considering if your application uses the data appropriately. Otherwise, go DIRECTLY to relational tech, do not pass "GO", do not pay the OODB people any money.
-Billy
Huh? The relational model does not include indices at all. And any sort of processing of large amounts of data benefits from indices. You just have to build them yourself without a database system.
Sorry, yes. You're right.
Let me back up and try again, this time without misreading "indices" as "keys". Whoops.
Indices are useful to speed access to data. They're not the only way to do so; a more appropriate data structure will speed access far more than any index could. The entire point of prevalence is that you get to choose the most appropriate data structure, rather than shoehorning the data into rows and columns.
we don't need trasactions because our commands are already atomic.
Which means you have to write all of the roll-back processing by-hand if you want any non-trivial commands. By the way, atomicity is only one aspect of a transaction.
The reason to want transactions isn't non-trivial commands; those are already handled correctly, since commands are atomic. (Please read the article!) You might want transactions if you need parallel commands, since you definitely need to rollback if your commands try to overlap -- but you might not need parallel commands if you're using object prevalence.
-Billy
Nope, this already has those. Read the article.
-Billy
1) SQL is incredibly powerful. You give up *a lot* of power when you go from sql semantics to object semantics. Sub-selects, group bys and optimized stored procedures, to name just a few things.
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem.
Ditto for transactions.
2) You immedately make a massive reduction in the number of database administrators who will be willing and/or capable of helping you out in your project.
Instead, you have programmers who can do all that work. It's what they're paid for.
3) Scaling is always a question. With oracle, it just isn't.
The first part is true. The second part is laughable.
4) Backup, redundancy, monitoring, management, etc. Most mature relational databases have very good tools for doing these infrastructure activities.
A good part of the purpose of this solution is to make those possible. The article discusses them in depth.
-Billy
The persistent store is quite language-specific. It doesn't allow for a Python application to access a Java store, for instance.
Nonsense. It's application specific, not at all language specific. No, it doesn't predefine how to link Python with Java; learning how to do THAT is up to you. (Hint: it's not hard, and has been done often before.)
It also doesn't seem to allow concurrent access to data, which would require significantly more than 350 lines of code.
Concurrent queries are easy; the site explains several ways of doing them. Concurrent updates are simply not possible given that scheme, though. If you really need them, perhaps you should be looking away from this and toward a system which has transactions (so that you can run your query at any time, and just allow the read to fail if something writes in the middle of the read).
But then, if your queries and updates are 9000 times faster, perhaps you don't need true concurrency anyhow.
-Billy
I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this, you would be running no faster than a typical SQL DBMS
Chalk up one more person who's missed the point.
This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all.
Someone's been reading DBDebunk.com again.
Great site. I read it all the way through, hard reading though it is.
This is language-specific, or application-specific.
Oh? Which one, then? Language, or application? Have you read the page?
It's application specific. That's the point -- it includes only the code your application needs, and winds up being as reliable as relational would be, for FAR less overhead.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).
Your other problems are real, of course; but they're also very real for any real database, relational or otherwise.
-Billy
In other words, "it doesn't have queries".
Um... Sorta. It doesn't have SQL queries. Instead, you talk to your program's API to find out things from your program in the usual coding way.
So you DO have queries. You just don't have SQL queries. Instead you have Java queries, or C++ queries, or whatever language you're working with. You don't express them in SQL; instead, you express them using whatever API the author designed for queries.
what real project doesn't eventually need indices, transactions, or other features of a real database system?
You've got SQL blindness.
Yes, SQL needs indices because they're required to meet the relational model. If you're not relational, you don't need them.
Transactions are there primarily to allow relational actions to be grouped together to allow them to simulate the commands that would otherwise be more natural. Well, again, we're not relational; we don't need trasactions because our commands are already atomic.
All the examples you gave are features SQL had to add to overcome "problems" SQL has. Remove the problem, and you remove the need for the feature. (Of course, we know that those aren't problems with SQL, they're just characteristics; but nonetheless they DO create problems that you have to add features in order to solve.)
Don't get me wrong; I use SQL all the time; it's useful and powerful. But it's not _everything_. Object Prevalance is another tool in the kit, to be used when you don't need some of the things SQL provides.
-Billy
Not really -- although the one I had was the cheapest Lexmark, the others spec out similarly in terms of cost-per-page. The Canon I got is not just lower cost-per-page, its cost per page is lower than any other printer I could calculate for, whether or not I calculated assuming third-party ink.
-Billy
Canon already does this -- the low cost per page is one of their major selling points (even without paying attention to third party cartridge sources).
...
:-). I haven't found it yet.
I had a Lexmark (came "free" with my computer), until I realised (after two refills) that buying a new Lexmark would be the same cost as buying a new refill. At that point I decided to see what was REALLY available. My new i550 kicks my old Lexmark's butt in _every_ way: faster, cheaper ink, uses less ink, monitors actual ink levels instead of trying to track in the driver (which utterly fails for network use), four independant ink cartridges, higher res, replacable print head,
There HAS to be a catch
-Billy
Terrible analogy. This bill applied to people who were distributing copies of the copyrighted item, not people who had it.
But yeah, it was a stupid bill. Almost as stupid as Canada's media tax. I blame Canada.
In XP, implementation is cheap up to a certain point where suddenly refactoring becomes imperative. Refactoring is then a very painful process given a very short iteration cycle.
Wow. I bet you'd also say that design is cheap, up to a certain point where testing becomes imperative. Or perhaps that implementation is cheap, up to the point where you have to integrate with the other programmers.
Wrong. Testing, and refactoring, are imperative from day one, according to XP. Before you add code, you start with cleanly factored code; if it's not clean, refactor it until it is. Then write the first component of your design in the form of a test. Next implement the code to make that test pass. Continue writing down more of your design in the form of a test and making the tests pass.
Once your design is fully expressed as tests and the tests all pass, refactor the code *immediately*.
Note how testing and refactoring are intermingled with coding? If you put the testing, coding, or refactoring off till later, you'll quickly find that your work becomes painful.
Integration should be constant as well -- the entire product should be ready to ship at least once a week, and should be built and tested in full at least once a day. If you put this off, you'll be creating work for yourself and setting yourself up for an expensive failure.
-Billy
The practices try to make it easier to produce good code design, but they could be applied to any design methodology. You could do XP Object-Oriented or not, with Java, COBOL, perl, basic, or assembler.
You do know that those aren't design methodologies, right? XP is a lifecycle methodology, and thus includes a design methodology, as well as systems and practices which attempt to ensure that the methodology is followed.
There is nothing to make your software design good or bad except your skillz and the developer sitting next to you.
Wait, don't forget about all the other developers who'll be refactoring your code, and the tests which serve as much to document the original intent of changes as to test the continued validity of the changes, and the constant integration which keeps your code polished, and weekly or biweekly product deliveries that keep your customer in the feedback loop, and the planning game that makes sure important requirements are found and developed for, and...
So, I'd say XP doesn't enforce any coding methodology
You'd be right, but this is the first time you've said that; you've been talking about design methodologies before.
, but tries to create an environment that encourages good habits.
Nope, not XP's job -- that's for the team to do. You could say that XP describes a set of "good habits", and how they interrelate to reinforce each other.
I was talking about the methods for designing at a fairly low implementation level the actual code that makes an application work
Do you know the difference between "design" and "implementation"? I ask because in the above sentance you mix them up.
the parent comment here expressed concern about code made under XP being sloppy.
The parent comment poster should speak for himself, but I have to say that I did NOT see that in his post at all. What I saw was that he felt that code produced using XP would be unreliable: in other words, it would fail to meet requirements all or part of the time, either due to bad understanding of the requirements, bad solutions to the requirements, or bad implementations of the solutions.
That's what I meant by design.
Well, that's not design. That's coding standards. XP addresses those too, but leaves all the details to the team doing the actual work.
If you talk about RUP or Waterfall as a design methodology then obviously they are incompatible with XP.
So are you agreeing that XP includes design methodology?
BTW, minor point: RUP is a flexible system which can include XP. See Rational's own website for what I'd consider dramatic proof.
-Billy
Somehow, I would never trust an "extreme programmed" program.
Would you ever trust any other program in this sense? Just curious.
I feel (perhaps just a prejudice) that
Sounds that way. Unless you have some facts that you haven't shared with us...
extreme programming is a "do now, think later" kind of approach.
No, it's the other way around -- "think now, do now." You're supposed to do things as you think of them -- when you come up with a clever design, don't write it down and walk away; instead, codify it as a test and then implement it. All the practices of XP are supposed to come together to prevent premature or delayed action: pair programming ensures that every idea put into code is understood enough to be explained to your peer; TDD ensures that every change made to code actually _adds_ some functionality; and so on.
I'd be interested in knowing if there have been studies with respect to reliability of extreme programmed projects.
A very interesting question! I think that we'll have answers on that in about five years. XP as a movement is a little new; very few companies have had a chance to adopt it, and only a few formal projects have been run with it.
Until then, any XP shop wishing to perform a high-reliability-required task would be wise to adopt some of the known reliabilty practices -- formal reviews, for example.
-Billy
I guess my issue is that the XP approach does not dictate anything about design.
Actually, it explicitly does. One of its practices is Testy Driven Design: every element of the programmer's design is expressed in the form of a test, written in automatically executable form before anything is added to the code.
Another rule XP requests is to minimise Big Design Up Front: don't do design on something else else until you've proven the design for what you just did. In other words, don't design something and then leave it unimplemented; let every implementation be completed as close to its design time as possible.
I don't use XP, since my company has its own methodology (CMM level 3); I do use Test Driven Design. It works extremely well, and has the pleasant side effect of producing tests to hand in with my code for no additional effort. Given what I've experienced with TDD, I would take up XP in a heartbeat.
So, I think of XP as a set of tools, none of which restricts or prevents good design.
XP is not a set of tools, although there are one or two practices in XP which make sense outside of XP (for example, pair programming can be imagined in another context, and TDD works very well without XP). Rather, it's a complete methodology, much like the Spiral methodology or the much-feared Waterfall (and no, waterfall isn't a myth; I've seen it used a couple of times, and most of the rest of the time it's a good approximation).
-Billy
This is just another twist on the old "guns don't kill people, people kill people" argument.
:-).
I can see why you say that (considering my post), but it's not really pertinent. The Unabomber says that technology makes our lives more complex; Lewis says that the dominion of Man over Nature (a phrase more used in his time than in ours) is actually, in the final analysis, the dominion of one man over every man. Both are considering technology; the Unabomber treats it as an abstract entity in its own right, while Lewis considers its qualities when seen as a means and an end.
It's as if someone wrote an essay claiming that guns were destroying our lives, and someone else wrote a book examining how the pursuit of guns was motivated, and speculating on the results of such motivation and actions. The analogy is perilously close, except that the Unabomber went on to murder a large number of people, something that most anti-gun people wouldn't consider (to say the least
The guns-don't-kill-people analogy doesn't even come close here; Lewis isn't claiming that technology is harmless; instead he's looking past the technology to the motivations of the people using and developing it.
Put another way, who we are is inseparable from our technology. Technology is our adaptive response to the problem of survival. It is what makes our species unique on Earth. Talking about humans without reference to their technology is like talking about sharks without reference to their teeth.
Humans have MANY sources of adaptive response to problems of survival. Lewis doesn't talk about humans without resource to their technology; actually, he considers it as part of the issue, a larger issue, of how and why humans use technology and science in general.
The Unabomber, on the other hand? Feh.
-Billy