Design patterns books have been gaining popularity since languages like Java and C++ first became widely used. Since Microsoft released its first truly object-oriented language, .NET, software designers from an even broader range of business and programming spheres have been looking for ways to refine and write better code. Many have turned toward design patterns, iterative and AGILE design methodologies, and other more defined ways to improve performance, maintainability, portability, and scalability of code as well as design processes. This book fits into that need in that it can teach people who write software new skills and techniques for improving their existing and new coding efforts.
Wordware is offering a 35% discount and free freight (continental U.S. only) to all Codeproject members/visitors when the book is purchased from www.wordware.com. The discount is good not only for my book, but for all books purchased from the site. Just enter the coupon code dp0314 when ordering.
In reading your articles on AOM, each new article demonstrates
a new way to use meta-data with an "Interperter Function" to perform what used to be "hard-coded" in a class. I'm a little
reluctant to jump in until all the articles are finished, but let me ask one for clarification on where you are going. With you
last article to cover "Interpreter methodologies", will classes (in your examples) like ExecutiveJobEntityType or JobOperation1 disappear into meta-land or business rules?
My hope is that they would. A system that handles 90% of the domain
specific functinality, but leaves 10% of it in code seems destined to join the crowded field of 90% solutions.
**THIS ARTICLE IS DONE** This is the next article I plan on getting around to writing, explaining how Entity, EntityType, Attribute and AttributeType deal with relationships within the model. I have some new data on this subject from my peer collaberations, and would will be taking some differnt approaches to the way I previously stated that relationships might occur, how they interact, and why.
I still plan on writing a full series of 'how to' articles on all the rest of the GOF patterns that I have not yet covered, and hopefully as I write new ones, I will get even better at explaining to both the pattern beginners and pattern elite, how basic implementaions work. Anybody got a suggestion on the next one they would like to see an article on? Right now it is up for grabs.
Anybody out there interested in discussing and sharing thier advanced design patterns experience? I am interested in Aspect Oriented programming, Adaptive Object Modeling, and other like patterns. Java and C# welcome.
Doga, is this you?
I think what makes a great programmer is the ability to self maintain, in other words to increase ones skills daily. A good designer is someone who can look at new design tools (like patterns methodologies), and evaluate these to improve thier skills. Also a lot of self deprecation in regard to usefulness of these skills is needed. What I always say about good design is 'Make it just complex enough, but not overly complex'. I think this holds true for anything you do.
As far as being a good developer, anybody working with these advanced patterns would have to be. And part of what makes a good developer is good practices.
Thanks for sharing buddy!
Yeah I agree, that patterns are not always the answer, just another tool. Like all tools sometimes a laser is the right tool, sometimes a hammer is. BTW What did you think of my latest article? Still waiting for someone knowledgeable on the AOM pattern to actually give me some constructive critisism. I mean, am I missing or misunderstanding something? Did I hit the nail on the head? Most comments are like 'what the hell is this?' or 'does this pattern work?' or 'blah, blah, blah' (nothing to do with the pattern). I would really like to get some feed back from someone like yourself who understands and uses the pattern to see if I really captured the AOM pattern method correctly in my article....
Yeah I saw the comments.. they dont understand.
in my work place there is an adviser. He finished his project as prototype for us.
so we will match that with ours.
but that is shame we cant find many people to discuss (I was telling you on my emails )
but a Architect who is from Microsoft.. he answered my forum.
look at here :
I started a thread in msdn forum. but there isnt much. but I had a great post and it is really possitive
I guess my questions shouldn’t be directed at the NAOM framework. I understand that you are using the framework as way to gain more insight on AOM and its potential / problems and as a teaching mechanism for people who want to learn about AOM patterns.
So, let me move my question over to the “more general patterns thread”.
In “The Adaptive Object-Model Architectural Style” by Yoder, Johnson WICSA3, several statements have caught my attention for additional comment.
a) “Many architects who have designed a system with Adaptive Object-Models claim that it is the best system they have ever created, and they brag about its flexibility, power, and eloquence.”
b) “However, developers that have to use, extend, or maintain them, usually complain that they are hard to understand and are not convinced that they are not as great as the architect claims.”
c) “Classes do not represent business abstractions because Most information about the business is in the database.”
d) “Adaptive Object-Models leads to a domain-specific language.”
e) “It is possible to design dynamic GUIs but this can be difficult and is usually domain specific.
So my concern over using AOM is this. It has a high cost of entry in that you need a really smart architect with equally good developers. (One observation I have is that it takes a really smart architect to design something that can’t be built) And, in the end, you end up with a Domain Specific Solution, which to me says that when you want to expand the AOM domain, you are back relying on those really smart (expensive) guys.
To me opens up the alternatives such as MDA or Software Factories as the more generic and industry supported path to take.
So my question: Is AOM destined as a niche domain specific solution? Or can it be “Adapted” so that all ALL business data can be placed in the DB?
Asked another way, what are the barriers to making AOM a general purpose solution?
I've been developing an AOM framework (using .net) for sometime now, where I've applied domain driven design approach together with an AOM approach with fairly good success.
However, I've got lots of questions/ideas pertaining to best-practice when it comes to various cross-cutting concerns such as dynamic querying, dependancies, auditing, performance etc. ~ you know where I'm headed.
I guess my frustration is that there is not much on the web on the subject, and little or no Open Source implementations so I feel like a bit of a pioneer. What I have found has been mostly academic and very light. Also very few (willing) people out there who could possibly help ~ Yoder, Fowler, Yegge [and you ] are more than likely out of my league anyway.
In any case Fowler says "I urge you not to use this approach" in his paper "Dealing with Properties" in 2007 so I guess that's why...
I am hardly out of anyones league, but I guess I can take that as a compliment. As far as Fowler, like many authors he is only really interested in things that pertian to his work. He is too busy for much else, as we all are. I wouldn't discount the patterns, they are useful if you have to put together a meta-data system, and there are some software companies using it. Keep plugging, and share your results with the rest of the community, it is the best way to get others interested in what you are doing.
I took your advice and started an open source project called NAom[^] on CodePlex.
It's a starting point, but nowhere near to fully implementing the "specification" of AOM as documented by you and others.
Also, I've deviated slightly from the specification, in so far as it is possible for both known and dynamic types of a given application domain to co-exist. i.e. An "AOM'd" type can derive from a well known (design-time) type.
This helps addresses to some extent, the "understandability pitfall" of the AOM approach as mentioned by Ralph E. Johnson in one of his papers on the subject.