Showing posts with label OOD. Show all posts
Showing posts with label OOD. Show all posts

Friday, 26 June 2015

Worth a read: UX is not UI

I love UX and spend hours thinking about how to make a great UX (no really).
So when I read this article I just had to share.
UX has become a neologism. When something has “good UX” it is an implied meaning of having the core components of UX (research, maybe a persona, IA, interaction, interface, etc etc…). It’s not really necessary or desirable to tack the word design onto the end anymore. It’s a distraction and leads people down a parallel but misguided path… the path to thinking that UX = User Interface Design.
See: http://www.helloerik.com/ux-is-not-ui  and the graphic from the article here.

Saturday, 2 March 2013

Project on Sourceforge: Pojo/Bean mapper

This is a work in progress but I am creating an ANT task to generate the conversion classes to allow you to create the code that transfers data from one POJO to an other..
While at first sight this may seem similar to dozer the primary difference is that this is code generation and does not have the overhead of using introspection at run time.


Project on Sourceforge: https://sourceforge.net/projects/pojobeanmapper/


The original use for this was to take data out of a set of Hibernate DAO objects and create a variety of XML DOM objects from them. In the project that instigated this work the mapping between the DAOs and the XML DOM was not one for one and encoding the conversion into the DOAs was not a good idea.

Use

To create the task ensure the ant-pojomapper-x.x.xx.jar is on your ANT path (I suggest in ANT_HOME/lib).
Create the task with this task def command:

<property name="ant.pojomapper.dir" value="./libs/pojomapper"/>
<path id="pojomapper.lib.classpath">
<fileset dir="${ant.pojomapper.dir}" includes="*.jar" />
</path>
<taskdef resource="pojomapper_ant.properties" classpathref="pojomapper.lib.classpath" />


Once declared this will allow you to call the pojomapper task.
This will look something like this:

<beanmapper
classPath="${build.classpath}"
settingsFolder="./src/templates"
srcPackage ="myproj.dom1"
dstPackage ="myproj.api"
dstDir ="${gensrc.java.dir}/pojomapping"
outputPackageName ="myproj.dom1.converters"
/>

To work correctly there needs to be at least the following file present in the settings folder:
This file is a "property" file which contains the classes that equate to each other.

beanmapper-classpairs.properties

This file is of the form:

srcClass1=destClass1
srcClass2=destClass2

In this example two classes will be created in the package myproj.dom1.converters:

SrcClass1ToDestClass1Copier.java
SrcClass2ToDestClass2Copier.java


The generator will create these files under the folder   ${gensrc.java.dir}/pojomapping/src
along with a copy of the beanmapper-classpairs.properties file.


Additionally two other files are auto-generated.
These files can be reused if the build process failed.

beanmapper-knownmethodmappings.properties

While the this pojo mapper will match beans of the same name.
There are some that it will not beable to convert.

destClass.setter=srcClass.getter

The file defines the mappings that are already known.

PojoB.pennies=PojoA.cash
PojoB.extra=PojoA.more

At the end of the generated file are a series of mappings the pojo mapper could not determine what should be done with them.
These will appear as follows:

## Missing mappings
# destClass.???=PojoA.getter1
# destClass.???=PojoA.getter2

This allows the developer to determine quickly which methods need some attention.

beanmapper-classconverters.properties

There are conversions that the pojomapper knows implicitly but some are not known.

These need to be defined for it as follows:

SrcType:DstType=ConverterClass.convertermethod

This will create a call in any of the generated code where a SrcType class needs to be converted into a dstType.

The call will be approximatly as follows:

SrcType a ;
DstType b ;
b = ConverterClass.convertermethod(a);


If the pojomapper will detect the need for converters that it is self will be creating.

MAVEN USE

It is possible to use this ant task as a plugin.
Add the following:

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>1.7</version>
                <executions>
                    <execution>
                        <id>download-files</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <target>
                                <echo>+++++++++++++++++ DOWNLOAD POJO BEAN MAPPER ++++++++++++++</echo>
                                <echo>Download pojobeanmapper to ${project.build.pojobeanmapper.jar}</echo>
                                <mkdir dir="${project.build.download.folder}" />
                                <get src="${project.build.pojobeanmapper.url}" 
                                        dest="${project.build.pojobeanmapper.jar}"
                                        verbose="false" 
                                        usetimestamp="true" />
                                <echo>Get commons-io 2.1</echo>
                                <get src="http://repo1.maven.org/maven2/commons-io/commons-io/2.1/commons-io-2.1.jar" 
                                        dest="${project.build.download.folder}"
                                        verbose="false" 
                                        usetimestamp="true" />
                                <echo>Get commons-lang 2.6</echo>
                                <get src="http://repo1.maven.org/maven2/commons-lang/commons-lang/2.6/commons-lang-2.6.jar" 
                                        dest="${project.build.download.folder}"
                                        verbose="false" 
                                        usetimestamp="true" />                                
                            </target>
                        </configuration>
                    </execution>
                    <execution>
                        <phase>generate-sources</phase>
                        <configuration>
                            <target>
                                <echo>+++++++++++++++++ INVOKE POJO BEAN MAPPER ++++++++++++++</echo>
                            
                                <!-- sEE: http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html -->
                                <property name="compile_classpath" refid="maven.compile.classpath"/>
                                <property name="runtime_classpath" refid="maven.runtime.classpath"/>
                                <property name="test_classpath"    refid="maven.test.classpath"/>
                                <property name="plugin_classpath"  refid="maven.plugin.classpath"/>
                                <path id="pojomapper.lib.classpath">
                                     <fileset dir="${project.build.download.folder}" includes="*.jar" />
                                </path> 
                                <taskdef resource="pojomapper_ant.properties" 
                                         classpathref="pojomapper.lib.classpath" />

                                <beanmapper 
                                    classPath="${compile_classpath}"
                                    settingsFolder="./src/templates"
                                    srcPackage ="com.proj.src"
                                    dstPackage ="com.proj.dst"
                                    dstDir ="${project.build.directory}/pojomapping"
                                    outputPackageName ="com.proj.converters"
                                    />

                            </target>
                        </configuration>
                        <goals>
                            <goal>run</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>


and add the following properties:

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.build.pojobeanmapper.url>http://sourceforge.net/projects/pojobeanmapper/files/latest/download?source=files</project.build.pojobeanmapper.url>
        <project.build.download.folder>${project.build.directory}/downloads</project.build.download.folder>
        <project.build.pojobeanmapper.jar>${project.build.download.folder}/pojobeanmapper.jar</project.build.pojobeanmapper.jar>
    </properties>


------------------------------------------------------------------------------
Please return to the is blog entry for full information at a later date.
It will be updated over the month of decemper 2013.

Friday, 20 July 2012

"Gang of Four" design paterns

There are times when you find something on the web and you go are that's useful! There are several reasons for this revelation, in this case it is a reminder that there are good ways and bad ways to write your code.

This article is one of those salutary reminders that we can all do better. So I have posted a link to the here with a short synopsis so I can find it when I need to be reminded.


Design patterns provide solutions to common software design problems. In the case of object-oriented programming, design patterns are generally aimed at solving the problems of object generation and interaction, rather than the larger scale problems of overall software architecture. They give generalised solutions in the form of templates that may be applied to real-world problems.
Design patterns are a powerful tool for software developers. However, they should not be seen as prescriptive specifications for software. It is more important to understand the concepts that design patterns describe, rather than memorising their exact classes, methods and properties. It is also important to apply patterns appropriately. Using the incorrect pattern for a situation or applying a design pattern to a trivial solution can overcomplicate your code and lead to maintainability issues.

The Gang of Four are the authors of the book, "Design Patterns: Elements of Reusable Object-Oriented Software". This important book describes various development techniques and pitfalls in addition to providing twenty-three object-oriented programming design patterns. The four authors were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

The full article by , is published at http://www.blackwasp.co.uk/GofPatterns.aspx but the types of patterns he describes are listed here:

Creational Patterns

The first type of design pattern is the creational pattern. Creational patterns provide ways to instantiate single objects or groups of related objects. There are five such patterns:
  • Abstract Factory. The abstract factory pattern is used to provide a client with a set of related or dependant objects. The "family" of objects created by the factory are determined at run-time.
  • Builder. The builder pattern is used to create complex objects with constituent parts that must be created in the same order or using a specific algorithm. An external class controls the construction algorithm.
  • Factory Method. The factory pattern is used to replace class constructors, abstracting the process of object generation so that the type of the object instantiated can be determined at run-time.
  • Prototype. The prototype pattern is used to instantiate a new object by copying all of the properties of an existing object, creating an independent clone. This practise is particularly useful when the construction of a new object is inefficient.
  • Singleton. The singleton pattern ensures that only one object of a particular class is ever created. All further references to objects of the singleton class refer to the same underlying instance.

Structural Patterns

The second type of design pattern is the structural pattern. Structural patterns provide a manner to define relationships between classes or objects.
  • Adapter. The adapter pattern is used to provide a link between two otherwise incompatible types by wrapping the "adaptee" with a class that supports the interface required by the client.
  • Bridge. The bridge pattern is used to separate the abstract elements of a class from the implementation details, providing the means to replace the implementation details without modifying the abstraction.
  • Composite. The composite pattern is used to create hierarchical, recursive tree structures of related objects where any element of the structure may be accessed and utilised in a standard manner.
  • Decorator. The decorator pattern is used to extend or alter the functionality of objects at run-time by wrapping them in an object of a decorator class. This provides a flexible alternative to using inheritance to modify behaviour.
  • Facade. The facade pattern is used to define a simplified interface to a more complex subsystem.
  • Flyweight. The flyweight pattern is used to reduce the memory and resource usage for complex models containing many hundreds, thousands or hundreds of thousands of similar objects.
  • Proxy. The proxy pattern is used to provide a surrogate or placeholder object, which references an underlying object. The proxy provides the same public interface as the underlying subject class, adding a level of indirection by accepting requests from a client object and passing these to the real subject object as necessary.