Skip to main content

Home/ SoftwareEngineering/ Group items tagged anti-patterns

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

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

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

www.adam-bien.com/...lazy_loading_entities_in_views

java javaee6 anti-patterns DesignPatterns lazy-loading EagerFetch JPA

shared by kuni katsuya on 12 Dec 12 - No Cached
  • 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
      kuni katsuya on 12 Dec 12
       
      DO NOT USE THE OPEN-SESSION-IN-VIEW *ANTI*-PATTERN
  • Use Stateful Session Beans
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      do not penalty: death, or at least a public flogging
  • eager load the relations
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      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

Illegitimus Non Interruptus - Published Patterns - 0 views

sites.google.com/...illigitimus-non-interruptus

scrum agile anti-patterns

shared by kuni katsuya on 18 Oct 12 - No Cached
  • Illegitimus Non Interruptus
  • dilemma arising from the situation in which multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource even when it is clear that it is not in anyone's long-term interest for this to happen
  • allot time for interrupts and
  • ...1 more annotation...
  • do not allow the time to be exceeded
kuni katsuya

Chris Kelly: Programming Retrospective - 0 views

www.chrisjasonkelly.com/...programming-retrospective.html

BestPractices anti-patterns

shared by kuni katsuya on 27 Mar 13 - No Cached
  • Programming Retrospective
  • anti-patterns
  • Final classes without interfaces
  • ...18 more annotations...
  • Lack of Defensive Programming
  • Exposure of super state to child classes
  • Printing out error messages to console instead of logging
  • Classes with unclear focus
  • Unwieldy or unneeded comments
  • Use of exceptions to control program flow
  • Throwing of ambiguous exceptions
  • Use parameter objects instead of long method signatures
  • Never Duplicate Code
  • copy and paste job
  • Return nulls from methods
  • Null Object pattern
  • onus is then on the callee to check the result is not null before using the result
  • client then doesn't have to check for nulls
  • empty map should be returned
  • instead of returning null, an
  • Refactoring: Improving the Design of Existing Code
  •  Working Effectively with Legacy Code
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

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

community.jboss.org/...OpenSessionInView

java javaee6 anti-patterns DesignPatterns lazy-loading EagerFetch JPA

shared by kuni katsuya on 12 Dec 12 - No Cached
  • Open Session in View
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      do not do this!  this be an anti-pattern
kuni katsuya

WYTIWYR : What You Test Is What You Run « Antonio's Blog - 0 views

antoniogoncalves.org/...-what-you-test-is-what-you-run

javaee6 UnitTest IntegrationTest arquillian

shared by kuni katsuya on 03 Oct 12 - No Cached
  • kuni katsuya on 03 Oct 12
     
    " Don't mock types you don't own TDD: Only mock types you own Test Smell: Everything is mocked Testing Anti-Patterns: How to Fail With 100% Test Coverage TDD: Only mock types you own Test Smell: Everything is mocked Arquillian"
kuni katsuya

Interface naming in Java - Stack Overflow - 0 views

stackoverflow.com/...interface-naming-in-java

java Interface NamingConvention BestPractices

shared by kuni katsuya on 19 Dec 12 - No Cached
  • interfaces define
  • capabilities
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      this is one sensible interface naming option, if the interface encapsulates a cohesive set of behaviors and yes, compared to blindly following the meaningless I+ convention, it requires some thought, but thinking of an appropriate name also forces you to (re)consider the interface's primary responsibility and how it fits into the overall design imho, a class diagram for a domain model should be almost fluently readable english
  • not types
  • ...16 more annotations...
  • Comparable
  • Runnable
  • Serializable
  • Sometimes an Adjective doesn't make sense, but I'd still generally be using interfaces to model behavior, actions, capabilities, properties, etc,... not types.
  • Also, If you were really only going to make one User and call it User then what's the point of also having an IUser interface?
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      another anti-pattern... blindly create an interface for every class, even if there's only one implementation!! arrgghhhh! consider introducing an interface when there are 2-3 well-distinguished, concrete implementations required
  • if you are going to have a few different types of users that need to implement a common interface, what does appending an "I" to the interface save you in choosing names of the implementations?
  • prefer not to use a prefix on interfaces:
  • hurts readability.
  • interfaces names should be as short and pleasant as possible
  • Implementing classes should be uglier to discourage their use.
    • kuni katsuya
      kuni katsuya on 19 Dec 12
       
      but they don't *have* to be ugly, like BlahImpl for specialized implementations, use descriptive adjective-noun combos
  • Code using an instance of some type should never, ever care if that type is an interface or a class
  • exposing such a detail in the name of the type is pointless and harmful to understanding
  • several reasons Java does not generally use the IUser convention.
  • should not have to know whether the client is using an interface or an implementation class
  • Java naming convention prefers longer names with actual meanings to Hungarian-style prefixes
  • Interface naming in Java [closed]
  • kuni katsuya on 19 Dec 12
     
    "have interfaces define"
kuni katsuya

Exceptions Are Objects : Adam Bien's Weblog - 0 views

www.adam-bien.com/...exceptions_are_objects

AdamBien java package Exceptions BestPractices anti-patterns

shared by kuni katsuya on 28 Apr 13 - No Cached
kuni katsuya

Technical debt; is it only technical? | Xebia Blog - 0 views

blog.xebia.com/...ical-debt-is-it-only-technical

agile TechnicalDebt anti-patterns

shared by kuni katsuya on 04 Nov 12 - No Cached
  • Technical debt; is it only technical?
  • “TechnicalDebtQuadrant“
  • distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices
  • ...10 more annotations...
  • not only code related
  • Code form
  • Architectural form
  • Testing form
  • Deployment form
  • Documentation form
  • Functional form
  • Project form
  • Organizational form
  • Whether technical dept is categorized as deliberate, inadvertent, reckless or careful, it is good to be aware of this and see how you want to cope with it strategically.
kuni katsuya

Collaboration Best Practices - 3 Reasons Interruptions are Hurting Your Team's Producti... - 0 views

blogs.atlassian.com/...nterruptions-hurt-productivity

agile productivity anti-patterns

shared by kuni katsuya on 01 Nov 12 - No Cached
  • Interruptions Hurt Your Team’s Productivity
  • Productivity is futile in the face of constant interruptions
  • work is scattered through shared network drives, hard drives, and email
    • kuni katsuya
      kuni katsuya on 01 Nov 12
       
      or sharepoint, confluence, jira, word docs, pdf docs, spreadsheets, walled post-it notes, emails... not universally or easily searchable. arghhh...
  • ...17 more annotations...
  • Charging towards a common goal is difficult when:
  • center on meetings alone.
  • When disorganization and uncertainty is the norm, clarification and re-clarification is needed to regularly keep a team focused and working together
  •  waste A LOT of your time
  • Information isn’t located in a centralized place so it isn’t easily accessible to everyone.
  • It’s just easier to ask someone else because they are a Subject Matter Expert (SME). Both.
  • 2. Interruptions encourage multi-tasking, which is bad
  • 1. Most interruptions are trivial and could be avoided
  • it takes most people 16 minutes to refocus after sending an email while doing other work
    • kuni katsuya
      kuni katsuya on 01 Nov 12
       
      it takes most software engineers *at least* 20-30 minutes to get back into 'the zone' following an unrelated distraction
  • No wonder people like to work from home!
  • To perform at your productive best, you need your best focus, something that’s unachievable when you’re constantly interrupted
  • 3. Recovering from interruptions takes longer than you think
  • Between email, meetings, and interruptions (both active and passive),
  • there’s hardly time to get any work done while you’re actually at work.
  • Pro-Tip: Only turn on email and instant message when you need to use them
    • kuni katsuya
      kuni katsuya on 01 Nov 12
       
      ie. never?  ;) though then, you end up with 5,932 unread emails in your inbox and 113 angry co-workers!
  • To combat such interruption, check these tools 3 times a day – when you first get into the office in the morning, around lunch, and before going home for the night – and turn them off otherwise.
  • reduce the rate at which interruptions occur
kuni katsuya

When to avoid CQRS - 0 views

www.udidahan.com/...when-to-avoid-cqrs

cqrs anti-patterns

shared by kuni katsuya on 16 May 12 - No Cached
  • When to avoid CQRS
1 - 17 of 17
Showing 20▼ items per page