Can you develop in an object-oriented way in c?(c에서 객체지향적 방법으로 개발할 수 있을까?)


Korean version is below. 한국어 버전은 아래에 있음

First of all, it is a domain that does not allow dynamic memory in the field of embedded sw.

 

conclusion

Developing in an object-oriented way in c …

  1. Why are you going to be object-oriented? It is better than procedure – oriented because the expression system is diverse and expressive in terms of design. So I will try.

  2. Do I have to? This is not because it makes the design more intuitive and greatly improves the readability of the code.

  3. Is object-oriented imitation possible? It is possible. You can do this without using dynamic memory. There may be some limitations

 

Apart from the reason for object-oriented development, it is possible to create object-free objects by defining well structured function pointers in c’s structure.

By the way, if malloc is not allowed in the sense that you should not use the heap … how ??

In fact, I was worried about whether I could develop in an object-oriented way in C for 2 or 3 years ago. It’s not necessarily the case, but it was because of the vague idea that it would be nice and nice to do so.

A-SPICE also comes with the concept of a component, which can be interpreted as a set of objects (although it can be interpreted in other ways as well)

Recently, I heard that UML class diagram could be a very powerful design tool in KOSTA by listening to use case and object-oriented modeling nighttime curriculum and wanted to solve the problem even more.

In the meantime, I’ve heard about two UML tutorials, and I have been thinking about something like this because I designed it in AUTOSAR anyway with the concept of object oriented.

However, there was a considerable difficulty in applying it to the past. C is so opaque than object-oriented language …

Through last night’s education, I have come to think again about the application of the class diagram to the automobile domain, and after a reckless attempt to move the class diagram to c … Two solutions were obtained.

One thing was okay with the way of writing the heap area. Of course not in the MISRA-c perspective.

The other is a way to write a static area, which is more restrictive than the first, but it seems to be possible to implement it objectively.

Personally, I think that the approach to design and implement using UML’s class diagram is superior to the approach to design with simulink / stateflow alone.

<Simulink / Stateflow only approach criticism>

The excellence of the class diagram enhances the flexibility and maintainability of the design by elegantly grouping the data and related actions into a single object. Simulink / stateflow only, on the other hand, is reusable because it is itself a chunk of code.

People who do not know (executives or senior managers) think like this. Simply drawing with a picture will make it more intuitive, reusable and excellent … Sorry, but you’re being scammed (or mistaken) … And the in-house Simulink / Stateflow SW developers know it’s a bad idea. However, it is merely a marketing point and a fantasy of the executives, so I do not want to make it inconvenient, so I do not tell the truth.

Obviously, simulink / stateflow is a nice and great tool, but it means that a well-trained and educated elite can draw nicely, doing the wrong thing to convert messy code into simulink / stateflow, Can not be done.

</ Simulink / Stateflow only Approach criticism>

Anyway It can be a way of designing as well as a way to put data into a huge data pool and use it whenever you need it. On the SI side, I put a lot of data in the DB and implement it in a way that I draw out when I need it. I do not know about your industry, but you can create a bunch of DB tables and process all the data with a query. It’s not a design. I heard your instructor at night, and I put a bunch of data in the automotive global variable I figured out how to put it out when you need it.

I agree with the teaching of the instructor. The way in which data is put into the data pool is not clear in the R & R of the data, and because it does not usually define the data dictionary, it is common for similar duplicate data to be entered, and the maintenance is the same. I’ll go back and reuse it later, but the code will not die and live forever, harassing new developers.

 

 

 

우선 임베디드 sw의 분야에서의 dynamic memory를 허용하지 않는 domain임을 미리 말해둔다.

객체지향적으로 개발을 해야 할 필요가 있는지에 대한 이유를 떠나서, c의 구조체에 함수포인터를 잘 정의해서 구조적으로 잘 정의만 하면 객체 비스므리한 것을 만들어 낼 수는 있다.

그런데, heap을 쓰지 않아야 한다는 점에서 malloc이 허용되지 않는다면…어떻게 ??

사실 c에서 객체지향적인 방법으로 개발할 수 있을까에 대한 고민은 2~3년 전부터 해왔었다. 반드시 그래야 하는 것은 아니지만, 웬지 그렇게 하면 멋있을 것 같고 좋을것 같은 막연한 생각때문이었다.

A-SPICE에서도 component라는 개념이 나오는데, 사실상 그게 객체의 집합으로 해석될 수도 있고 (다른 의미로도 해석될 수 있지만..)

최근에 KOSTA에서 유즈케이스와 객체지향 모델링 야간 교육과정을 듣고 UML의 class diagram이 매우 강력한 설계 도구가 될 수 있음을 알게 되고 더욱 그 문제에 대한 해결을 하고 싶었다.

그간 UML에 대한 교육도 2개 듣고, AUTOSAR에서도 어쨌거나 object oriented개념이 들어간 방법으로 설계를 하니 뭔가 그런 트렌드를 따라가줘야 하는게 아닌가 생각도 들었다.

그런데, 막상 적용하기에는 상당한 고민이 따랐다.. c가 워낙 객체지향 언어에 비해서는 미개한지라…

지난 야간 교육을 통해서 class diagram에 대한 자동차 domain으로의 적용 가능성을 다시금 생각해보게 되었고, class diagram을 c로 옮기려는 무모한 시도를 한 끝에… 2가지 solution을 얻게 되었다.

1가지는 heap영역을 쓰는 방법으로 나름 괜찮았다. 물론 MISRA-c관점에선 안된다.

다른 한가지는 static영역을 쓰는 방법으로 첫번째보다는 제약이 좀 있기는 하지만, 나름 object스러운 방법으로 구현이 가능할 듯 싶다.

개인적인 생각이지만, UML의 class diagram을 사용해서 설계 및 구현하는 접근법이 simulink/stateflow만으로 설계하는 접근법보다는 우수하다고 생각한다.

<Simulink/Stateflow only접근법 비판>

class diagram의 우수성은 데이터 및 그와 관련된 행동을 우아하게 묶어서 하나의 객체로 표현함으로써 설계의 유연성과 유지보수성을 높여준다고 볼 수 있다. 그에 비해 simulink/stateflow only는 그 자체가 하나의 덩어리코드이기 때문에 재사용성이 떨어진다.

잘 모르는 사람들(임원들이나 고위 관리자)은 이렇게 생각한다. 단순히 그림으로 그리면 보다 직관적이고 재사용 가능하고 우수할 것이라고,… 미안하지만 당신은 사기당한거다(혹은 착각을 한것이다.)… 그리고 사내 Simulink/Stateflow SW개발자들도 그것이 잘못된 생각이라는 것을 다 알고 있다. 다만 그것이 마케팅 포인트이고 임원진들의 환상이고 하니까 불편하게 하고 싶지 않아서 진실을 말하지 않는 것일 뿐이다.

물론 simulink/stateflow가 멋지고 훌륭한 도구는 분명하지만, 잘 훈련되고 교육받은 엘리트가 멋지게 그릴 수 있다는 의미이지, 엉망진창인 코드를 simulink/stateflow로 변환하는 한참 잘못된 일을 하고 이제 코드가 좋아졌다고 생각하고 좋아해서는 안된다.

 

Anyway 거대한 data pool에 데이터를 엄청 집어넣고 필요할 때마다 사용하는 방식이 물론 설계의 한 방법일 수는 있다. SI쪽에서는 DB에 데이터를 잔뜩 넣고 필요할때 꺼내쓰는 방식으로 많이 구현한다고 한다. 그쪽 업계를 잘은 모르지만, DB 테이블을 잔뜩 만들고 쿼리로 모든 데이터를 처리한다고.. 그건 설계가 아니니라..라고 야간 교육때 말씀하신 강사님의 말씀을 듣고 난 automotive쪽의 전역변수에 데이터를 잔뜩 넣고 필요할때 꺼내쓰는 방식을 떠올렸다.

나도 고수 강사님의 그 가르침에 동의한다. 데이터 pool에 데이터를 집어넣는 방식은 데이터의 R&R로 명확하지 않고, 일반적으로 data dictionary를 정의하지도 않기 때문에 유사한 중복데이터가 들어가는 경우가 흔하고, 유지보수는 물건너간거와 같다. 돌아가기는 하니까 나중에 재사용하기는 하지만, 그 코드는 죽지 않고 영원히 살아서 신입 개발자를 괴롭힐 것이다.

결론

c에서 객체지향적 방법으로 개발하기…

  1. 왜 객체지향적으로 하려고 하는가? 설계관점에서 표현방식이 다양하고 표현능력이 더 우수하기 때문에 절차지향적보다는 낫다. 그래서 하려고 하는 것이다.

  2. 꼭 그렇게 해야하는가? 그런건 아닌데, 설계를 보다 직관적으로 할 수 있고, 코드의 가독성이 비약적으로 향상되기 때문이다.

  3. 그럼 객체지향적인 흉내내기는 가능한 것인가? 가능하다. dynamic memory를 쓰지 않고도 할 수 있다. 약간의 제약은 있겠으나

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s