Skip to main content

Home/ SoftwareEngineering/ Group items tagged Object-Oriented

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

Anemic domain model - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/...Anemic_Domain_Model

patterns AnemicDomainModel

shared by kuni katsuya on 12 Dec 12 - Cached
  • objects containing only data
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ie. dumb data structures with little or no behavior
  • objects containing only code
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ie. classes that are just containers for methods that implement the behavior part of the domain objects (aka the procedures)
  • Martin Fowler, who considers the practice an anti-pattern
  • ...14 more annotations...
  • Benefit
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      none
  • Liabilities
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      lots
  • Logic cannot be implemented in a truly object-oriented way
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      for example, polymorphic behavior
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Violation of the encapsulation
  • domain model's objects cannot guarantee their correctness
  • validation and mutation logic is placed somewhere outside
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      instead of, say, attaching validation 'behavior' directly on, but still decoupled from domain classes themselves (eg. validation rule annotations on jpa entity beans)
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Necessitates a service layer when sharing domain logic across differing consumers of an object model.
  • Makes a model less expressive and harder to understand.
  • Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
kuni katsuya

Chapter 12. ActionScript 3 Reflection API - 0 views

www.graniteds.org/...graniteds.reflection.html

graniteds ActionScript3 reflection api

shared by kuni katsuya on 14 Sep 12 - No Cached
  •  ActionScript 3 Reflection API
  • describeType
  • method returns
  • ...5 more annotations...
  • XML data
    • kuni katsuya
      kuni katsuya on 14 Sep 12
       
      why gawd, whhhhhhhhhyyy...
  • describing its parameter object and is therefore not type-safe and its use is subject to many syntax errors.
  • GraniteDS provides a Java-like reflection API that encapsulates describeType calls and offers a type-safe, object-oriented, set of reflection classes and methods
  • caches its results for better performance
  • supports advanced features such as ApplicationDomain and namespaces
kuni katsuya

Lean service architectures with Java EE 6 - JavaWorld - 0 views

www.javaworld.com/...-04-lean-soa-with-javaee6.html

javaee6 lean service architecture

shared by kuni katsuya on 30 Jul 12 - No Cached
  • key ingredients of a service-oriented component: Facade: Provides simplified, centralized access to the component and decouples the client from the concrete services. It is the network and transaction boundary. Service: The actual implementation of business logic. Domain structure: This is a structure rather than an object. It implements the component's persistence and exposes all of its state to the services, without encapsulation.
  • This convention not only standardizes the structure and improves maintainability, but also allows automatic dependency validation with frameworks like JDepend, Checkstyle,  Dependometer, SonarJ, or XRadar. You can even perform the validation at build time. If you do, the continuous build would break on violation of defined dependencies. The rules are clearly defined with strict layering: a facade may access a service, and the service a domain object, but not vice versa
1 - 6 of 6
Showing 20▼ items per page