[macker-user] Re: Macker-user digest, Vol 1 #35 - 1 msg

[Michael S. <MS...@in...>]

Hi Alex

My impression with Macker is that it is designed to describe and check 
relationships between Classes using the implement, extend, and import 
relationships that classes have with each other. Macker does not seem to 
analyze specific call relationships between classes. (Anybody, please 
correct me if I am wrong with this).

The rules that you described require the concept of a call to a 
constructor / static factory method between classes which is not supported 
by Macker.

However, it seems if you change yor package structure a bit, you can use 
Macker to enforce your rule: If you move the DAO interfaces in their own 
subpackages, e.g. parallel to the package with the DAO implementations, 
you can define a rule that basically express the following: "It is a 
violation to use a DAO Implementation class from anywhere in the 
application with the exception of the DAOFactory". However, it would be ok 
to access the DAO interfaces from anywhere in the application.

This means that your entire application code should always refer to the 
interfaces of an DAO, never its instance. The only entity in your code 
that  may know about the DAO instances is the DAOFactory class. So, it 
would be feasible to rotate out the DAO implementations, updating the 
factory and be done with a persistence change.


How can you achieve what you want to achieve in the case in which you 
cannot change the package structure?

I tried something similar during an analysis of a large system and wanted 
to check similar small design issues as well as large scale issues. For 
the large-scale issues I was able to use Macker. For the smaller design 
issues I decided to create static aspects in AspectJ 5 to define 
appropriate join points and use the static compiler checker feature of the 
AspectJ 5 compiler to report violations as warnings or errors during the 
compilation process. This works well but there are some issues for very 
large projects.

An alternative approach is the use of Inversion of Control (IoC). With 
this design approach, DAOs would be injected into the application code by 
an external framework (e.g. Spring or an programmatic IoC approache). This 
means that the developer does not need to think about creating DAO 
instances or even call the factory for that matter. The creation and 
injection is done by the IoC  framework itself and all the DAO 
implementations can be defined in an external file. Since the application 
code would only be allowed to refer to the interface of the DAO , we can 
use the same method as described above to enforce the correct use of DAOs.

If you have any questions related to the three approaches above, please 
feel free to contact me directly. I think this may be amore of an offline 
discussion.

Regards,

Michael




mac...@li... 
Sent by: mac...@li...
03/21/2006 11:35 PM
Please respond to
mac...@li...


To
mac...@li...
cc

Subject
Macker-user digest, Vol 1 #35 - 1 msg






Send Macker-user mailing list submissions to
                 mac...@li...

To subscribe or unsubscribe via the World Wide Web, visit
                 https://lists.sourceforge.net/lists/listinfo/macker-user
or, via email, send a message with subject or body 'help' to
                 mac...@li...

You can reach the person managing the list at
                 mac...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Macker-user digest..."


Today's Topics:

   1. factory pattern violation recognition (Alex Greif)

--__--__--

Message: 1
Date: Tue, 21 Mar 2006 09:30:00 +0100
From: "Alex Greif" <ale...@gm...>
To: mac...@li...
Subject: [macker-user] factory pattern violation recognition

Hi,

first of all, thanks for "macker"! We use it and it hels a lot!

now to my question:
beside checking architecture layer violations we want to use macker to
check factory pattern violations. In out persistence layer we want
that everybody gets a dao instance through the DAOFactory and nobody
should create a new DAO Instance with "new".

In other words, inside a dao class it is allowed to access the
DAOFactory and dao interfaces but not to instanciate and directly
access dao classes.

beneath is my rule declaration. I made these patterns:
- dao classes
- daoFactory
- dao interfaces

Then I prohibit to access dao classes and exclude the factory and the
interfaces.

My problem is that dao classes which are "OK", and follow the rules
are still reported from macker.
I disassambled the class file of this "fine" dao, and saw that there
is still an import statement, that imports the other dao.
Does that mean that the line
OtherDAO otherdao =3D DAOFactory.getInstance().getOtherDAO();
has the class declaration of OtherDAO in the constant pool, so that
macker reports it as a violation?

Is there a way to check this factory pattern violation with macker?

thanks,
ALex


    =09<pattern name=3D"pt_server_persistenz_dao_class">
    =09=09<include class=3D"${star_server_persistenz}.dao.**.DAO*" />
    =09=09<exclude class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09</pattern>
    =09<pattern name=3D"pt_server_persistenz_daoFactory"
class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09<pattern name=3D"pt_server_persistenz_dao_ifc"
class=3D"${star_server_persistenz}.dao.*Interface" />



        <access-rule>
        =09<message>DAOs d=FCrfen DAOs nicht direkt aufrufen, sondern nur
=FCber DAOFactory</message>
            <deny>
            =09<from pattern=3D"pt_server_persistenz_dao_class"/>
            =09<to>
            =09=09<include pattern=3D"pt_server_persistenz_dao_class"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_daoFactory"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_dao_ifc"/>
                </to>
            </deny>
        </access-rule>



--__--__--

_______________________________________________
Macker-user mailing list
Mac...@li...
https://lists.sourceforge.net/lists/listinfo/macker-user

Macker home page: http://innig.net/macker/

End of Macker-user Digest