Results 1 to 14 of 14
  1. #1
    dismal-it is offline Member
    Join Date
    Aug 2013
    Posts
    8
    Rep Power
    0

    Default Streamlining corporate IT development

    Hi,

    I just joined this forum a few hours ago. I am working in the IM department of a big organization. After 10+ years in almost all positions of corporate IT, my major interest is to analyze development processes in corporate IT, identify waste ( amongst them, in my opinion, a large number of java server technologies suited for B2C web applications, but not suited for corporate software), and try to propose streamlined solutions. I try to develop those ideas in a (still small) blog: Dismal IT.

    I am joining this forum mostly to discuss java topics, as I plan to launch some major (and complex) development prototypes in the next months, most of them in java (as for me java is, despite its limits, the "default" programming option today for its very large developer population, cross-platform portability, and quite good library set).

  2. #2
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    Its not fair, Java can't defend itself. So I'm going to do it: Java does not have limitations, only programmers do. One such limitation is diving in without first thinking about if the tool you're using will get the job done. Its like assuming you can use a hammer to drive a screw into a wall. Sure it will work, but it ain't gonna look pretty... In the world of programming, its exactly the same. So no, Java is not the "default" programming language/programming platform and never should be. It is the right tool for certain jobs; nothing more, nothing less.

    Griping aside, I identify with the topics you breach in your blog although perhaps you might want to take a slightly more positive tone at times. You don't want to come over as the guy standing on a soap box in the park ;)

    And the color scheme man... its nauseating. Please, consider changing it.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  3. #3
    dismal-it is offline Member
    Join Date
    Aug 2013
    Posts
    8
    Rep Power
    0

    Default Re: Streamlining corporate IT development

    Hi gimbal2,

    thanks for your answer. Let me answer a few things.

    First, I only concern myself today with corporate application developments, I fully acknowledge there are many other contexts.

    In that context, I see java as a default option, mostly I believe for the cross platform aspect (never know if a customer will want to use Linux / Windows / commercial Unix in the datacenter), the quite easy learning curve (no C-like pointers) which is key as corporate IT has to "wistand" very variable skill of developers, and the decent set of libraries (I say decent as the amount of standard libraries is impressive, but I always have the frustration that especially the SDK did not go the extra mile for my needs - the missing Treetable component in swing is one example, the quite late arrival of logging in the jdk is another).

    One of the big limitation I see on java is the lack of proper multiple inheritance, which, seen from my window, is the root cause of many of the boilerplate or unreadable code in java. This frustrates me even more that I see it implemented in other languages and it did not seem so complex. Not that I think the people who defined java were wrong or bad: i recognize you have to make compromises also to get a product out.

    I will think about your comments for the color (a reference to the "terminal green" ) and the tone (partly the fact I am French, partly the fact I believe being 'pessimistic / conservative' is what corporate IT needs). I can probably make both more attractive.

  4. #4
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    Sorry, but the multiple inheritance bit completely contradicts your earlier "easy learning curve" comment. The fact that Java is easier to pick up is because it does not contain such language features that lead to utter application design madness.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  5. #5
    dismal-it is offline Member
    Join Date
    Aug 2013
    Posts
    8
    Rep Power
    0

    Default Re: Streamlining corporate IT development

    well in my experience the need to "assemble" objects from "subcomponents" comes quite soon. In my experience, multiple inheritance allows to do that quite cleanly, even if I agree with you, there could be "dirty" complications (mostly from what I remember about what to do when the two subcomponents use a method of the same name, something we could maybe circunvent by just forbidding it). I see most of the patterns that go around this limitation (interface + helper, even aspect-oriented programming to some extent) as being neither easier to learn nor as convenient.

    I am very interesting though if you have any examples of how multiple inheritance can lead to crazy application designs. For sure, there are some reasons why it is not so widespread. Sometimes, those reasons are just history (java evolving from C...), but they may be also that multiple inheritance is a "dismal friend", though I am not convinced so far.

  6. #6
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    'assemble' is more another word for composition rather than inheritance. As in a house has four walls, a roof and a door.

    I don't need to prove myself to you; I challenge you to give a code design that uses multiple inheritance that IS clean, and could not be solved cleanly using composition and/or interfacing.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  7. #7
    dismal-it is offline Member
    Join Date
    Aug 2013
    Posts
    8
    Rep Power
    0

    Default Re: Streamlining corporate IT development

    Well, let's try to make an example. Let's say I have a component called "lifecycle" that I may want to stick to some business objects. It mostly consists of:
    - (1) a field to store the current lifecycle and a getter ( lifecycle / getLifecycle) ;
    - (2) a feature to allow to change the lifecycle if the user is authorized ( setLifecycle );


    I describe only one component here, but there can be plently of other components I would like to make a business object of. So making my business object inherit of "lifecycle" is not an option.

    I see the following possible patterns:

    Helper Class
    - store the field (1) on the business object;
    - declare an interface that provides the getter (1) and setter for (1), with somehow a restriction that the setter for one should not be public (I have seen that sometimes and it can be quite fuzzy).
    - write an helper class that implements (2)

    Multiple inheritance:
    - just declare the business object as inheriting from lifecycle. It will implement the data and the methods, providing additional features if required.

    Composition:
    - declare an instance of the lifecycle class inside the business object;
    - allows users to access to the lifecycle subobject. Here, my main fear somehow is that the lifecycle object is out 'in the wild' and not controlled by the business object, so I need to put somehow a "back reference" from my business object inside my lifecycle object (to get the id of the row in the db to modify).

  8. #8
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    You create a vague requirement where a method on what is most clearly an interface should be visible only on specific classes, and you then claim that multiple inheritance can 'solve' that vague requirement.

    Sorry, we'll just have to agree to disagree. I'd rather just do this:

    Java Code:
    public interface Lifecycle {
      public int getLifeCycle(); // whatever
    }
    
    public interface AdjustableLifecycle extends Lifecycle {
      public void setLifeCycle(int lifeCycle); // whatever
    }
    Any code that needs to be able to adjust the lifecycle will only accept objects that implement AdjustableLifecycle, any other code can accept the basic Lifecycle interface. The helper class is optional, if there is lots of business logic in there I might choose to abstract it away but if not then the classes just implement the methods themselves.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  9. #9
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,450
    Rep Power
    18

    Default Re: Streamlining corporate IT development

    I would argue that a BusinessObject has-a Lifecycle...not is-a Lifecycle.
    Hence a BusinessObject will have a Lifecycle attribute.

    Security and permissions are not something the underlying model should be worried about.
    Please do not ask for code as refusal often offends.

  10. #10
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    Quote Originally Posted by Tolls View Post
    I would argue that a BusinessObject has-a Lifecycle...not is-a Lifecycle.
    ... yeah, exactly. Crud, I was only half-way there with my interfacing example.

    Security and permissions are not something the underlying model should be worried about.
    Even though that's true, what exactly are you responding to here? I'm confused :)
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  11. #11
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,450
    Rep Power
    18

    Default Re: Streamlining corporate IT development

    "
    a feature to allow to change the lifecycle if the user is authorized ( setLifecycle );
    "

    Strikes me as irrelevant to whether you give BusinessObject a setter or not for Lifecycle.
    The above only applies to how specific users can use that object, and certain methods on that object, which is the realm of security and permissions.
    Please do not ask for code as refusal often offends.

  12. #12
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    3,082
    Rep Power
    4

    Default Re: Streamlining corporate IT development

    Ah. Well now you've proven that you DO have a good day after all.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  13. #13
    dismal-it is offline Member
    Join Date
    Aug 2013
    Posts
    8
    Rep Power
    0

    Default Re: Streamlining corporate IT development

    Hi guys,

    thanks for your answers. So here is more detail on the use-cases I often encounter:
    - let's say that the set lifecycle is quite complex, and I want to implement it once only, not copy paste the code of the logic on each object (which would be the case if I just declare an interface). Probably, I can indeed define a lifecycle object and have it as an attribute of the business objects. This raises the further questions:
    - the persistence is at the business object level (let's say typically, business object is its own table in the DB): this means that whenever I do an action on the lifecycle, it needs to reference back to the main business object for the persistence. I am not sure it is obvious to do;
    - on security, I am interested in many ideas on best practices. Just to tell you, in my experience, security rules are quite complex, and typically represent 15-30% of the overall business logic of an application (nothing as simple as the unix '741' kind of security). Could be something like: for object 1 (and its children for inheritance) if you are of group A and lifecycle is B and the object is in folderC, then you can do actions E and F, but not G. Adding the fact one guy can have several roles with different compositions rules (sometimes, the authorization wins, sometimes the denial wins), it is not obvious.

  14. #14
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,450
    Rep Power
    18

    Default Re: Streamlining corporate IT development

    Quote Originally Posted by dismal-it View Post
    Hi guys,

    thanks for your answers. So here is more detail on the use-cases I often encounter:
    - let's say that the set lifecycle is quite complex, and I want to implement it once only, not copy paste the code of the logic on each object (which would be the case if I just declare an interface). Probably, I can indeed define a lifecycle object and have it as an attribute of the business objects. This raises the further questions:
    - the persistence is at the business object level (let's say typically, business object is its own table in the DB): this means that whenever I do an action on the lifecycle, it needs to reference back to the main business object for the persistence. I am not sure it is obvious to do;
    Depends on the exact lifecycle requirements. If "lifecycle" is simply some collection of things that define the lifecycle state, and represented by a table in the db, then it persists itself. If it's more business flow (bunch of stuff gets done when object moves from state A to state B), then you're probably looking at AOP? Just trying to think in terms of stuff I've seen/done. That way the lifecycle logic is simply layered over the top.

    Quote Originally Posted by dismal-it View Post
    - on security, I am interested in many ideas on best practices. Just to tell you, in my experience, security rules are quite complex, and typically represent 15-30% of the overall business logic of an application (nothing as simple as the unix '741' kind of security). Could be something like: for object 1 (and its children for inheritance) if you are of group A and lifecycle is B and the object is in folderC, then you can do actions E and F, but not G. Adding the fact one guy can have several roles with different compositions rules (sometimes, the authorization wins, sometimes the denial wins), it is not obvious.
    But that's a "simple" package. Yes, the rules are complex, but at the end of the day you have a simple "yes" or "no" answer to the action you are trying to perform. And again this is something I have seen generally done via AOP, especially for complex stuff. Funnily enough this is dug from the same bit of memory as the above one. A business execution (planninng, budgeting, monitoring, etc) software with ridiculously flexible roles.
    Please do not ask for code as refusal often offends.

Similar Threads

  1. I'm from corporate and I'm here to help!
    By jlczuk in forum Introductions
    Replies: 3
    Last Post: 04-19-2012, 04:39 PM
  2. Replies: 0
    Last Post: 04-10-2012, 05:45 PM
  3. Corporate Trainer Java/JEE Technology
    By pooja_k in forum Jobs Offered
    Replies: 0
    Last Post: 04-09-2010, 10:55 AM
  4. Code streamlining
    By Gtrain in forum New To Java
    Replies: 1
    Last Post: 08-23-2009, 03:32 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •