Skip to content
HomeVideosBooks
AllTopicsTrends
BlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K
    Cover of Component software

    Component software

    Clemens Szyperski · 1997

    Component Software: Beyond Object-Oriented Programming explains the technical foundations of this evolving technology and its importance in the software market place. It provides in-depth discussion of both the technical and the business issues to be considered, then moves on to suggest approaches for implementing component-oriented software production and the organizational requirements for success. The author draws on his own experience to offer tried-and-tested solutions to common problems and novel approaches to potential pitfalls. Anyone responsible for developing software strategy, evaluating new technologies, buying or building software will find Clemens Szyperski's objective and market-aware perspective of this new area invaluable.

    ProgrammingSoftware EngineeringComputer Science
    Open LibraryAmazon
    Stats for nerds
    3recommend
    30mentions
    4people
    2013–2026years
    33% recommend67% neutral

    Mentions per year

    20132015201720192021202320252026

    What Hacker News says

    1. pjmlpFeb 2026
      Rust's OOP model fits perfectly into COM, WinRT, which is also OOP from CS point of view, and known for decades.

      See Component Software: Beyond Object-Oriented Programming, first edition 2002.

      Also the way Microsoft is implementing their windows-rs crate, and WDK for Rust.

      thread
    2. pjmlpMar 2023
      Recommended reading for everyone that doesn't get how traits are just yet another kind of OOP.

      "Component Software: Beyond Object-Oriented Programming"

      https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720

      "Authoring ActiveX with VB 6"

      https://learn.microsoft.com/en-us/previous-versions/visualst...

      "Traits - Composable Units of Behavior"

      https://scg.unibe.ch/research/traits

      "Working with Protocols"

      https://developer.apple.com/library/archive/documentation/Co...

      thread
    3. pjmlpFeb 2021
      It is a bit hard to just explain in a bunch of comments.

      In your examples you need to add extra layers, just like you would do with the microservices.

      There would be the DTOs that represent the actual data that gets across the models, the view models that package the data together as it makes sense for the views, the repository module that actually abstracts if the data is accessed via SQL, ORM, RPC or whatever.

      You should look into something like:

      "Domain-Driven Design: Tackling Complexity in the Heart of Software"

      https://www.amazon.com/Eric-J-Evans/dp/0321125215

      "Component Software: Beyond Object-Oriented Programming"

      https://www.amazon.com/Component-Software-Beyond-Object-Orie...

      thread
    4. pjmlpSep 2020
      Neither => Component Based Programming,

      "Component Software: Beyond Object-Oriented Programming"

      https://www.amazon.com/Component-Software-Beyond-Object-Orie...

      https://www.amazon.com/Component-Software-Object-Oriented-Pr...

      thread
    5. pjmlpJul 2020
      Here are some pointers:

      "Large-Scale C++ Software Design"

      https://www.amazon.com/Large-Scale-Software-Design-John-Lako...

      Although oriented towards C++, many architecture tips apply to other languages as well.

      John Lakos is in the process of writing updated versions of the book.

      "Large-Scale C++ Volume I: Process and Architecture"

      https://www.amazon.com/Large-Scale-Architecture-Addison-Wesl...

      "Large-Scale C++ Volume II: Design and Implementation"

      https://www.amazon.com/Large-Scale-Implementation-Addison-We...

      Then going back into the old days, you have

      "Software Engineering in Modula 2: An Object Oriented Approach"

      https://www.amazon.de/-/en/Jill-Hewitt/dp/0333515188

      "Data Structures and Program Design in Modula-2"

      https://www.amazon.de/Larry-R-Nyhoff/dp/0023886218/ref=sr_1_...

      "Code Complete: A Practical Handbook of Software Construction"

      https://www.amazon.com/dp/0735619670/ref=sr_1_1

      "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis"

      https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711...

      "Component Software: Beyond Object-Oriented Programming"

      https://www.amazon.com/Component-Software-Object-Oriented-Pr...

      "Use Cases Combined With Booch/Omt/Uml: Process and Products"

      https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372...

      Just some pointers to get you started.

      thread
    6. RossBencinaDec 2019
      This article was an excellent read. Like other commenters, it reminded me of Clemens Szyperski's "Component Software" book. While a component model of software production has succeeded in some niches, it has (so far) failed to become a central organising principle for large scale software production. The article suggests that new micropayment mechanisms such as blockchain might enable Brad Cox's vision of pay-as-you-use software components. But I think this misses the point. I would argue that software differs from physical goods in important ways that make it a poor fit for this model. In particular, software is cheap to modify, evolve and customise, but expensive to specify independent of implementation (cf. Refactoring, Agile processes versus ISO Standards Development.)

      One issue that Szyperski's book examined was the composition model (i.e. object model: COM, CORBA, JavaBeans, etc) used for defining interfaces between software components and how those interfaces can be composed. The idea of standardizing interfaces and composition mechanisms does not get so much attention today. It seems that things are currently balkanized into language communities, each doing their own thing.

      The industrial manufacturing concept of "interchangeable components" comprises of two things: (1) standardized specifications, (2) multiple independent manufacturers who are able to independently implement specifications. We do have this kind of practice in, for example, the specification and implementation of the C++ standard library. But that's not how most software is developed, and it is commonly held that it is not how most software should be developed. On the other hand, we do have "component reuse" in the form of software libraries -- but the interfaces are unique and idiosyncratic to each library, not standardised, and there is usually a single "manufacturer".

      thread

    Related

    Cover of Object-Oriented Analysis and Design with Applications
    2012–2025

    Object-Oriented Analysis and Design with Applications

    Grady Booch
    7 recommend · 13
    Cover of Object-oriented software construction
    2010–2026

    Object-oriented software construction

    Bertrand Meyer
    22 recommend · 53
    Cover of The C++ standard library
    2008–2020

    The C++ standard library

    Nicolai M. Josuttis
    9 recommend · 11
    Cover of The art of multiprocessor programming
    2009–2026

    The art of multiprocessor programming

    Maurice Herlihy
    27 recommend · 64
    Cover of Elements of programming
    2009–2026

    Elements of programming

    Alexander A. Stepanov
    31 recommend · 58
    Cover of Project Oberon
    2009–2026

    Project Oberon

    Niklaus Wirth
    30 recommend · 129
    Cover of Domain-Driven Design
    2007–2026

    Domain-Driven Design

    Eric Evans
    104 recommend · 252
    Cover of Component-based software engineering
    2018–2020

    Component-based software engineering

    George T. Heineman
    0 recommend · 4