> Michael,
> Thanks for your interest !
> >>I am also interested in this and willing to participate.
> Absolutely, just give me some time to put together a starter document, run
> it by people whose content I might have borrowed/referred to and then we'll
> all get to collaborate and add on it.
> >But does that mean that if you have a best practice everything else is
> bad practice?
> Definitely not. There are always multiple ways of achieving something.
> An anti-pattern, however is something that causes a lot of harm (e.g. it
> makes very hard or impossible to make enhancements with reasonable cost) in
> addition to the effects you mentioned.
> Effects I had in mind:
> 1. Reduce your ability to change code easily, add new functionality with
> minimal cost. etc.
> 2. Actually neutralize and negate the benefits offered by the framework
> because either it is used incorrectly or contrary to how it's meant to be
> used.
> On Thu, Nov 5, 2009 at 6:34 PM, Michael Koniotiakis <mko...@hotmail.com>wrote:
>> I am also interested in this and willing to participate.
>> Yet I feel like we need to define more what anti-patterns are.
>> The best definition that comes in mind is that:
>> Its a way to implement functionality that has a better way to
>> implement the same functionality.
>> But does that mean that if you have a best practice everything else is
>> bad practice?
>> Since nothing is black or white, I feel we need to define in more
>> detail criteria that will evaluate one pattern against an other. I
>> could think of:
>> Reduce of Quality.
>> Reduce of Reusability
>> Reduce performance
>> Increase of development time
>> Increase of complexity
>> Generate bugs in combination with other practices or components
>> So I would suggest for every anti-pattern to define which criteria
>> make it an anti-pattern, and if possible to suggest a better practice
>> based on the same criteria.
>> On Nov 5, 2:53 pm, Drikus Britz <drikusbr...@gmail.com> wrote:
>> > Also saw on the slide show Andrejus Baronovskis presented he mentioned
>> > quite a couple of things to avoid/stay away from when working with ADF
>> > in a production environment.
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
|
