Skip to main content

Home/ SoftwareEngineering/ Group items tagged DesignPatterns

Rss Feed Group items tagged

kuni katsuya

AnemicDomainModel - 0 views

  • AnemicDomainModel
  • Eric Evans
  • basic symptom of an Anemic Domain Model
  • ...40 more annotations...
  • The catch comes when you look at the
  • behavior
  • there is hardly any behavior on these objects, making them little more than bags of getters and setters
  • I was chatting with
    • kuni katsuya
       
      note, the 'i' here, is mr. MARTIN FOWLER!! and of course, eric evans hails from domain driven design fame
  • fundamental horror
  • it's so contrary to the basic idea of object-oriented design
  • combine
  • 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
  • should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities
  • logic that should be in a domain object is domain logic
  • validations
  • calculations
  • business rules
  • 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
  • void of behavior
  • service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
  • does not contain business rules or knowledge, but
  • only coordinates
  • tasks and delegates work to
  • collaborations of domain objects
  • in the next layer down
  • can have state that reflects the
  • progress of a task
  • for the user or the program
  • Domain Layer
  • Application Layer
  • Service Layer
  • Responsible for
  • representing concepts of the business
  • business rules
  • This layer is the heart of business software
    • kuni katsuya
       
      ... and has the *most value* to an organization investing in writing their own software infrastructure software (eg. user interface, orm, application server-related frameworks) or plumbing code should be treated as commodities where possible, unless, the business consciously decides that a custom, home-grown implementation is absolutely required for patenting or other differentiation reasons and/or that no existing off-the-shelf solution can be used but these cases should be rare! do not blindly fall for the not-invented-here syndrome
  • all the key logic lies in the domain layer
  • I don't know why this anti-pattern is so common
  • if they come from a
  • data background
    • kuni katsuya
       
      this is why during every sprint, i reiterate that the data model up approach to designing the system is OH SO WRONG but nobody listens
  • J2EE's Entity Beans
    • kuni katsuya
       
      damn baggage from  eons ago!!!
kuni katsuya

Lazy Loading Entities In Views Challenge--Reader's Question And Answer : Adam Bien's We... - 0 views

  • Lazy Loading Entities In Views
  • class User
  • Address
  • ...10 more annotations...
  • Friend
  • addresses are lazily loaded
  • detached mode already in the controller
  • eagerly loaded
  • It gets ugly pretty quickly
  • JXPath relations
  • Use Fetch Joins they are designed to prefetch lazy relations
  • Anti-Pattern
    • kuni katsuya
       
      DO NOT USE THE OPEN-SESSION-IN-VIEW *ANTI*-PATTERN
  • Use Stateful Session Beans
    • kuni katsuya
       
      do not penalty: death, or at least a public flogging
  • eager load the relations
    • kuni katsuya
       
      just don't hard-code this eager loading behavior by using jpa's FetchType.EAGER when annotating the entity beans if you do, you force all clients of said entity beans to *always* eager fetch everything, even if the client doesn't want/need the full depth/breadth of the object graph to eager load the relations when needed, try fetch joins (see item 5)
kuni katsuya

Open Session in View | Hibernate | JBoss Community - 0 views

  • Open Session in View
    • kuni katsuya
       
      do not do this!  this be an anti-pattern
kuni katsuya

Emulating "self types" using Java Generics to simplify fluent API implementation | Pass... - 0 views

  • Emulating "self types" using Java Generics to simplify fluent API implementation
  • this article shows how "self types" can be emulated in Java using Generics
  • The only thing wich differs is the return type, which is always the
  • ...16 more annotations...
  • class implementing the overridden isNotNull
  • necessary because otherwise it would not be possible to add methods to a call chain which are defined in the concrete assertion class, but not in the more generic superclass where isNotNull is implemented
  • <ELEMENT_TYPE>
  • ELEMENT_TYPE actual
  • ELEMENT_TYPE actual
  • GenericAssert<ELEMENT_TYPE>
  • SELF_TYPE
  • SELF_TYPE
  • SELF_TYPE self()
  • (SELF_TYPE) this
  • SELF_TYPE isNotNull()
  •  return self();
  • SELF_TYPE extends GenericAssert<SELF_TYPE, ELEMENT_TYPE>
  • only subclasses of GenericAssert are allowed as SELF_TYPE
  • sometimes called a
  • self-bounded generic
kuni katsuya

Chris Kelly: Using generics with a fluent API - 0 views

  • Using generics with a fluent API
  • fluent API with builders
  • fluent interface is implemented by using method chaining to relay the instruction context of a subsequent call
kuni katsuya

Unquiet Code | Using Generics To Build Fluent API's In Java - 0 views

  • Using Generics To Build Fluent API's In Java
  • extends BaseClass
  • super(ChildClass.class)
  • ...19 more annotations...
  • accomplish the same idea using generics
  • creates a bad sort of dependency where we need to update the base class every time we make a new derived class. Not good!
  • superclass requests information about the child, and the child provides it
  • (CHILD)
  • <CHILD extends BakedGood<CHILD>>
  • CHILD
  • (CHILD)
  • CHILD
  • abstract
  • extends BakedGood<Cake>
  • The type parameter is saying “the Child class must extend Base<Child>”, forcing the Child class to provide its own type to the type system
  • Now that we can return the derived class in our chained method calls we are free to alternately call methods from the base class and the derived class
  • All of the normal polymorphic abilities are retained (you can see that we’ve implemented the abstract bake() method required by BakedGood)
  • .bake()
  • .bake()
  • practical applications of fluent API’s can be found
  • this one
  • best article I was able to find on the topic was
  • here and here
kuni katsuya

Getting Started · UnquietCode/Flapi Wiki - 0 views

  • UnquietCode / Flapi
  • Getting Started
  • include a block chain
  • ...29 more annotations...
  • builds what is called a descriptor
  • blocks
  • methods
  • Blocks can be reused by using their name later in a addBlockReference(...) method
  • block contains methods
  • block can in turn nest other blocks
  • last()
  • Invocation Tracking
  • allowed invocations:
  • any()
  • exactly(int x)
  • atLeast(int x)
  • atMost(int x)
  • uses to build the Java code model and generate the classes and interfaces of a builder
  • between(int x, int y)
  • last(Class c)
  • Creating a Descriptor
  • Flapi.builder()
  • setPackage(String)
  • setStartingMethodName(String)
  • setDescriptorName(String)
  • setReturnType(Class)
  • enableCondensedClassNames()
  • addMethod(...)
  • startBlock(...)
  • addBlockChain(...)
  • addBlockReference(...)
  • Implementing the Helpers
  • Flapi creates only the interfaces for the helpers
kuni katsuya

UnquietCode/Flapi · GitHub - 0 views

  • UnquietCode / Flapi
  • Flapi is an API generator for Java, which generates chained API's for improved fluency in your code
  • UnquietCode / Flapi
  • ...3 more annotations...
  • Flapi is an API generator for Java, which generates chained API's for improved fluency in your code
  • code generation utility for creating fluent API in Java
  • stable release
kuni katsuya

Java EE Revisits Design Patterns: Asynchronous - Java Code Geeks - 0 views

  • Java EE Revisits Design Patterns: Asynchronous
  • @Asynchronous
  • tell the JavaEE container to run the called method in a separate thread asynchronously
  • ...5 more annotations...
  • @Asynchronous
  • @Asynchronous
  • Future<>
  • simple to use
  • as a return type and to receive a result asynchronously
1 - 14 of 14
Showing 20 items per page