Skip to main content

Home/ SoftwareEngineering/ Group items tagged constructor

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Seam Framework - Why is the constructor invoked twice when a normal scoped bean is crea... - 0 views

sfwk.org/...WhenANormalScopedBeanIsCreated

cdi constructor invocation @PostConstruct

shared by kuni katsuya on 12 Jul 12 - No Cached
  • Why is the constructor invoked twice when a normal scoped bean is created?
  • What you see is the instantiation of two objects: one is the actual bean instance, the other one is the proxy. Both likely invoke the default constructor.
  • That's why it's generally considered a bad idea to do initialization in class construction code. Instead, when using managed beans (objects managed by the EE container) to perform initialisation in a @PostConstruct or @Inject annotated method.
  • kuni katsuya on 12 Jul 12
     
    Why is the constructor invoked twice when a normal scoped bean is created?
kuni katsuya

Item 2: Consider a builder when faced with many constructor parameters | Creating and D... - 1 views

www.informit.com/...article.aspx

EfffectiveJava JoshuaBloch BuilderPattern

shared by kuni katsuya on 12 Oct 12 - No Cached
  • Item 2: Consider a builder when faced with many constructor parameters
  • kuni katsuya on 12 Oct 12
     
    "Item 2: Consider a builder when faced with many constructor parameters"
kuni katsuya

A proper way for JPA entities instantiation « Paul Szulc's Blog - 0 views

paulszulc.wordpress.com/...for-jpa-entities-instantiation

database jpa EntityBeans BuilderPattern

shared by kuni katsuya on 03 Oct 12 - No Cached
  • A proper way for JPA entities instantiation
  • creating the entities I would like to focus in this post
  • JPA2.0 entities
  • ...31 more annotations...
  • UserService
  • UserDao
  • FacebookWS
  • User u
  • UserService uses UserDAO and FacebookWS
  • but don’t know how those dependencies are instantiated
  • And you shouldn’t really care, all that is important is that UserService depends on dao and webservice object.
  • BDD template given-when-then) tests are easy to read
  • @Entity
  • public class User
  • calling new User(“someName”,”somePassowrd”, “someOtherName”, “someOtherPassword”) becomes hardly readable and maintainable
  • code duplication
  • Maintaining this code would turn into a nightmare in no time
  • running the code above will throw an exception by the JPA provider,
  • since not-nullable password field was never set.
  • Joshua Blooch gives fine example of builder pattern.
  • Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
  • Coffee
  • public static class Builder
  • Builder(CoffeeType type, int cupSize)
  • Builder withMilk()
  • Coffee build()
  • Coffee(this)
  • private Coffee(Builder builder)
  • Coffee coffee = new Coffee.Builder(CoffeeType.Expresso, 3).withMilk().build();2}
  • especially if most of those parameters are optional.
  • For all entity attributes I create private fields
  • those that are obligatory become parameters for the public constructor
  • parameter-less constructor, I create one, but I give him
  • protected access level
  • protected
kuni katsuya

Implementing the Builder Pattern using the Bean Validation API - Musings of a Programmi... - 0 views

musingsofaprogrammingaddict.blogspot.ca/...uilder-pattern-using-bean.html

database jpa EntityBeans BuilderPattern BeanValidation

shared by kuni katsuya on 03 Oct 12 - No Cached
  • invariants
  • customer's last name must not be null
  • must be between 3 and 80 characters long
  • ...23 more annotations...
  • @Size(min = 3, max = 80)
  • @NotNull
  • LastName
  • inner class Builder is in charge of creating Customer instances
  • mandatory fields – either primitive (e.g. id) or annotated with @NotNull (e.g. lastName) – are part of the builder's constructor
  • all optional fields setter methods on the builder are provided
  • newly created Customer instance is validated using the Validator#validate() method
  • impossible to retrieve an invalid Customer instance
  • extract the validation routine into a base class:
  • abstract class AbstractBuilder<T>
  • T build() throws ConstraintViolationException
  • protected abstract T buildInternal();
  • private static Validator validator
  • Concrete builder classes have to
  • 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
  • (require objects to be mutable, can leave objects in inconsistent state)
kuni katsuya

Chapter 14. Tide client framework - 0 views

www.graniteds.org/...graniteds.tideframework.html

graniteds tide context

shared by kuni katsuya on 23 Apr 13 - No Cached
  • 14.3. Contexts and Components
  • core concepts
  • component
  • ...14 more annotations...
  • context
  • unique context that exists during the whole lifetime of the Flex application. It can be compared to to the server-side session
  • Components
  • two main kinds of contexts:
  • stateful objects that can be of any ActionScript 3 class with a default constructor
  • global context
  • temporary contexts that can be created and destroyed at any time during the lifetime of the application
  • conversation contexts
  • conversation context always has an identifier
  • usually tied to a particular use case in the application
  • three available scopes:
  • session scope
  • conversation scope
  • event scope
kuni katsuya

Stephen Colebourne's blog: Javadoc coding standards - 0 views

blog.joda.org/...javadoc-coding-standards.html

java javadoc BestPractices documentation design communication

shared by kuni katsuya on 13 Dec 12 - No Cached
  • Javadoc coding standards
  • explain some of the rationale for some of my choices
  • this is more about the formatting of Javadoc, than the content of Javadoc
  • ...63 more annotations...
  • Each of the guidelines below consists of a short description of the rule and an explanation
  • Write Javadoc to be read as source code
  • Making Javadoc readable as source code
  • Public and protected
  • All public and protected methods should be fully defined with Javadoc
  • Package and private methods do not have to be, but may
  • benefit from it.
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      think of it as internal design documentation when you revisit this code 8 months from now: - based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not - when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
  • If a method is overridden in a subclass, Javadoc should only be present if it says something distinct to the original definition of the method
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ie. don't just copy-paste the javadoc from the superclass. that's mindless and pointless monkey work
  • Use the standard style for the Javadoc comment
  • Do not use '**/' at the end of the Javadoc
  • Use simple HTML tags, not valid XHTML
  • XHTML adds many extra tags that make the Javadoc harder to read as source code
  • Use a single <p> tag between paragraphs
  • Place a single <p> tag on the blank line between paragraphs:
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
  • Use a single <li> tag for items in a list
  • place a single <li> tag at the start of the line and no closing tag
  • Define a punchy first sentence
  • it has the responsibility of summing up the method or class to readers scanning the class or package
  • the first sentence should be
  • clear and punchy, and generally short
  • use the third person form at the start
  • Avoid the second person form, such as "Get the foo"
  • Use "this" to refer to an instance of the class
  • When referring to an instance of the class being documented, use "this" to reference it.
  • Aim for short single line sentences
  • Wherever possible, make Javadoc sentences fit on a single line
  • favouring between 80 and 120 characters
  • Use @link and @code wisely
  • @link feature creates a visible hyperlink in generated Javadoc to the target
  • @code feature provides a section of fixed-width font, ideal for references to methods and class names
  • Only use @link on the first reference to a specific class or method
  • Use @code for subsequent references.
  • This avoids excessive hyperlinks cluttering up the Javadoc
  • Never use @link in the first sentence
  • Always use @code in the first sentence if necessary
  • Adding a hyperlink in that first sentence makes the higher level documentation more confusing
  • Do not use @code for null, true or false
  • Adding @code for every occurrence is a burden to both the reader and writer of the Javadoc and adds no real value.
  • Use @param, @return and @throws
  • @param entries should be specified in the same order as the parameters
  • @return should be after the @param entries
  • followed by @throws.
  • Use @param for generics
  • correct approach is an @param tag with the parameter name of <T> where T is the type parameter name.
  • Use one blank line before @param
  • This aids readability in source code.
  • Treat @param and @return as a phrase
  • They should start with a lower case letter, typically using the word "the". They should not end with a dot. This aids readability in source code and when generated.
  • treated as phrases rather than complete sentences
  • Treat @throws as an if clause
  • phrase describing the condition
  • Define null-handling for all parameters and return types
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling also, there are cleaner ways to design around this type of old school null handling hackage
  • methods should define their null-tolerance in the @param or @return
  • standard forms expressing this
  • "not null"
  • "may be null"
  • "null treated as xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this might also stink of poor design ymmv
  • In general the behaviour of the passed in null should be defined
  • Specifications require implementation notes
  • Avoid @author
  • source control system is in a much better position to record authors
  • This wastes everyone's time and decreases the overall value of the documentation. When you have nothing useful to say, say nothing!
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      likewise with javadoc on things like default constructors /**  * Creates an instance of SomeClass  */ public SomeClass() {} is equally useless and unnecessarily clutters up the source code
kuni katsuya

Release Notes - GraniteDS - Version 3.0.0.M1 - HTML format - Granite Data Services - 0 views

www.graniteds.org/...ReleaseNote.jspa

java javaee javaee6 graniteds GraniteDS3 ReleaseNotes

shared by kuni katsuya on 13 Dec 12 - No Cached
  • Release Notes - GraniteDS - Version 3.0.0.M1
  • GAS3 does not handle Java generics with abstract class implementations
  • Generated as3 has compilation warnings: missing constructor
  • ...1 more annotation...
  • Rename flex-filter to server-filter and @FlexFilter to @ServerFilter
kuni katsuya

Google Groups - 0 views

groups.google.com/forum

graniteds flex java type conversion

shared by kuni katsuya on 01 Nov 12 - No Cached
  • new ArrayCollection();
  • new ArrayCollection();
  • new ArrayCollection();
  • ...6 more annotations...
  • new ArrayCollection();
  • new ArrayCollection();
  • You cannot serialize ListCollectionView instances directly. Use ArrayCollection instead in your constructor :
  • new ArrayCollection();
  • ListCollectionView to List<E> conversion
  • send a ListCollectionView object to a java method that accepts a java.util.List, I get a NoSuchMethodException.
kuni katsuya

Chapter 14. Tide client framework - 0 views

www.graniteds.org/...graniteds.tideframework.html

graniteds Tide framework Flex

shared by kuni katsuya on 12 Sep 12 - No Cached
  • Tide client framework
  • framework features
  • Dependency Injection
  • ...18 more annotations...
  • Event Bus
  • Contextual Components and Conversations
  • Contexts and Components
  • two main kinds of contexts:
  • global context
  • unique context that exists during the whole lifetime of the Flex application
  • compared to to the server-side session
  • conversation contexts
  • temporary contexts that can be created and destroyed at any time during the lifetime of the application
  • can exist simultaneously
  • isolated from each other
  • Components are stateful objects that can be of any ActionScript 3 class with a default constructor
  • have a name
  • A context is mostly a container for component instances
  • three available scopes:
  • session scope
  • conversation scope
  • event scope
  • kuni katsuya on 12 Sep 12
     
    "Tide client framework"
kuni katsuya

Pro JPA 2: Mastering the Java™ Persistence API > Advanced Topics > SQL Querie... - 0 views

my.safaribooksonline.com/...sql_queries

jpa SqlQueries NativeQueries

shared by kuni katsuya on 25 Jul 12 - No Cached
  • queries are also known as native queries
  • SQL Queries
  • reasons why a developer using JP QL might want to integrate SQL queries into their application
  • ...32 more annotations...
  • JPA 2.0, still contains only a subset of the features supported by many database vendors
  • features not supported in JP QL.
  • performance required by an application is to replace the JP QL query with a hand-optimized SQL version. This may be a simple restructuring of the query that the persistence provider was generating, or it may be a vendor-specific version that leverages query hints and features specific to a particular database.
  • recommend avoiding SQL initially if possible and then introducing it only when necessary
  • benefits of SQL query support is that it uses the same Query interface used for JP QL queries. With some small exceptions that will be described later, all the Query interface operations discussed in previous chapters apply equally to both JP QL and SQL queries.
  • keep application code consistent because it needs to concern itself only with the EntityManager and Query interfaces.
  • An unfortunate result of adding the TypedQuery interface in JPA 2.0 is that the createNativeQuery() method was already defined in JPA 1.0 to accept a SQL string and a result class and return an untyped Query interface
  • consequence is that when the createNativeQuery() method is called with a result class argument one might mistakenly think it will produce a TypedQuery, like createQuery() and createNamedQuery() do when a result class is passed in.
  • @NamedNativeQuery
  • resultClass=Employee.class
  • The fact that the named query was defined using SQL instead of JP QL is not important to the caller
  • SQL Result Set Mapping
  • JPA provides SQL result set mappings to handle these scenarios
  • A SQL result set mapping is defined using the @SqlResultSetMapping annotation. It may be placed on an entity class and consists of a name (unique within the persistence unit) and one or more entity and column mappings.
  • entities=@EntityResult(entityClass=Employee.class)
  • @SqlResultSetMapping
  • Multiple Result Mappings
  • A query may return more than one entity at a time
  • The SQL result set mapping to return both the Employee and Address entities out of this query
  • emp_id, name, salary, manager_id, dept_id
  • address_id, id, street, city, state, zip
  • order in which the entities are listed is not important
  • ntities={@EntityResult(entityClass=Employee.class), @EntityResult(entityClass=Address.class)}
  • expected result type and therefore received an instance of TypedQuery that is bound to the expected type. By qualifying the result type in this way, the getResultList() and getSingleResult() methods return the correct types without the need for casting.
  • Defining a Class for Use in a Constructor Expression
  • public EmpMenu(String employeeName, String departmentName)
  • List<EmpMenu>
  • NEW example.EmpMenu(" + "e.name, e.department.name)
  • EmpMenu.class
  • createNamedQuery() can return a TypedQuery whereas the createNativeQuery() method returns an untyped Query
  • List<Employee>
  • createNamedQuery("orgStructureReportingTo", Employee.class)
kuni katsuya

Overview of Interceptors - The Java EE 6 Tutorial - 0 views

docs.oracle.com/...gkigq.html

javaee6 interceptors tutorial overview

shared by kuni katsuya on 16 May 12 - No Cached
  • Overview of Interceptors
  • allow developers to invoke interceptor methods in conjunction with method invocations or lifecycle events on an associated target class
  • logging, auditing, or profiling
  • ...7 more annotations...
  • Interceptor classes and methods are defined using metadata annotations, or in the deployment descriptor of the application containing the interceptors and target classes
  • Interceptor Metadata Annotations
  • AroundInvoke
  • AroundTimeout
  • PostConstruct
  • PreDestroy
  • Interceptor classes must have a public, no-argument constructor
1 - 13 of 13
Showing 20▼ items per page