Group items tagged

@Size(min = 3, max = 80)

@NotNull

LastName

extend AbstractBuilder

must implement the buildInternal() method:

Builder extends AbstractBuilder<Customer>

@Override protected Customer buildInternal()

Implementing the Builder Pattern using the Bean Validation API

variation of the Builder design pattern for instantiating objects with multiple optional attributes.

this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)

or providing setter methods for the optional attributes

encourages the ProductService approach

it’s not for small projects

William Drai

Honestly I don't see any value in switching to CDI if it is

please not this Dao/Template mess

Gavin King

to reproduce the same awful patterns

please not this Dao/Template mess

Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.

This is exactly the kind of

It gives people a

and somehow shuts down their brains so they

It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.

but that might be too high-level for your taste. Their are other, less-abstract options.

exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."

Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.

Gavin King

there are a bunch of people

They don't understand, or see the value of, using managed objects to represent their persistent data.

Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?

@Asynchronous

@Asynchronous

simple to use

as a return type and to receive a result asynchronously

The catch comes when you look at the

there is hardly any behavior on these objects, making them little more than bags of getters and setters

I was chatting with

fundamental horror

it's so contrary to the basic idea of object-oriented design

data and process together

procedural style design

completely miss the point of what object-oriented design is all about

It's also worth emphasizing that putting behavior into the domain objects

One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer

this isn't an argument to make the domain model

service layer advocates use a service layer in conjunction with a behaviorally rich domain model.

does not contain business rules or knowledge, but

data background

J2EE's Entity Beans

names

Do not move or rename the package of an

Avoid deep inheritance hierarchies

Do not use public nested types

Do not declare public or protected fields

Do not expose implementation inheritance to the client

Anti-Pattern

Use Stateful Session Beans

eager load the relations

copy and paste job

instead of returning null, an

EJB MDG Technology for Enterprise Java Beans allows the user to model EJB entities and EJB sessions, complete with UML profiles for modeling EJB, EJB patterns and Code Management. (requires Enterprise Architect 4.1 or later)

ICONIX AGILE DDT ICONIX Agile Developer - Design-Driven Testing (DDT) streamlines the ICONIX modeling process, providing: Convenient modeling of robustness diagrams Automatic generation of sequence diagram structures from robustness diagrams Transformation of robustness control elements to test diagrams Transformation of sequence diagram elements to test diagrams Transformation of requirement diagrams to test diagrams Transformation between test cases and test classes. (JUnit & NUnit) Built-in model validation rules for ICONIX robustness diagrams (requires Enterprise Architect 7.5 or later)

Testing MDG Technology for Testing helps users to rapidly model a wide range of testing procedures including component testing, SUT, Test Cases and more. (requires Enterprise Architect 4.1 or later)

Instructions for loading an MDG Technology EXE file: Download and run the .exe file to install the MDG technology. Open Enterprise Architect. Select from the Main Menu Add-Ins | XYZ Technology | Load.

Built-in MDG Technologies: Most of the MDG Technologies provided by Sparx Systems are built into Enterprise Architect directly. Depending on your edition of Enterprise Architect, some or all of the following MDG Technologies will be available:

Gang of Four Patterns

Mind Mapping

Web Modeling

Data Flow (DFD)

Entity-Relationship (ERD)

Business Rule Model

BPMN™

Some people are talkative and tend to wander off into Story Telling

Some people want to engage in Problem Solving immediately

Other topics of discussion (e.g., design discussions, gossip, etc.) should be deferred until after the meeting.

questions should be reversed in order to emphasise the correct order of importance:

Any impediments in your way? What are you working on today? What have you finished since yesterday?

A long, droning meeting is a

to start the day

a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality

can manipulate a single instance of the object just as you would manipulate a group of them

allows additional behavior to be added to an existing class by wrapping the original class and duplicating its interface and then delegating to the original

AOP proxy is like a dynamic decorator