5 ms·

As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?

by neals 10y ago

greydius 10y ago
This is the basic stategy that I try to follow as much as possible: Classes that hold data have no methods (beyond getters/setters). Classes that implement behavior have no mutable state; they exist as namespaces for the functionality that they provide. I've been quite successful with this approach. It leads to code that is easier to understand than a big ball of stateful objects.
- unsoundInput 10y ago
  Funny, I tend to go the opposite way (immutable value types, stateful-as-needed behavior classes). I wonder how you argue that you have less stateful objects considering data objects are usually instantiated more than logic objects?
- mattmanser 10y ago
  Someone did this on a project I work on (C#). Utter nightmare. Loads of repeated code as new programmers didn't know methods existed, loads of extraneous DTO objects, lots of nested single line methods, massive code bloat. Hard to find what actually does stuff, hard to use built in editor functionality. It's really not a good tactic imo. I'm undoing it as I go, at one point after having worked on it nearly 4 months according to git I'd still had a net negative on total lines of code, having added a ton of new functionality. Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat. I see the need for something, on the startup + enterprisey projects I work on you always seem to end up with at least one mega class that ends up being a beast, the Order, Person, Customer, Job or Project objects are usual culprits, but most other classes don't need much past a few basic methods. I'm just not convinced this programming tactic is it having now seen it in the wild.
  - coldtea 10y ago
    >Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat. Moving the methods off the classes would actually lead to less code duplication -- as now different data that need the same treatment can be handled with the same methods. "Loads of repeated code as new programmers didn't know methods existed" seems like a bigger issue here...
    - jghn 10y ago
      A bigger issue indeed, and one I've also seen in fully OOP code bases. Entire parallel bits of functionality as developer A has no idea that developer B already made the thing they want
    - mattmanser 10y ago
      as now different data that need the same treatment can be handled with the same methods. That just doesn't happen enough in real life to design around. In the rare instances when you do need to that, it's trivial to handle with interfaces and a wrapped method that calls a shared function.
      - coldtea 10y ago
        >That just doesn't happen enough in real life to design around. On the contrary, I think it does. Especially for web, enterprise and application programming, 90% of the logic is the same tired data transformations.
        mattmanser 10y ago
        It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying. Have you got any examples? I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class? Like in C#, the entity framework has mainly done away with all the "tired data transformations". The equivalents like Hibernate, ActiveRecord, etc. have done the same in other languages (and were the trailblazers). When I dip into a data transformation these days it's complex, hand-coded SQL, the tricky bit that takes time, with a simple data class to handle strong typing, trivial to write in a minute or two with snippets and auto-completion.
- dr0verride 10y ago
  I second this approach. The only state my behavior classes hold are injected dependencies. The only caveat to this approach is that for some cases you will need a state accumulator of some sort. But those state manipulations are isolated and easy to deal with.
- deleted 10y ago
  [deleted]
- geophile 10y ago
  A class that holds data and has no methods other than get/set is basically a struct. Why even bother with the get/set methods? You assert that code based on this approach is easier to understand, but you don't give a reason why this is so. This sounds a lot like a pre-OO approach to organizing code and data, and I don't understand the benefits. To use the tried-and-true example: I want my stack state and code to go together. Why would I want to expose the stack state, and keep the code manipulating it separate?
imron 10y ago
Consider compression oriented programming: https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html
hasbot 10y ago
I started programming before OOP was widely adopted (C++ was available on some platforms but costly). The C code we worked on wasn't structured very rigorously. There were really no rules or guidelines. I worked on telecommunications software, compilers, and databases. C structs were used obviously to hold data. Structs were created after analyzing the data to be stored, determining multiplicities, lifetime, etc. C functions were frequently large and handled numerous concerns. Programmers usually started with one function and split off other functions as needed mostly to take advantage of commonality and to avoid deep nesting.
mabynogy 10y ago
You can transform: o.f(a,b,c) to f(o,a,b,c) Remove methods and use the object as a data structure.
Chris_Newton 10y ago
You can apply principles like functional decomposition and modular design without necessarily having an object/class system. Instead of storing some state implicitly within objects and having some sort of this/self available when calling a method on an object, you create data-only variables to hold the state and then pass extra data into and out of your functions as needed instead of calling methods “on” some object. Traditional procedural, structured programming works this way. You see it at a small scale in countless scripts written in languages like Perl or Python, and at a larger scale in big C programs. Functional programming also works this way, but typically is even more explicit about it. The key point is that usually you still want to separate the responsibilities of your program in a modular way, with clean interfaces and hidden implementations. You just use other tools to do it, typically by defining your data structures and algorithms directly, instead of bundling them together in a class or your language’s equivalent. At first glance that might seem restrictive or less powerful, but in fact it’s the opposite, because it removes OO’s inherent bias towards algorithms where one object is special. I commented about this last point once before, if you’re interested: https://news.ycombinator.com/item?id=8690746 https://news.ycombinator.com/item?id=8690746 If it helps, you might consider that when you call a method on an object in a typical class-based language, what’s really happening under the hood is that (a) you’re passing an implicit pointer/reference to the object as an extra parameter to the function you call, and (b) which function you call may itself be determined by a look-up process based on the type of the object. If your language didn’t support those functions as built-in features, you could just as well pass any required data from the “object” in and back out again explicitly through function parameters and return values, just as you do for any other data you’re processing or generating in that function, and you could use some sort of look-up table to decide which function to call based on some form of tagging each object with its “type”. Indeed, plenty of people were doing this in C, before what we now call C++ came along and made it more convenient by building the pattern into the language.

As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?

by neals 10y ago

As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?

greydius 10y ago

This is the basic stategy that I try to follow as much as possible: Classes that hold data have no methods (beyond getters/setters). Classes that implement behavior have no mutable state; they exist as namespaces for the functionality that they provide. I've been quite successful with this approach. It leads to code that is easier to understand than a big ball of stateful objects.

unsoundInput 10y ago
Funny, I tend to go the opposite way (immutable value types, stateful-as-needed behavior classes). I wonder how you argue that you have less stateful objects considering data objects are usually instantiated more than logic objects?
mattmanser 10y ago
Someone did this on a project I work on (C#). Utter nightmare. Loads of repeated code as new programmers didn't know methods existed, loads of extraneous DTO objects, lots of nested single line methods, massive code bloat. Hard to find what actually does stuff, hard to use built in editor functionality. It's really not a good tactic imo. I'm undoing it as I go, at one point after having worked on it nearly 4 months according to git I'd still had a net negative on total lines of code, having added a ton of new functionality. Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat. I see the need for something, on the startup + enterprisey projects I work on you always seem to end up with at least one mega class that ends up being a beast, the Order, Person, Customer, Job or Project objects are usual culprits, but most other classes don't need much past a few basic methods. I'm just not convinced this programming tactic is it having now seen it in the wild.
- coldtea 10y ago
  >Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat. Moving the methods off the classes would actually lead to less code duplication -- as now different data that need the same treatment can be handled with the same methods. "Loads of repeated code as new programmers didn't know methods existed" seems like a bigger issue here...
  - jghn 10y ago
    A bigger issue indeed, and one I've also seen in fully OOP code bases. Entire parallel bits of functionality as developer A has no idea that developer B already made the thing they want
  - mattmanser 10y ago
    as now different data that need the same treatment can be handled with the same methods. That just doesn't happen enough in real life to design around. In the rare instances when you do need to that, it's trivial to handle with interfaces and a wrapped method that calls a shared function.
    - coldtea 10y ago
      >That just doesn't happen enough in real life to design around. On the contrary, I think it does. Especially for web, enterprise and application programming, 90% of the logic is the same tired data transformations.
      - mattmanser 10y ago
        It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying. Have you got any examples? I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class? Like in C#, the entity framework has mainly done away with all the "tired data transformations". The equivalents like Hibernate, ActiveRecord, etc. have done the same in other languages (and were the trailblazers). When I dip into a data transformation these days it's complex, hand-coded SQL, the tricky bit that takes time, with a simple data class to handle strong typing, trivial to write in a minute or two with snippets and auto-completion.
dr0verride 10y ago
I second this approach. The only state my behavior classes hold are injected dependencies. The only caveat to this approach is that for some cases you will need a state accumulator of some sort. But those state manipulations are isolated and easy to deal with.
deleted 10y ago
[deleted]
geophile 10y ago
A class that holds data and has no methods other than get/set is basically a struct. Why even bother with the get/set methods? You assert that code based on this approach is easier to understand, but you don't give a reason why this is so. This sounds a lot like a pre-OO approach to organizing code and data, and I don't understand the benefits. To use the tried-and-true example: I want my stack state and code to go together. Why would I want to expose the stack state, and keep the code manipulating it separate?

imron 10y ago

Consider compression oriented programming: https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html

hasbot 10y ago

I started programming before OOP was widely adopted (C++ was available on some platforms but costly). The C code we worked on wasn't structured very rigorously. There were really no rules or guidelines. I worked on telecommunications software, compilers, and databases. C structs were used obviously to hold data. Structs were created after analyzing the data to be stored, determining multiplicities, lifetime, etc. C functions were frequently large and handled numerous concerns. Programmers usually started with one function and split off other functions as needed mostly to take advantage of commonality and to avoid deep nesting.

mabynogy 10y ago

You can transform: o.f(a,b,c) to f(o,a,b,c) Remove methods and use the object as a data structure.

Chris_Newton 10y ago

You can apply principles like functional decomposition and modular design without necessarily having an object/class system. Instead of storing some state implicitly within objects and having some sort of this/self available when calling a method on an object, you create data-only variables to hold the state and then pass extra data into and out of your functions as needed instead of calling methods “on” some object. Traditional procedural, structured programming works this way. You see it at a small scale in countless scripts written in languages like Perl or Python, and at a larger scale in big C programs. Functional programming also works this way, but typically is even more explicit about it. The key point is that usually you still want to separate the responsibilities of your program in a modular way, with clean interfaces and hidden implementations. You just use other tools to do it, typically by defining your data structures and algorithms directly, instead of bundling them together in a class or your language’s equivalent. At first glance that might seem restrictive or less powerful, but in fact it’s the opposite, because it removes OO’s inherent bias towards algorithms where one object is special. I commented about this last point once before, if you’re interested: https://news.ycombinator.com/item?id=8690746 https://news.ycombinator.com/item?id=8690746 If it helps, you might consider that when you call a method on an object in a typical class-based language, what’s really happening under the hood is that (a) you’re passing an implicit pointer/reference to the object as an extra parameter to the function you call, and (b) which function you call may itself be determined by a look-up process based on the type of the object. If your language didn’t support those functions as built-in features, you could just as well pass any required data from the “object” in and back out again explicitly through function parameters and return values, just as you do for any other data you’re processing or generating in that function, and you could use some sort of look-up table to decide which function to call based on some form of tagging each object with its “type”. Indeed, plenty of people were doing this in C, before what we now call C++ came along and made it more convenient by building the pattern into the language.