Skip to main content

Home/ SoftwareEngineering/ Group items tagged OO

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Dependency injection discourages object-oriented programming? @ Blog of Adam Warski - 0 views

www.warski.org/...es-object-oriented-programming

java javaee6 CDI CdiDependencyInjection OO Object-Oriented procedural DI DependencyInjection

shared by kuni katsuya on 12 Dec 12 - No Cached
  • Dependency injection discourages object-oriented programming?
  • if you’re using DI, and you have an X entity, do you have an XService or XManager with lots of method where X is the first argument?
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      evidence of the anti-pattern of procedural design in a java ee6 cdi application
  • previous way is more procedural
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ie. ProductService.ship(Product,Customer)
  • ...12 more annotations...
  • service/manager is a set of procedures you can run, where the execution takes a product and a customer as arguments
  • better
  • OO approach
  • not saying that achieving the above is not possible with a DI framework
  • only that DI
  • encourages the ProductService approach
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      well, dependency injection, but moreover, the soa approach to service design tends to force otherwise intelligent software engineers into doing procedural design the services just end up being bags of method calls that implement any type of behavior, with the domain objects or entity beans being reduced to mere data structures with little responsibility or behavior beyond persistence. (which, in this anti-pattern, is typically mostly provided by the repository or dao class! ie. domain object crud)
  • it’s just easier
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ... if you just blindly follow the anti-pattern, of course  ;)
  • many benefits
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      with the procedural approach, you also cannot implement polymorphic behavior, for instance
  • builder
  • fluent interface
  • it’s not for small projects
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      fuckwhat? small or big matters not. if di is applied poorly, regardless of project size, it's an anti-pattern! disregard these comments!
  • problems with DI frameworks:
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      not sure i agree with these points, but will refuse in a later sticky note
kuni katsuya

AnemicDomainModel - 0 views

www.martinfowler.com/...AnemicDomainModel.html

java javaee6 anti-patterns DesignPatterns

shared by kuni katsuya on 12 Dec 12 - Cached
  • 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
      kuni katsuya on 12 Dec 12
       
      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
      kuni katsuya on 12 Dec 12
       
      ... 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
      kuni katsuya on 12 Dec 12
       
      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
      kuni katsuya on 12 Dec 12
       
      damn baggage from  eons ago!!!
kuni katsuya

15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfie... - 0 views

www.adam-bien.com/...10_tips_on_jpa_rich

jpa best practices DomainModeling

shared by kuni katsuya on 20 Jul 12 - No Cached
  • [For Greenfields]
  • Try to identify concepts and abstractions from the target domain. Use them as candidates for entities.
  • Do not obfuscate them with additional technical naming conventions like XYZEntity or "BOs".
  • ...10 more annotations...
  • Write unit tests
  • without involving the EntityManager
  • - Thinking In Objects
  • JPA Rich Domain Modelling
    • kuni katsuya
      kuni katsuya on 12 Oct 12
       
      strategy to use when less or unconstrained by legacy db schema baggage. ie. the *proper* and *ideal* way to model domain classes... using oo, not dumb structs!  :)
  • Build objects, not structs
  • Think about builders
  • Let the tool (JPA-provider) generate the DDL
    • kuni katsuya
      kuni katsuya on 12 Oct 12
       
      generated ddl can be optimized by hand if required
    • kuni katsuya
      kuni katsuya on 12 Oct 12
       
      eg. see step 12 below
  • Provide a lean facade/service layer
  • only contain crosscutting concerns
1 - 3 of 3
Showing 20▼ items per page