Skip to main content

Home/ SoftwareEngineering/ Group items tagged pattern

Rss Feed Group items tagged

kuni katsuya

UML Class Diagrams Examples - Abstract Factory Design Pattern, Library Management, Onli... - 0 views

    • kuni katsuya
       
      note lack of dependency lines between a class and the types of it's attributes (eg. no dependency line drawn between Order->OrderStatus or WebUser->UserState. these are obvious and would just clutter the diagram)
kuni katsuya

Interface naming in Java - Stack Overflow - 0 views

  • interfaces define
  • capabilities
    • kuni katsuya
       
      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
       
      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
       
      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]
  •  
    "have interfaces define"
kuni katsuya

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

kuni katsuya

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

  • 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

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

  • 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

It's Not Just Standing Up: Patterns for Daily Standup Meetings - 0 views

  • stand-up meeting should
  • give energy
  • not take it
  • ...11 more annotations...
  • The purpose is not to meet... it is to improve.
  • Some people are talkative and tend to wander off into Story Telling
  • Some people want to engage in Problem Solving immediately
  • Other topics of discussion (e.g., design discussions, gossip, etc.) should be deferred until after the meeting.
  • questions should be reversed in order to emphasise the correct order of importance:
  • Any impediments in your way? What are you working on today? What have you finished since yesterday?
  • Fifteen Minutes or Less
  • A long, droning meeting is a
  • horrible, energy-draining way
  • to start the day
  • Signal the End
  •  
    "stand-up meeting should"
kuni katsuya

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

  • 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
       
      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
       
      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
       
      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

Composite pattern - Wikipedia, the free encyclopedia - 0 views

  • Motivation
  • tree-structured data
  • interface that allows treating complex and primitive objects uniformly
  • ...3 more annotations...
  • a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality
  • can manipulate a single instance of the object just as you would manipulate a group of them
  • when clients should ignore the difference between compositions of objects and individual objects
  •  
    Motivation
kuni katsuya

Part 3 of dependency injection in Java EE 6 - 1 views

  • powerful way of formalizing the recurring bean roles that often arise as a result of application architectural patterns
kuni katsuya

Chapter 10. Integration with CDI - 0 views

  • Chapter 10. Integration with CDI
  • GraniteDS provides out-of-the-box integration with CDI via the Tide API
  • GraniteDS also integrates with container security for authentication and role-based authorization
  • ...37 more annotations...
  • always have to include this library in either WEB-INF/lib
  • support for CDI is included in the library granite-cdi.jar
  • 10.1. Configuration with Servlet 3 On Servlet 3 compliant containers, GraniteDS can use the new APIs to automatically register its own servlets and filters and thus does not need any particular configuration in web.xml. This automatic setup is triggered when GraniteDS finds a class annotated with @FlexFilter in one of the application archives:
  • @FlexFilter(configProvider=CDIConfigProvider.class) public class GraniteConfig { }  
  • list of annotation names that enable remote access to CDI beans
  • ConfigProvider
  • override these values by setting them in the annotation properties
  • tide=true,         type="cdi",         factoryClass=CDIServiceFactory.class,         tideInterfaces={Identity.class}
  • @FlexFilter declaration will setup an AMF processor for the specified url pattern
  • tideAnnotations
  • defines suitable default values
  • @TideEnabled
  • @RemoteDestination
  • always declared by default
  • tideInterfaces
  • tideRoles
  • exceptionConverters
  • amf3MessageInterceptor
  • 10.3.2. Typesafe Remoting with Dependency Injection
  • It is possible to benefit from even more type safety by using the annotation [Inject] instead of In. When using this annotation, the full class name is used to find the target bean in the CDI context instead of the bean name.
  • Security
  • integration between the client RemoteObject credentials and the server-side container security
  • client-side component named
  • identity
  • API to define runtime authorization checks on the Flex UI
  • login()
  • logout()
  • login(username, password, loginResult, loginFault)
  • logout()
  • bindable property
  • represents the current authentication state
  • loggedIn
  • identity.loggedIn 
  • integrated with server-side role-based security
  • identity.hasRole('admin')
  • clear the security cache manually with
  • identity.clearSecurityCache()
kuni katsuya

How evil are Data Transfer Objects (DTOs)? : Adam Bien's Weblog - 0 views

  • How evil are Data Transfer Objects (DTOs)?
  • In certain situations, they become the necessary tool or workaround to solve a particular problem
  • Some relations are probably going to be collapsed, attributes renamed and even types changed
  • ...1 more annotation...
  • It is perfect valid to introduce a dedicated DTO to adapt an incompatible domain layer
kuni katsuya

How To Deal With Interfaces In Java EE 6 (or no more Impl) : Adam Bien's Weblog - 0 views

  • How To Deal With Interfaces In Java EE 6 (or no more Impl)
  • In Java EE 6 interfaces became absolutely optional. Neither in EJB 3.1, nor CDI / JSR-330 you need interfaces. You can inject classes directly. They will be still proxied, so all aspects like persistence, transactions, interceptors, decorators are still available. So you are no more forced to implement interfaces by the container
  • used for: Strategy Pattern: there are already several implementations of an algorithm or concept Layering: there is a clear need to hide e.g. an ugly implementation of a legacy framework API (not very common): you have to expose a API, which gets implemented by SPI (e.g. JDBC)
  • ...4 more annotations...
  • If you introduce interfaces intentionally - and not as a general rule, you will considerably reduce the number of files. Your code becomes easier to understand and so maintain
  • Even for decoupling purposes, interfaces are no more needed
  • "Contract First", "Coding To Interfaces" or "Decoupling"
  • is not a reason to introduce an interface for everything
kuni katsuya

In Relation To...  Bean Validation for Flex developers - 0 views

  • Bean Validation for Flex developers
  • GraniteDS have added support for Bean Validation into their project and hence Bean Validation is usable by all Flex users
  • Because they do not run on the JVM, they basically have reimplemented the full specification in Flex: you can annotate your ActionScript3 objects with constraints: it supports all the standard constraints and you can write your own constraints you can execute the validation logic and retrieve the error report you can make use of most of the feature including advanced ones like groups, group sequence etc
  • ...3 more annotations...
  • for GraniteDS users keeping their Java domain model and ActionScript3 domain model in sync via Gas3, the constraints are kept in sync
  • a couple of gotchas to be aware of
  • the constraint implementation is in the same class as the constraint declaration (not a problem in a dynamic language) @Pattern has a sightly different semantic because the regexp engine in Flex is a bit different. instead of the features provided by ConstraintValidatorContext, you can define a properties attribute in your constraints to make it belong to several sub-properties. not as flexible but good enough in many cases.
kuni katsuya

CQRS - 0 views

kuni katsuya

When to avoid CQRS - 0 views

  • When to avoid CQRS
« First ‹ Previous 41 - 60 of 61 Next ›
Showing 20 items per page